You Own Your Data. Your Vendors Own the Keys.
How business leaders should think about the ‘transition’ architecture from their current tech landscape to an AI native future state
A mid-market operator who looks honestly at the systems running the business will find something closer to sediment than to architecture. There is the ERP bought a decade ago, and the CRM bought later to cover what the ERP could not see. There are three or four spreadsheets that quietly run reconciliation and pricing, because no purchased system ever fit the real process. There is an Airtable base a clever manager built, a Notion workspace holding the institutional memory that lives nowhere official, and a reporting warehouse that some people trust and most people work around. Each of these was a reasonable answer to the problem in front of someone at the time. Together they answer nothing, because the picture of the business is split among them and held whole by no one.
Into this the software industry is now pouring artificial intelligence, and for the buyer the effect has been more tools rather than more clarity. The CRM grew a copilot. The productivity suite grew one. So did the help desk, the accounting package, and the marketing platform. Each assistant reasons capably over the slice of the business its parent application happens to hold, which is exactly why none of them can answer a question that crosses two systems. The leader who expected AI to dissolve the fragmentation has instead watched it acquire a voice in every window.
It is worth asking why this keeps happening, and why it will keep happening until someone changes the order of the layers. The answer starts with the constraint that built the current landscape.
The warehouse was a confession
For about three decades the dominant fact about business software was that producing it was slow and expensive. That made buying a packaged application the rational default for almost everything that was not the firm’s own product. The decision was sound on its own terms. What went unexamined was that every packaged application bundled three things with no real reason to travel together: the model of the data, the logic that acts on it, and the interface a person uses to touch it. Because the data model lived inside each vendor’s schema, every system the firm bought became another enclosure of truth that knew its own contents and nothing else.
The data warehouse was invented to answer the one question no operational system could: what is actually happening across the business. It was useful, and it was also an admission. A firm only needs to copy its data somewhere separate to understand itself once the systems doing the work have become impossible to read together. The warehouse never fixed the fragmentation. It produced a lagging, read-only photograph of it, accurate as of last night’s load and steadily less trusted the longer it went unchecked. And it could not be acted through. A copy of the truth is something you read; the business runs on the original.
The same problem, one layer higher
The current wave of vendor intelligence reproduces this arrangement one level up, at the point where reasoning happens. An assistant bound to one application can ground its answers only in what that application can see. Microsoft’s Copilot reasons over the Microsoft Graph and a semantic index, limited to what the signed-in user already has permission to open inside the Microsoft boundary. The capability is real and the limit is structural, which is why observers note that the product wins on ecosystem lock-in rather than on the quality of the underlying model.
The more telling move is the contest now under way to become the unifying engine, because every large vendor has worked out that whoever owns the layer where context is assembled owns the customer. Salesforce renamed Data Cloud to Data 360 and now presents it as the intelligence foundation for its agents, ingesting and harmonising data from any source, and it spent billions on Informatica to fold data cataloguing, governance, quality, and master-data management into the platform. Microsoft, from the other direction, has begun shipping federated connectors that pull live data from hundreds of outside systems into its own grounding layer.
This is the warehouse argument coming back in a more expensive form. The vendor whose application fragmented the firm’s data is now selling the platform that promises to gather all of it back, and the gathering still happens inside that vendor’s perimeter, on that vendor’s pricing and roadmap. A firm that takes the offer has not escaped the enclosure. It has moved to a larger one and paid for the privilege.
The sharpest illustration arrived in the spring of 2026. SAP, whose systems hold the payroll, financial-close, and supply-chain records of much of the corporate world, published a new API policy. One clause prohibits using its interfaces to connect autonomous or generative AI systems that plan, select, or execute sequences of API calls, except through routes SAP endorses. Enforcement began at the protocol layer in June. The endorsed routes are SAP’s own: Joule, Business Data Cloud, and the Agent Gateway. So a customer’s agents can now reach its own SAP data only through tools SAP has blessed, while SAP’s own assistant faces no such limit. SAP defends the change as a matter of platform stability and protection of its domain knowledge, and the engineering concern is real, since a single agent loop can fire thousands of calls at a system built for human-paced work. The commercial effect stands regardless. By one industry survey, Joule was in production at around three per cent of SAP customers, while about three-quarters of AI-active SAP enterprises were already running Microsoft Copilot. The policy cuts the direct path to the tools nearly all of them had chosen.
Not every incumbent has gone the same way. In the same quarter Salesforce described an architecture it calls Headless 360, which exposes its data, workflows, and actions through APIs and tools that outside agents can call directly, with no proprietary interface standing in the way. Within three months, two of the largest enterprise vendors had taken opposite positions on a question their customers had rarely had to face: whether a firm’s own operational record can be reached by the agents the firm chooses, or only by the agents its vendor permits.
That question is the one the whole transition turns on, and it exposes what the fragmentation has really been about. A firm’s data, the record of its products, suppliers, customers, and the particular way it does the work, is its own asset and its one advantage that does not commoditise. Yet the usual arrangement leaves that asset spread across the vendors whose software happens to touch it, each free to decide what may read it, what retrieving it costs, and which intelligence may act on it. The firm holds the title to its moat while a shifting set of vendors holds the keys. For as long as it accepts that, it will keep meeting its own business in fragments. It will wait on roadmaps, renewal terms, and approved-partner lists to do things it ought to be free to decide. And it will spend years negotiating with its software for permission to use what it already owns, which is precisely the attention the business needed for its customers, its operations, and the work technology was supposed to make easier.
What actually changed, and what did not
The constraint that justified the old arrangement has weakened. Producing software, in the narrow sense of writing working code, has become far cheaper and faster, which removes the original reason to accept a vendor’s data model just to get the vendor’s logic and screens. It does not follow that building custom systems is now cheap. A leader who hears the first point and concludes that everything can be built in-house has misread it. The cost did not disappear; it moved. The hard part of software was never the typing. It was integrating across systems, governing who may see and change what, encoding a particular firm’s hard-won judgement, and keeping all of it correct as the business shifts underneath. Those costs are as high as ever. What changed is that they are no longer hidden inside the cost of production, so a firm can now decide deliberately where its real advantage sits, instead of inheriting that decision from a vendor’s packaging.
Inverting the order of the layers
The destination worth aiming at is not a better hub bought from a larger vendor. It is an arrangement where the firm’s own context sits at the centre, as a coherent, current, write-capable model of the business, and the systems of record, the agents, and the interfaces all attach to that centre rather than each holding a private fragment. A single source of truth here does not mean one giant database into which everything is dumped, an idea that deserves the scepticism it usually gets. It means one current semantic model that agents can both read and act through, so that the picture the business uses to understand itself and the system it uses to operate are the same thing, rather than one always trailing the other.
With that centre in place, the other layers take cheaper roles. Commodity capability, the functions every competitor can buy on the same day for the same price, should be bought, precisely because owning it confers no advantage. Agents reason and act over the unified context instead of over isolated slivers, which is the only setup in which they can finish work that crosses the seams of the old stack. The interface, long treated as the expensive and permanent piece, becomes the lightest layer. It can be generated for a given role and job, and regenerated when the job changes, because once the model and the logic sit beneath it, a screen is cheap.
The transition is a shift in the centre of gravity
No firm starts from open ground. Payroll is running, a renewal is due in March, and the warehouse three people trust cannot simply be switched off. So the move from the legacy landscape to the native one should not be treated as a migration with a cutover date, nor as a multi-year programme that freezes the business while it runs. It is better seen as a gradual shift in the centre of gravity. Today the applications are the centre, and any unified view is a downstream copy. The aim is to reverse that weighting. It is reached not by one decision but by building each new thing on the side of the unified context, until enough of the firm’s weight rests there that the legacy systems have quietly become replaceable rather than load-bearing.
This reframing dissolves the false choice between a heroic programme and doing nothing, and it is what makes a small set of standing principles useful. The transition is decided less in the boardroom than in a few hundred ordinary choices made by people who will not have the chief executive in the room. The principles are how those choices bend in one direction.
Treat data extractability as a procurement requirement, not a feature. The test for any system the firm is considering is whether the business can retrieve its own data and events, in full and in real time, without the vendor’s permission. A system that traps its data should be disqualified whatever else it does well, because that one property does more than any other to decide whether the stack fragments further.
Stop solving problems at the application layer that belong at the context layer. A reporting gap prompts the purchase of a reporting tool; a handoff gap prompts a workflow tool; each purchase deepens the fragmentation it was meant to relieve. The discipline is to ask first whether the real problem is missing unified context, and where it is, to invest there rather than buy another island.
Build the layer that compounds and buy the layer that commoditises, and keep the two clearly apart. The recurring error is to spend scarce capital building something a competitor will buy off the shelf next quarter, or to hand a vendor the layer that holds the firm’s own advantage.
Stop the bleeding before dressing old wounds. New context should flow into the unified layer from the day it exists; backfilling history is a slower, partly optional effort. Programmes that reverse this spend their first year migrating the past while the present keeps fragmenting, so the destination recedes faster than they approach it.
Make everything new feed the centre. Each new tool, agent, or automation either reads from and writes to the unified context, or it becomes one more island. The standing rule that nothing new may create a private data store is what actually shifts the centre of gravity.
Sequence by where context is richest and most trapped at once. Start where the firm already holds deep proprietary knowledge locked inside a system that hoards it, since that is where unification returns the most and where the advantage is most exposed today. Resist starting merely where the work looks easiest.
Judge progress by the decisions an agent can complete end to end, not by the number of systems integrated. Integration counts plumbing. The measure that tracks the centre of gravity is whether a role’s actual job can now be done by reasoning and acting through the context layer, without a person stitching across screens.
The moat, and what it costs
The reason to do any of this is that almost everything else has stopped conferring advantage. The models are shared across competitors, the applications are shared, and the interfaces are drifting toward free, so the off-the-shelf assistant hands every firm in a sector the same capability on the same morning. The one layer that does not commoditise, and the only one that compounds, is the proprietary context a firm has built up about its operations, customers, history, and judgement. Fragmentation attacks that asset directly: an agent allowed to see one system is as limited as an employee allowed to open one filing cabinet, and the warehouse, a stale copy, defends nothing because it cannot be acted through. To own the advantage in any real sense is to hold the context layer itself, rather than leave it parcelled out among vendors who set the terms of access. An asset whose custody rests with others is an asset only on paper, and the firm that keeps delegating it will keep spending on technology the energy it meant to spend on the business.
One thing should be said plainly, against the cleaner version vendors and consultants will tell. The binding constraint on this whole transition is governance and trust, not technology. A unified model that agents can act through is more powerful than a read-only warehouse, and for the same reason more dangerous. The discipline that makes it safe to run, clear control over what may be seen, what may be changed, and by which agent under whose authority, is the same discipline that makes it valuable. A firm that wants the moat without doing that work will end up with neither.