CRM Is Data at Rest, CX is Data in Motion

Two executives, mid-argument. Each arguing their roladex is more important than the others. Behind them, unnoticed, an AI Agent flows past in red. "Mark my words," the first one is saying, with the conviction of someone who has read the Forrester report twice, "whoever owns the record owns the customer."

Last time, I argued the convergence debate is the wrong debate. Now the harder line for the convergence camp. Even if you win that argument, you have only unified two stationary systems. CRM and CCaaS were both designed to make data sit still. That is the one thing agentic CX cannot afford.

So let me say it plainly. Data at rest cannot power data in motion. The substrate that can — MCP, A2A, and the orchestration layer that lives between the boxes on the org chart — is what makes the platform-ownership question structurally irrelevant.

What CRM was built to do

CRM is one of the most successful pieces of enterprise software ever shipped. Strip away the modules, the AI bolt-ons, and the consolidation rumours, and the underlying object model has barely changed since the late 1990s. Account, contact, opportunity, lead, activity, case. A system designed to capture what happened — accurately, consistently, in fields a CFO can audit — and report on it.

That was the right design for the problem CRM was solving. Sales operations needed pipeline visibility. Boards needed defensible forecasts. Account teams needed a single place to record who they had talked to and when. The genius of the architecture was its ruthless prioritisation of state over flow. A clean opportunity record at end of quarter is worth more to the system of record than a messy real-time feed of every signal that produced it.

A CRM, in other words, is a photo album. Carefully composed, chronologically ordered, useful in retrospect. What it cannot do, what it was deliberately not designed to do, is tell you what is happening now. It cannot tell you what the customer meant, how they felt, what they tried on three other channels before picking up the phone, or what they are about to do next. None of that is in the schema. None of it can be in the schema, because the schema was the point.

This is not a flaw of any individual CRM vendor. It is the operating premise of the category. And it is the reason the convergence debate, on its current terms, is solving the wrong half of the problem.

Why agentic CX needs data in motion

Picture the work an actually-useful customer service agent has to do. Authenticate the caller. See what they tried in the app five minutes ago. Read the email thread they opened last Tuesday. Notice the bot already failed them once. Decide whether to refund, escalate, schedule a callback, or just answer the question. Take that action across three different systems. Confirm it back.

None of that is a record-keeping problem. All of it is a context problem.

Now imagine the same work being done by software. The list does not get shorter; it gets longer, because the software cannot rely on a sympathetic human pattern-matching across the gaps. Every signal has to be addressable. Every action has to be authorised. Every handoff has to carry state across system boundaries that were never designed to carry it. The current workaround is duct tape: integrations between systems that were not built to share a data model, middleware connecting middleware, AI features bolted onto a 1990s ticketing schema.

If all of that were working, the symptoms would not be quite so visible. They are visible. The Forrester CX Index 2025 reports that customer experience quality has declined three years running. That is not an AI problem. It is a flow problem the AI is being asked to solve from inside the systems that cause it.

Here is the part that should bother any CCO reading this. When the systems cannot share the customer, the customer ends up sharing themselves. Repeatedly. Once with the bot, once with the agent, once again on the transfer. The deal you have made, without realising you made it, is that the customer pays the integration tax in time, frustration, and goodwill. Bolt-on architectures do not eliminate that tax. They redistribute it.

This is the camera feed the photo album cannot give you.

The substrate is already here

The good news, if you can call it that, is that the architecture for data in motion has already been named. It is not a platform. It is a pair of protocols.

The Model Context Protocol (MCP) gives an agent a standard way to read context and take actions across whatever system actually holds them. Agent-to-Agent (A2A) gives one agent a standard way to talk to another, across vendor boundaries. MCP is the vertical plumbing: agent to tool, agent to data. A2A is the horizontal: agent to agent. Together they describe an architecture in which the substrate is shared and the apps sit on top of it, exactly the inversion of the current architecture, in which every app brings its own substrate.

This is not a 2027 conversation. By April 2026, MCP records 97 million monthly SDK downloads and more than 10,000 published servers, Cloudflare has shipped an enterprise reference architecture with SSO, governance, and audit baked in, and Gartner forecasts 75 percent of API gateway vendors will support MCP by year-end. A2A passed its first anniversary under the Linux Foundation with more than 150 supporting organisations and production deployments across major cloud platforms.

The point is not the specs themselves. The point is what they do to the platform debate. Protocols do not care whose login screen the customer goes through. They do not care whose name is on the contract. They route context to whichever agent, human or otherwise, is in the best position to act on it. When that becomes the architecture, "who owns the customer record" is a question about a filing cabinet nobody is opening any more.

What you're actually buying

The platform debate does not get resolved. It gets bypassed. IDC's Future Enterprise Resiliency Survey reports that more than 80 percent of organisations are reconsidering their packaged-app investments in light of AI agents. That is not a convergence problem. That is a question about whether packaged apps are the right shape of investment at all.

For a CIO, this is the moment when the procurement spreadsheet starts to feel different. The seven-figure CCaaS contract you renegotiate next quarter is being priced against a static field of competitors. By the time the renewal lands, half of those competitors will be selling against an architecture that does not yet have a Magic Quadrant. The companies winning are not the ones picking sides in the convergence debate. They are the ones quietly deciding which of their CX surfaces will sit on the substrate, and which will become legacy under it.

The convergence camp will not be wrong, exactly. They will be early. Or rather, they will be late to the right argument and early to the wrong one. Salesforce knows this. Agentforce Contact Center is less a category move than a hedge, a way to buy time before the architecture that replaces convergence arrives.

A CCaaS contract is a statement about the shape of your customer experience for the next three to five years. So is the CRM consolidation memo on the next page. So is the marketing-cloud add-on after that. Each one assumes the architecture you're buying into will still be the right shape when the renewal comes around.

The question I would put to any CIO or CCO reading this: are you buying a platform — a thing your customers and your agents have to learn the shape of — or are you shipping your org chart? Every CX platform I have ever seen built reflects the org chart that bought it, not the journey the customer took. That has been a tolerable inefficiency for thirty years. The substrate makes it intolerable.

You can decide. The convergence debate is loud enough to drown out the decision, but the decision is yours.