Which Record
Wins?

I framed the last issue as a choice between two architectural directions: does the engagement layer belong inside the system of record, or beside it?

Two readers came back with versions of the same challenge. One pushed on the trade-off between clean integration and modular control. The other made the point that routing engines are often the easy part to sell, while integrating into the legacy CRM estate is where these programmes actually live or die.

They were right.

There was an assumption underneath my argument that I had skipped over. That there is a system of record.

In most large organisations, there isn’t. There are three or four systems containing different versions of customer truth. Each is authoritative for something, none is authoritative for everything, and for years we have dealt with that by putting a person in front of several screens and letting them work it out.

Agentic automation changes that. Remove the person doing the reconciliation and the disagreement between those systems does not disappear.

It moves into the conversation.

There is rarely one system of record

The phrase system of record makes enterprise architecture sound much tidier than it usually is. The CRM holds the relationship, billing holds the entitlement, case management holds the promise somebody made to the customer, and a policy or product platform may hold the thing they actually bought. Somewhere there may also be a data platform containing a beautifully governed golden record that everyone agrees is strategically important and nobody in the contact centre entirely trusts when a customer is shouting at them.

None of those systems is necessarily wrong. That is the difficult part. They were built to answer different questions.

The CRM may correctly say this is a high-value customer with a particular service history. Billing may correctly say the account is overdue. The case system may correctly show that somebody waived the charge last Thursday. The data platform may correctly contain yesterday’s consolidated position. Every record can be valid for the purpose it was designed for and still produce the wrong answer when you put all four into a live interaction.

We tend to call this an integration problem. Often it isn’t. The APIs can work perfectly and the integration can return every field you asked for. The harder question is what happens when those fields disagree.

Which record wins?

Your agents were hiding the problem

Watch an experienced agent working in a complicated estate. Four tabs open, sometimes six. They check the CRM, look at the bill, open the previous case, read the notes, and occasionally ask the customer a question because the customer is the only source that can resolve the contradiction. Then they make a judgement, and they may not even realise they are doing it.

After a few years in an operation, people learn which systems are trustworthy for which things. They know which status field does not refresh until overnight. Case notes get read before anyone touches an account with an open complaint. A suspended flag in billing means something different if a payment landed this morning.

None of that appears in the process map. It probably was not in the requirements document, and it certainly was not costed in the business case. But it is a control. The agent is acting as a human reconciliation engine between systems that were never given a formal hierarchy.

Which is one reason apparently straightforward automation programmes become difficult when they move beyond answering questions and start taking actions. You have not simply removed labour from the process. You may have removed the control that made the process work.

The contradiction was always there. The human was absorbing it. Now there is nobody left to do that quietly.

Three questions expose most of it

I have started thinking about this through three ownership questions. Not as a maturity model, and not as another assessment framework with red, amber and green boxes. Just three questions that become surprisingly uncomfortable when you ask them properly.

Identity. Who decides this is the same person? That sounds elementary until a customer changes an email address, calls from an unrecognised number, has several accounts, uses different names across products, or moves from authenticated digital into voice. Which system owns identity, and more importantly, which system is allowed to resolve disagreement about it?

Entitlement. Who decides what this person is allowed to have? A refund, a replacement, an upgrade, a credit, an appointment, access, a cancellation, compensation. The CRM might describe the customer, the product platform might describe their contract, billing might describe their financial state, and a policy engine may contain the actual rule. Which one has authority to say yes? This is usually where the arguments start.

Outcome. Who records what was agreed, and which other systems are required to believe it? This is the one I think we ask least often. If an AI agent tells a customer it has waived a charge, what makes that statement true? The conversation platform recording the decision, the case being updated, billing accepting the adjustment, or the ledger changing? And if two of those writes succeed and one fails, which version does the customer get to rely on?

Most estates can give you an answer for identity. They can have a long argument about entitlement. Outcome is where you discover whether anybody actually designed authority end to end.

Then it breaks at runtime

Once an AI agent is acting rather than merely retrieving information, these ambiguities stop being architectural abstractions and become runtime behaviour.

