For forty years, customer data was a centralisation project.
In an agent era of distributed sources, that may be the constraint.
Every architecture diagram for customer data, for forty years, has started the same way. Many sources flowing into a single platform in the middle. One centre. One truth. Question the architecture in a planning meeting and you will be looked at like you have just questioned gravity. The architecture has been so consistent that nobody asks whether centralisation is necessary; only which vendor builds the centre best. That is the question this piece asks.
This is not because the architects were wrong. Given the constraints they worked under, centralisation was the only path to coherent customer data.
Three constraints made it inevitable. Compute was expensive: live queries across many systems were not affordable. Networks were slow: pulling data on demand blew through every latency budget. And SQL, the dominant query interface, required schema reconciliation up front. Every system had to agree on what a customer was first. The only path was to bring the data together. The record this approach produced never quite settled, but for forty years it was the best available option.
Three things have changed in a short period. Compute is now plentiful enough to query live at scale. Networks are fast enough to make distributed access work. And the deepest change: the dominant query interface is no longer SQL. It is the agent.
An agent does not require schema reconciliation. It reads structures it has never seen, reasons across them, composes a coherent answer in the moment. The protocol layers that support this are taking shape: Anthropic's Model Context Protocol (MCP), launched November 2024, and Google's Agent-to-Agent Protocol (A2A), launched April 2025, both now under the Linux Foundation. MCP grew from 100,000 server downloads to 97 million monthly by late 2025, across 9,400 public servers. A2A is backed by more than 150 organisations.
None of this is yet settled. As of mid-2026, both protocols are barely eighteen months old. Whether the layer consolidates, or fragments under vendor pressure, is a question the next two years will answer. The direction is clear. Agents do what SQL could not: traverse, reason and act across data that has not been pre-arranged.
The centralisation assumption was always about the inadequacy of the previous query interface. The interface has changed.
Governance does not get to relax. Identity, policy, audit and access control are required at least as much as before, because the action no longer lives behind one team's boundary. What changes is the location of the discipline: it moves from the centre to the edges, via shared primitives every agent and application must consult.
This is the pattern Zhamak Dehghani named the data mesh in 2019: domain-driven ownership of data, data as a product, a self-serve platform, federated computational governance. The agent era makes the mesh workable beyond the largest enterprises, because the agents traverse it, not the analysts.
None of this is hypothetical. Platforms built on the principle already exist: action at the boundary, identity and policy at the edges, the record optional. They tend not to be the relabelled CDPs of the past two years, but infrastructure built for regulated execution from the start, on the substrate the operator controls.
A skeptic will say the complexity has not gone away, only moved. Decentralisation has its own costs: governance at the edges is harder than at the centre, and shared primitives must be agreed across teams that have historically owned their own.
The honest reply is that the cost trade has changed. The cost of centralisation was never bounded: it compounded with every new channel, source and acquisition. The cost of decentralisation is bounded, and is now decreasing. 31 per cent of enterprises already run at least one agent in production, with regulated industries leading. Gartner forecasts that share will rise from under 5 per cent in 2025 to 40 per cent by end of 2026. The protocol layer is no longer purely experimental, even if it is not yet settled.
The inversion also helps residency. Residency is, at heart, a question of whether data crosses a border. Data that does not move does not cross. The architectures that age well will be those with reliable identity, policy and audit primitives, applied wherever the action happens.
| Discipline | At the centre (the past) | At the edges (next) |
|---|---|---|
| Identity | Embedded in the central customer record. | Provided by a shared identity service every agent and application consults. |
| Policy | Applied to access of the central record. | Applied to every action, wherever the action fires. |
| Audit | Logged at the centre when the record was read or exported. | Produced where the action happened, in the same motion as the act. |
| Action | After the centre settles, via export to a downstream tool. | Where the signal lands, against live state. |
| The record | The source of truth. | A cache, useful for analytics. No longer load-bearing. |
This is the inversion of a forty-year rule. The old rule: move the data to where the decision lives. The new rule: move the decision to where the data already is. The agent reasons across whatever is current. Identity, policy and audit are the spine. The action happens where the signal lands. The record catches up afterwards, if at all.
The data does not need to move. The architecture has been moving it for forty years out of habit.
The substrate that emerges is already being relabelled. Composable data fabric. Agentic CDP. AI-native customer platform. The relabelling tends to outrun the architecture. The buyer who keeps their head will look past the label and ask where the action actually happens, and whether the data had to move. The architectures that pass that test have four properties the relabelling does not: an open architecture, so the customer's agent reads on terms the operator publishes; reason-coded decision logs as a by-product of every decision, exportable in the regulator's format; outcomes-aligned pricing against decisions made rather than seats licensed; and operator-controlled deployment, so neither the data nor the audit trail crosses a vendor's boundary.