For years, Customer Data Platforms (CDPs) have been built around a relatively clear objective: bring customer data together from different systems and make it useful for marketing. By connecting customer records, tracking behaviour, building segments and synchronizing audiences with other tools, CDPs have helped companies turn fragmented information into more effective campaigns and more consistent customer experiences.
Today this remains an important job. Many organizations still struggle to connect their customer data, and marketing teams continue to need reliable profiles for segmentation, personalization and activation. But as AI becomes part of customer service, sales, product experiences and other operational processes, the role of customer data is beginning to change.
An AI application does not necessarily need another audience to activate. It may need to understand whether a person is an existing customer, which company that person belongs to, whether an account is currently active, what happened during a recent support interaction, and which information can legitimately be used to answer a particular question. It also needs to distinguish current information from historical records and understand when different systems disagree.
These requirements are not entirely new. Companies have always needed accurate customer data, and well-designed data architectures have always depended on clear definitions, reliable identities and appropriate access controls.** What changes with AI is how directly these foundations influence the behaviour of an application. Information that was previously used to build a report or select a marketing audience can now shape a conversation, a recommendation or an operational decision.**
This is why the evolution of customer data platforms deserves more attention than simply adding AI features to existing products. The question is whether the customer profile itself can become a reliable foundation for applications that need to understand and act on customer information.
When the single customer view became a marketing view
The idea of a single customer view has been central to the CDP category from its early days. Customer information was scattered across CRM systems, websites, mobile applications, transactional databases and marketing platforms, often with several records representing the same person. By connecting those records, companies could build a more consistent view of customer behaviour and use it to coordinate their communications.
In practice, however, the value of that unified view was often measured by what marketing teams could do with it. Could they identify customers who had abandoned a purchase? Could they distinguish new prospects from existing customers? Could they create more relevant audiences, personalize messages and synchronize those audiences with advertising or marketing automation platforms?
These were legitimate objectives, and they shaped the way many CDPs were designed and implemented. The profile became the basis for segmentation and activation, with identity resolution serving primarily to ensure that the right records contributed to the right audience.
AI introduces a different set of expectations because a customer profile may now be used directly by an application operating within a business process. Consider a support assistant that needs to explain why a customer cannot access a service. The CRM may identify the account as active, while billing shows an overdue payment and the support system contains an unresolved incident affecting access. Each system may be reporting accurate information, but the assistant needs a coherent interpretation of the situation before it can provide a useful answer.
A marketing segment is not designed to resolve that kind of contradiction. Nor should we expect a language model to resolve it reliably simply because it can read all three records.
The underlying challenge is therefore not that marketing-oriented CDPs have become useless. Their established capabilities remain valuable. It is that the customer profile is being asked to serve purposes beyond those for which it was originally designed, and the architecture supporting that profile needs to evolve accordingly.
Connecting AI to customer data is only the beginning
When companies begin experimenting with AI agents or copilots, the first technical challenge often appears to be connectivity. The team needs to connect a model to a CRM, expose data through an API, configure retrieval from a warehouse or allow an assistant to query internal systems.
Once those connections work, a more difficult set of questions emerges. Which source should the application trust when two systems disagree? How does it know whether a customer record is current? Can it distinguish a verified fact from an assumption or an outdated status? What happens if two different people have been incorrectly identified as the same customer?
These questions become particularly important when the AI application is expected to act rather than simply retrieve information. A sales assistant might recommend contacting an account that has already cancelled its contract. A customer service agent might offer a solution that is incompatible with the customer's current plan. An automated workflow might expose information associated with the wrong person because two identities were merged incorrectly.
In each case, the connection to the data source can be working exactly as intended. The problem lies in the representation of the customer that the application receives.
This distinction is easy to underestimate because a database can be accessible, well maintained and technically reliable while still providing an inconsistent view of a customer. It may contain records created at different times, fields with different meanings, identifiers that cannot safely be combined and information collected for different purposes. Making all of this data available does not automatically make it suitable for operational use.
An AI-ready customer data foundation must therefore do more than provide access. It needs to establish which identities belong together, preserve the origin and meaning of information, account for changes over time, and make the resulting customer representation appropriate for the application that will use it.
The more directly AI influences customer interactions and business decisions, the harder it becomes to treat these requirements as secondary data-engineering concerns.
The warehouse is essential, but it is not the whole solution
The growing importance of data warehouses and lakehouses has already changed the way companies think about customer data architecture. Rather than allowing every application to maintain its own isolated version of the customer, organizations increasingly want their data to remain accessible within an environment they control, where it can be combined with other business information and governed according to their own requirements.
A warehouse-native approach follows this principle. Customer data can remain in the company's existing infrastructure instead of being copied into a separate proprietary repository simply to build unified profiles. This reduces unnecessary duplication and gives the organization greater control over how customer identities and their associated information are represented.
However, having all the relevant data in one place does not mean that a reliable customer profile already exists.
A warehouse may contain website events, CRM contacts, billing records, support interactions and product usage data, but these datasets do not necessarily share the same definitions or identifiers. The same company might have different account IDs across systems, while the meaning of an apparently simple field such as customer status may vary between sales, billing and customer support.
The warehouse can preserve these differences and make them available for analysis. It does not automatically decide which identities belong together or which interpretation should be used in a particular business context.
That requires an additional layer of customer intelligence: one that applies explicit identity rules, connects the relevant records, maintains a coherent profile and makes the resulting information available to applications that need it. The original data should remain accessible so that the organization can inspect how a profile was constructed and rebuild it when the underlying data or matching rules change.
This is an important architectural distinction. The warehouse provides the environment in which customer data can remain under the company's control. The customer data layer makes that information coherent and usable.
For AI applications, both are necessary. Keeping data in a controlled environment is valuable, but control also depends on understanding how identities are linked, how profile attributes are derived and which information is exposed to each application.
Identity resolution becomes an operational responsibility
Identity resolution is often described as a technical capability that allows a CDP to recognize the same customer across different systems. That description is correct, but it understates the importance of the decisions involved.
When an anonymous website visitor logs in, a company may be able to connect the visitor's previous activity to a known user through a verified identifier. When a CRM contact is linked to a billing record, the relationship may be established through an explicit mapping between the two systems. These relationships allow the organization to build a more complete representation of the customer.
The difficulty arises when the evidence is ambiguous or the matching rules are not sufficiently understood. Two records may share an email address because they represent the same person, but a shared mailbox or a reused address can produce a misleading match. Two contacts may belong to the same company without being the same individual. A person may also change employers, making a previously valid relationship between an individual and an account outdated.
For this reason, identity resolution should not be judged only by how many records a platform can unify. The organization also needs to understand why identities were connected, which rules produced the relationship and what happens when those rules change.
A deterministic approach, based on explicit and verifiable matching rules, provides a clear foundation for this kind of control. When an anonymous identifier is linked to a known user following authentication, for example, the relationship has a specific explanation that can be inspected. Preserving the original identifiers and the history of the relationship also makes it possible to reconsider the profile without losing the underlying data.
These capabilities matter for marketing, but they become particularly consequential when customer profiles are used by AI applications. An incorrect audience membership may lead to an irrelevant message; an incorrect identity relationship can cause an application to attribute another person's history, permissions or account status to the wrong individual.
Identity resolution is therefore not simply a preliminary step in building a profile. It is part of the foundation on which subsequent applications rely, and it needs to remain understandable as the organization's data and business processes evolve.
A customer memory is not a collection of everything the company knows
The expression customer memory describes a useful way to think about this broader role. It refers to a persistent, evolving representation of a customer that brings together relevant identities, historical interactions, current business information and the context needed to interpret them.
Memory is a more appropriate concept than a static profile because customer information changes over time. An account that was active last month may now be suspended. A product issue may have been resolved, a contract renewed or a consent preference withdrawn. A new identifier may establish a connection that was previously unknown. The customer representation must reflect these changes without losing the history needed to understand them.
This does not mean that every record and event should be presented to every AI application. In fact, a useful customer memory requires the opposite: the ability to distinguish the complete data foundation from the information appropriate for a particular task.
A customer support assistant, for example, may need the current account status, recent support incidents, applicable service entitlements and the customer's relevant interaction history. A sales copilot may instead need contract details, renewal dates, account ownership and recent product adoption signals. A personalization system may require recent behaviour and preferences, together with the permissions governing how those signals can be used.
These applications can rely on the same underlying customer data without receiving identical views of it.
This separation also helps establish clearer boundaries around consent and purpose. A piece of information may be appropriate for resolving a support issue but not for commercial targeting. A preference may permit one kind of personalization while excluding another. If those restrictions are recorded in one system but ignored when data is assembled for an AI application, the organization may have the correct information somewhere in its architecture without actually enforcing it where it matters.
The customer data layer should therefore help ensure that the views supplied to applications reflect the relevant permissions and business rules. This does not eliminate the need for controls within the AI application itself, but it reduces the risk of leaving the interpretation of customer data and its permitted uses entirely to the model.
In this sense, customer memory is not an attempt to give AI an unrestricted view of the customer. It is a way of making the relevant context available in a form that can be understood, inspected and governed.
Why the customer profile must remain under the company's control
There is another consequence of this shift: the customer profile becomes an increasingly important part of the company's operational infrastructure.
When a profile is used primarily to build marketing audiences, the organization may be able to tolerate some dependence on the platform that creates and activates those audiences. Once the same profile supports customer service, sales decisions and AI-assisted workflows, dependence on an external system can become more consequential.
The company needs to know where the profile is maintained, how its attributes are derived and whether the underlying identity logic can be inspected. It should be possible to trace information back to its source, understand why records were connected and update the profile when a source system changes or a matching rule is corrected.
This is one reason why we believe customer identity and profile logic should remain close to the company's own data environment. A warehouse-native architecture allows the organization to build on its existing infrastructure rather than treating the customer representation as an asset that exists only inside a separate vendor platform.
That principle does not require every AI application to query the warehouse directly. Depending on the use case, an application may consume a profile through an API, a service layer, a cache or another operational interface. Nor does keeping the profile in the warehouse automatically solve every governance or security problem. Access controls, data quality, retention, consent and application-level safeguards still need to be designed and maintained.
The architectural objective is to retain control over the underlying customer representation while making it practical to use across different applications. The company should not have to choose between making customer data operationally useful and retaining the ability to inspect, govern and reuse it.
Building the missing layer between customer data and AI
This is the problem we are addressing with Krenalis. We are building a warehouse-native Customer Data Platform focused on identity resolution and unified customer profiles, with the aim of making fragmented customer data more reliable and useful across analytics, activation and AI applications.
The approach starts with the data companies already have. Events collected from websites and applications can be combined with records from CRM systems and other business tools, while identity resolution establishes relationships between identifiers according to defined rules. The resulting profiles are built directly in the company's data warehouse, allowing the organization to retain control over its data and the customer representation derived from it.
We see this as a foundation that can serve different needs as they emerge. Some companies may initially want to unify customer identities and maintain a consistent customer database for analysis and activation. Others may already have a mature data warehouse and marketing technology stack, and need an identity layer that works alongside their existing tools. As AI applications become more closely integrated with business processes, the same foundation can support the delivery of more consistent customer context to those applications.
These are related use cases, but they do not all require the same interfaces, update frequency or governance rules. Our view is that the customer data foundation should be reusable across them, rather than being tied to a single campaign workflow or application.
Krenalis is still evolving, and we do not claim that every aspect of this vision is already implemented. We are building the product around the capabilities we consider fundamental: collecting and integrating customer data, resolving identities, maintaining unified profiles and working within the customer's data infrastructure. Further development will extend the ways these profiles can be governed and used as requirements become clearer.
For us, the important distinction is between building another destination for customer data and providing a layer that makes the data already held by a company more coherent and useful. We do not intend to replace the warehouse, CRM, billing system, support platform or AI application. Each has its own responsibilities. The challenge is to ensure that they can work from a more consistent understanding of the customer without creating another isolated version of that customer along the way.
From campaign activation to customer memory
The evolution of CDPs should not be understood simply as a transition from marketing technology to AI technology. Marketing will continue to need segmentation, personalization and activation, and AI will not make those capabilities less relevant. The more important change is that customer data is becoming part of a wider range of operational processes, where the quality and interpretation of a profile can directly affect what a system says or does.
That creates a different set of expectations for the layer responsible for unifying customer information. It must do more than connect records and make audiences available to downstream tools. It needs to preserve the relationship between identities and their sources, make the resulting profiles understandable, account for changes over time and support the controls required by different applications.
The first two articles in this series explored why AI needs a reliable customer profile and what is involved in building one. This final article brings those ideas back to the role of the CDP itself. The issue is not whether every CDP should become an AI platform, nor whether a particular category of software will disappear. It is whether the customer data foundation can meet the requirements of applications that increasingly depend on a consistent, current and governed understanding of the customer.
For years, companies could treat customer data primarily as an input to reports, segments and campaigns, correcting inconsistencies when they became visible. As AI enters more operational workflows, the same inconsistencies can influence decisions and interactions before anyone has an opportunity to notice them. Reliable customer data is therefore becoming a prerequisite for putting AI into production, rather than simply a way to improve its results.
We believe the next generation of customer data platforms will need to reflect this change. They should help companies maintain a customer memory that evolves with their data, remains under their control and can be used by different applications without losing its meaning or its safeguards.
That is the direction we are taking with Krenalis. Not a bigger platform that tries to replace every component of the data stack, but a customer intelligence layer designed to make the information across that stack more coherent and dependable.
The CDP was built to help companies understand which customers to reach and how to reach them. As AI becomes part of the way companies serve customers, support employees and make decisions, it must also help them establish what they actually know about each customer, why they believe it, and how that knowledge can be used responsibly.
AI needs more than access to customer data. It needs a customer memory the company can trust.