Latency is the obvious example. A live conversation does not have unlimited time to wait for your estate to decide what is true. Think in hundreds of milliseconds rather than several seconds for dependencies that sit repeatedly inside the conversational path. Those are illustrative design ranges rather than universal performance targets, but the principle holds.

If a legacy CRM regularly needs seconds to return what you need, you have choices: fetch it before the conversation reaches that point, cache it, use another source, or accept the delay. What you cannot do is draw the CRM directly into every turn of a real-time interaction and then be surprised the interaction feels slow. At that point the CRM may still be the system of record. It just is not the system that can practically sit in the conversational path.

That immediately creates the next problem. You cache the entitlement because the live system is too slow, the customer changes something, and your AI acts against a version of reality that was correct thirty seconds ago.

Then there is write-back. Two systems both accept the update, neither has been designated as the one that wins, and everything appears successful until the overnight reconciliation decides they disagree. That was irritating enough when a human entered the update. It is more serious when an autonomous system has already told the customer the matter is resolved.

Underneath all of it sits audit. When an AI agent makes a commitment, which record proves the commitment existed? The transcript, the tool invocation, the CRM activity, the case, or the financial transaction. If those records disagree, what would you put in front of a complaint investigator six months later and say: this is what happened? That answer needs to exist before the AI starts making decisions, not after the first disputed one.

Handover is where all of this becomes visible

The worst version of the problem is often the moment automation hands the customer to a person.

What actually arrives? Usually a transcript nobody has time to read and an intent label. Rarely the entitlement decisions the AI has already made, the systems it checked, or what failed. Almost never a clear statement of whether the human is authorised to rely on any of it.

Because if the person answering the escalation has to re-establish identity, re-check entitlement and reconstruct the state of the interaction, the automation did not remove that work. It moved it, and probably made the experience worse while doing so. The customer has already completed discovery once. Decisions have already been taken. Now the human starts again.

That is why I think so many conversations about context passing are too shallow. Passing a transcript is not the same thing as transferring state. State includes what has been established, what has been attempted, what failed, what has been promised, and what authority the next participant inherits.

If the human contradicts what the AI just told the customer, that is not primarily a handover problem. It is an authority problem. Two parts of the same service have reached different conclusions about what is true.

Stop looking for one winner

The answer is not to declare that one enormous platform owns everything. In most established enterprises that is neither realistic nor desirable.

Instead, designate an authoritative store per question. Identity is authoritative here, entitlement there, outcome committed somewhere else. Everything downstream of those decisions is either a consumer or a cache.

That language matters. If a copy of entitlement data sits inside the engagement platform to make the latency work, call it a cache. Then define how fresh it is allowed to be, what happens when it cannot be refreshed, and which decisions can safely be taken from it rather than requiring a live check.

Do the same for writes. What is the authoritative transaction? What happens when a secondary write fails? Does the customer-facing commitment wait for every system to complete, or is there one successful write that makes the commitment real while everything else becomes eventual consistency?

Write down the conflict-resolution rule. Write down the latency budget. Write down which system wins for each question.

Once you have done that, the original question gets much easier. Inside or beside stops being an architectural preference and becomes a consequence of decisions you have already made, because now you know what the engagement layer actually needs from everything around it.

Write the assumptions, not just the answer

This comes back to an argument I made in There Is No Best Platform. Architecture decisions have a shelf life, and the useful record is not that we chose Platform A. It is: we chose Platform A because identity is authoritative in this service, entitlement is owned by this platform, outcomes are committed here, we require this latency, and these are the reconciliation rules when those systems disagree.

That survives a replatform. It survives a new CRM. It survives somebody deciding the customer data platform should become genuinely operational rather than merely analytical. And it tells the next architect which assumptions they are allowed to challenge. A decision record that says the platform won the procurement scorecard tells them almost nothing.

The system of record was never really one system. It was a collection of responsibilities we happened to describe with one convenient phrase. Human agents made that ambiguity survivable because they could reason across it. As we automate more of the interaction, those decisions have to become explicit.

Not because AI creates the conflict. Because AI removes the person who used to hide it.

When you last unpicked an estate, which system turned out to be authoritative, and had anyone written that down, or did you have to work it out?