This article is adapted from “The CDP was built for campaigns. AI needs customer memory.”, originally published on the Krenalis blog.
Customer Data Platforms were built to solve a very practical problem: customer data was scattered across too many systems, and marketing teams needed a way to bring it together.
That made perfect sense. If you want to segment an audience, personalize a message or activate a campaign, you need a reasonably coherent view of the customer.
What is changing now is not that those use cases have disappeared. It is that the same customer data is starting to be used in a very different context.
AI assistants, copilots and automated workflows do not just need to know who belongs to a segment. They may need to understand what is happening with a customer right now, how that situation evolved, and which pieces of information can actually be trusted.
That is a different kind of requirement.
Imagine a customer contacting an AI assistant because they cannot access a service. The CRM says the account is active. The billing system shows an overdue payment. The support platform has an unresolved technical issue.
None of those systems is necessarily wrong. They are simply describing different parts of the same situation.
For a marketing campaign, that distinction may not matter very much. For an AI assistant trying to explain why access is blocked, it matters a lot.
This is where the idea of a unified customer profile starts to become more interesting. It is no longer only about combining records. It is also about preserving enough context to understand what those records mean.
Connecting an AI application to multiple systems does not automatically create that understanding. The model may receive more data, but it still needs to know which information is current, which is historical, which system is authoritative for a given field, and whether two records actually refer to the same person.
These are not really AI problems. They are data problems that become more visible because AI is now sitting closer to the customer.
Identity resolution is a good example.
In theory, it sounds simple: match records that belong to the same customer. In practice, the rules can become complicated very quickly. A CRM contact, a billing account and a product user may all use different identifiers. Two people may share an email address. A person may move to a different company but still exist in the historical data under the old relationship.
When customer data is mainly used for reporting or campaign segmentation, a bad match is already a problem. When an AI application uses that same profile to answer a question or trigger an action, the consequences can become more immediate.
This is one reason why I find the idea of customer memory useful.
The term should not be understood as “store everything forever.” It is closer to the idea of maintaining a customer representation that evolves over time without losing the distinction between current state and history.
Take a customer who was on a paid plan last year and is now on a free plan. The old subscription is still part of the relationship. It may be useful when looking at previous usage or support interactions. But it should not be treated as evidence that the customer still has access to paid features today.
A useful customer profile needs to keep both pieces of information without flattening them into one.
That may sound obvious, but it becomes important when these profiles are used as context for AI systems. The quality of the model cannot compensate for a profile that mixes old and current states or combines records incorrectly.
The same applies to the amount of information we expose to an application.
A support assistant does not need the same view of the customer as a sales copilot. The support assistant may care about current entitlements, open tickets and recent incidents. The sales application may care more about contracts, account ownership and product adoption.
The underlying customer data can be shared, but the context should still be shaped around the task.
This is also where warehouse-native architectures become interesting.
If a company already has a data warehouse where customer, product, billing and support data eventually comes together, it can make sense to build the customer profile there rather than maintaining yet another isolated copy of the data.
That does not mean the warehouse solves everything. The difficult part is still the logic that turns raw records into something usable: deciding how identities are resolved, which attributes are kept, how conflicting values are handled and how changes propagate over time.
The advantage is that those decisions can remain close to the company’s own data and be inspected rather than hidden inside a black box.
For AI applications, that matters.
If an assistant gives the wrong answer, it is useful to be able to trace the problem back. Was the source record wrong? Was the identity match incorrect? Was an old value treated as current? Did the application receive a field it should not have used?
A customer profile becomes much more useful when these questions can actually be answered.
This is the direction behind Krenalis. We are building a warehouse-native CDP focused on customer data integration, reversible identity resolution and unified profiles inside the customer’s own infrastructure.
The goal is not to replace the warehouse, CRM, billing system or AI application. Each of those systems still has its role.
The customer data layer sits in between, with the aim of making the customer representation more consistent and reusable across different applications.
Krenalis is still evolving, and not every part of this vision is implemented yet. But the underlying idea is becoming clearer as more companies experiment with AI on top of customer data.
The interesting question is no longer just whether a company has enough data about its customers.
It is whether that data can be turned into a representation that an application can use without losing the context that gives it meaning.
That is the shift from customer data to customer memory.
Top comments (1)
history without flattening it is the line i'd steal. most profiles treat the past as a current state that lost an argument. 'paid last year, free now' as two surviving facts instead of one updated row is the kind of small change that fixes a lot of wrong answers.
the part i keep thinking about: the trace leads back to the team that wrote the profile-building logic three quarters ago and moved on. inspectable is one thing, investigated is another.
builder-side question: when the memory is right but the read of it is wrong, who owns that? the model, the profile, or the person who wired them together?