The Customer Record Is Not the Customer Relationship

An airline might know a passenger's loyalty status, recognise that her flight has been delayed, see that she has been browsing an upgrade and understand that she is travelling with her family. Yet these signals may live in separate systems, each supporting a different team with a different objective. Customer service sends an apology. Marketing sends an upgrade offer. Both systems have access to useful information, but neither understands the situation as a whole.

For years, the customer data platform promised to solve this problem by bringing customer information together into a unified profile. That was meaningful progress, but a profile only takes us so far. Knowing who someone is and what they have done is not the same as understanding what is happening now, what the organisation has already tried or what it should do next.

This distinction becomes much more important when software starts making decisions rather than simply providing information to the people who make them.

Databricks' CustomerLake announcement is an interesting example of this shift. By bringing customer profiles, identity resolution, audience building, AI models and agents into the same data foundation used for analytics and machine learning, Databricks is proposing something more significant than another customer data platform. It is moving towards a system that can interpret customer context, determine what should happen next and coordinate the actions that follow.

I think this points towards a broader change in enterprise architecture.

For years, the industry has focused on data gravity. Where should enterprise data live? The rise of cloud data platforms and lakehouses has provided a compelling answer. Increasingly, organisations want their data governed within a shared foundation rather than duplicated across disconnected applications.

But solving the question of where data lives introduces another question. Which system gets to decide what happens next?

I think this is where the next architectural contest begins. The advantage will increasingly belong to organisations that can connect trusted information to coordinated decisions, while retaining control over how those decisions are made.

The difference matters because a data platform that informs a decision is fundamentally different from one that participates in making it.

Consider what this means for the customer relationship. A traditional customer data platform might identify a high-value passenger, place her in a loyalty segment and make that information available to a marketing campaign. An agentic system needs to understand considerably more. It needs to know about the delayed flight, the unresolved service issue, the offers already presented and the customer's current circumstances. It also needs to understand what the business is permitted to do.

The result is not simply a more complete customer profile. It is a system with a working memory of the relationship.

That distinction is important. A record describes what the organisation knows. A working memory also captures what it has done, why it acted, what happened afterwards and how those outcomes should influence future decisions.

Without that memory, introducing agents can make existing fragmentation considerably worse. A service agent might be trying to resolve a complaint while a marketing agent attempts to increase revenue. Each can pursue its objective correctly, yet the combined experience can be entirely wrong. The problem is not necessarily the intelligence of either agent. It is that neither has enough context to understand the consequences of its actions for the wider relationship.

We already see versions of this problem in conventional software. What changes with agents is the speed at which it can happen and the number of decisions involved. A coordination failure that once unfolded over several days can now produce conflicting actions across multiple channels in moments.

This is why I think persistent context is becoming a fundamental architectural concern.

The organisation needs a reliable way to maintain what it knows, what it has attempted, what it has learned and what it is allowed to do next. That information must be available to the systems making decisions, not trapped in documentation or isolated applications.

There is another consequence of this shift that is easy to overlook. It changes the way we think about the work itself.

Marketing has traditionally been organised around campaigns. Teams define an audience, create content, select channels, establish a schedule and measure the results. Even sophisticated automation relies on people anticipating possible behaviours and encoding the appropriate responses into workflows.

Agentic systems introduce a different operating model. Rather than specifying every step, a marketer can define an objective, a budget, an eligible audience and the constraints within which the system must operate. Agents can then evaluate changing circumstances and recommend or select actions as new information becomes available.

The campaign may remain the way teams organise their work, but the individual decision becomes the more important unit of execution.

Was this the right action for this customer at this moment? Which information influenced it? Was the action permitted? Did it create value, and what should the system learn from the result?

These questions also expose a weakness in how organisations measure AI performance. A system can increase conversions while damaging customer relationships. It can reduce churn by contacting customers so frequently that it creates dissatisfaction. It can optimise engagement by discovering that provocative content generates more clicks, even when those clicks do little for the business.

The system may be working exactly as designed. The problem is that the objective was incomplete.

This is one of the reasons I believe agentic systems require a more deliberate approach to evaluation. It is not enough to establish that an agent can execute a task successfully. We need to understand whether its decisions produce the outcomes the organisation actually wants, including consequences that may not appear in a short-term performance metric.

The same principle applies to the architecture supporting those decisions. There is a temptation to assume that if data, models and governance are consolidated within one platform, decision-making should be centralised there too. I don't think that necessarily follows.

Some decisions need to happen close to the interaction. A website may need to respond in milliseconds. A customer service platform may possess operational context that is unavailable elsewhere. A sensitive financial or healthcare decision may require additional controls or human approval. Other decisions, such as coordinating contact frequency across marketing channels, benefit from a broader view of the customer relationship.

The architecture needs to accommodate these differences.

A platform such as CustomerLake could provide the foundation for governed customer context and shared intelligence, while specialist applications retain responsibility for decisions or execution where they have a clear advantage. The important distinction is that shared intelligence does not require every decision to be made in one place.

What matters is that decision authority is explicit.

Which system can make a decision? Which system can execute it? What happens when two agents pursue conflicting objectives? How does one agent know that another has already acted? When something goes wrong, can the organisation reconstruct the information, policies and approvals behind the decision?

These are engineering questions, not simply product configuration questions.

A natural-language interface does not make them disappear. It may make sophisticated technology easier to use, but a simple prompt can conceal a complicated decision process. Users still need to understand which audience was selected, how identities were resolved, whether consent was enforced and why the system recommended a particular action.

The more autonomy we introduce, the more important these controls become.

An incorrect identity match can combine the histories of two different people. An outdated consent record can allow an action that should never have occurred. Delayed operational data can cause an agent to recommend something that is no longer appropriate. When these errors influence a continuous decision-making process, they can propagate across channels and compound over time.

The organisation therefore needs to know not only what its data contains, but where it came from, how reliable it is, whether it is current and whether it can be used for the decision in question. It also needs the ability to reconstruct consequential decisions, enforce constraints and reverse actions where possible.

This is where the distinction between an impressive product announcement and a production-ready enterprise capability matters. The Credera ebook describes CustomerLake as being in private preview at the time of writing. Its real-time performance, usability for marketers, coordination across platforms and ability to deliver measurable business value therefore remain things that need to be demonstrated.

The direction is compelling, but the architecture alone does not establish that the operating model works.

There is also a risk that consolidating more intelligence within a single platform creates another form of dependency. Enterprises should retain the ability to use different models, identity providers, activation channels and measurement approaches where they provide genuine value. The goal should be to reduce unnecessary complexity without surrendering the flexibility to evolve.

I see a direct parallel with what is happening in software engineering.

The conversation about AI-native engineering often focuses on how quickly developers can produce code. But code generation is only one part of software delivery. An effective engineering system needs to understand why a change is required, which architectural decisions constrain it, what has already been attempted and whether the outcome improves the product.

A repository contains the code. It does not, by itself, contain all the context required to make good engineering decisions.

This is where Engineering Intelligence becomes important. The opportunity is to combine the knowledge of engineers, AI systems and the organisation into a capability that continuously learns from engineering work and improves how future work is performed.

That requires persistent project and architectural context, reusable organisational knowledge, explicit engineering standards and evaluation mechanisms that connect decisions to real outcomes. Agents become more useful when they can operate within that environment, rather than treating every task as an isolated problem.

Across customer experience and software engineering, the underlying challenge is similar. We need to move beyond systems that simply store information or execute instructions towards systems that can use context to make better decisions, coordinate their actions and learn from what happens.

The organisations that achieve this will not necessarily be the ones that centralise the most functionality or deploy the largest number of agents. They will be the ones that understand which decisions matter, what information those decisions require and how to make the resulting behaviour reliable.

That is where I think the real opportunity lies in the shift from data platforms to intelligence systems.

The customer record helped organisations recognise people across disconnected applications. The next challenge is to understand the relationship well enough to act appropriately, and to remember the consequences of those actions.

The same principle applies across the enterprise. Data becomes substantially more valuable when it informs decisions. AI becomes substantially more valuable when those decisions improve through context, feedback and experience.

The goal is not simply to build systems that know more.

It is to build systems that become better at deciding what to do with what they know.