A widely-cited MIT study put a number on something most operators already suspected: the overwhelming majority of enterprise AI pilots produce no measurable return. Ninety-five percent show nothing on the P&L.
The instinct is to read that as a verdict on the technology — the models aren’t ready, the use cases are thin. It isn’t. The same study locates the failure somewhere more uncomfortable. Not in the models, but in everything around them. The systems don’t hold on to what they learn. They get re-briefed from scratch every session. They sit beside the business rather than inside it.
That is a context problem, not a capability problem. The model is rarely the thing that’s missing. What’s missing is the connection between the model and the work — the data it should be able to reach, the decisions it should be able to see, the memory of what happened last time. Most organisations have bought capability and starved it of context. Then they’ve concluded the capability was overrated.
This is the part worth sitting with, because it changes where the money should go. If the binding constraint were model quality, the right move would be to wait — better models arrive every few months on their own. But the constraint is context, and context is something only the organisation can build. No vendor ships it. It doesn’t improve while you wait. It is the work.
Outward-in is rational, which is exactly why it’s a trap
Look at where AI has actually landed in most companies and you find it on the edges. Customer support. Marketing copy. A licence to a chat tool handed round the team. Sensible places to start — contained risk, fast payback, a result you can point to inside a quarter. Nobody chose the periphery by mistake. They chose it because it pays back before anyone has to defend a larger bet.
The problem is what that approach quietly assumes. It treats each AI use case as a thing you bolt on in isolation — a feature added to a function, independent of the rest. Support gets its tool. Marketing gets its tool. Finance, later, gets its tool. Each one is provisioned alone, hits the same wall alone, and is judged alone.
And each one hits the same wall: it can’t see the context the others hold. The support agent doesn’t know the customer’s contract terms — those live with legal. It can’t see the payment history — that’s finance. It has no memory of the last three conversations — those were never written anywhere it can read. So it does a passable job of a narrow task and stops well short of the thing that would have mattered. The ceiling isn’t the model. It’s the isolation.
Retrofitting AI onto the edges of a business is locally rational and structurally capped. You can keep adding tools at the periphery and the line will keep going roughly flat, because you’re adding elements of a system one at a time while forgoing the thing that makes the system worth more than its parts.
Capabilities are complements, not line items
Here is the claim the rest of this rests on. Inside a single firm, AI capabilities are complements. Each one is worth more when it can draw on what the others produce.
The support agent that can read the contract, see the payment history, and recall the last three conversations isn’t incrementally better than the one that can’t. It’s doing a different job. The same is true in reverse — the legal capability is worth more when it can see how contract terms actually play out in support tickets and collections. Connect two capabilities through a shared layer of context and the pair is worth more than the two of them apart. Connect a third and it compounds again, because the third now has two sources of context to draw on, and they have a third.
This isn’t a new or speculative idea. The economics of it were formalised decades ago — Milgrom and Roberts on complementarity, the observation that some sets of practices are worth more adopted together than separately, because each raises the return on the others. The finding that travels with it is the one that should worry anyone running a periphery-first programme: when practices are genuine complements, partial adoption underperforms. Not by a little. You don’t capture a fraction of the value by adopting a fraction of the system — you forgo the interaction terms entirely, which is where most of the value was.
That is the real case for building inward-out rather than outward-in. It isn’t that the centre is tidier, or that one platform is cheaper to run. It’s that the value lives in the connections, and you cannot harvest the connections by installing the endpoints one at a time and hoping they meet in the middle. They don’t meet on their own. Something has to hold the context they share.
Connection has a cost, and the foundation is what lowers it
The honest version of this argument has a second half, and leaving it out is how these claims lose credibility.
Connection is not free. Every link between two capabilities is a coupling — a thing to govern, a thing to secure, a thing that breaks when a schema changes or an owner moves on. Wire everything to everything and you don’t get compounding value; you get a maintenance burden that grows faster than the value does, and an integration layer that rots quietly until something fails in production. Anyone who lived through the centralised data-warehouse era knows the shape of this. The promise was one place for everything. The reality was a bottleneck that aged badly.
So the move is not to pool everything in the centre. That’s the mistake the last decade already made and rejected. The move is narrower and more durable: build one shared foundation that the rest of the business plugs into, while the parts keep owning their own data and their own context. A common layer for the things that genuinely should be solved once — identity, access, governance, evaluation, the memory that lets a system carry context from one session to the next. Not a vault that swallows the organisation’s data. A layer underneath it that lets the organisation’s data be reached, safely, by everything that needs it.
That distinction is the whole game. Centralise the foundation, not the data. Get it right and each new connection is cheap, because the hard parts were solved once and are simply there to be used. Get it wrong — centralise the data itself — and you’ve rebuilt the bottleneck everyone spent the last decade escaping.
There’s a quieter reason the foundation matters more than the count of connections. A chain of capabilities is only as strong as its worst-integrated link. One capability wired to stale or untrusted context doesn’t add a little value — it poisons the decisions downstream of it. Which means the variable that determines whether connection pays isn’t how many things you’ve connected. It’s how good the shared foundation is. Connection multiplies whatever the foundation gives it. If the foundation is solid, connection multiplies value. If it isn’t, connection multiplies noise.
The second effect: each capability gets cheaper to add
Complementarity is the value side of the argument. There’s a cost side that points the same way.
Every AI use case, built in isolation, re-solves the same handful of problems from scratch. How do we reach the data. How do we handle identity and access. How do we govern this. How do we know it’s working, and catch it when it isn’t. Solve those once, in a shared foundation, and the marginal cost of the next capability falls — because the next one doesn’t pay the setup cost again. It inherits it.
This is the logic McKinsey has put to its own clients: direct change spending towards shared platforms and foundations that lower the marginal cost of future innovation, rather than funding each initiative as a one-off. The platform-engineering discipline has spent years proving the narrow, technical version of this — reusable building blocks that make the next thing faster to ship. The claim here is the same economics at the level of the operating model rather than the infrastructure. Build the foundation once. Watch the cost of everything that follows come down, and the ceiling on what’s buildable rise, for every part of the business at the same time.
Falling marginal cost and rising value from the same foundation. That is what compounding actually means here — not a magic multiplier, but two reinforcing effects off one piece of work.
Real change, or activity?
A word on what this is and isn’t, because the claim deserves to be stated honestly. The mechanism above is well-grounded — the failure data is real, the economics of complementarity are settled, the cost logic is proven at the infrastructure layer. What we have modelled, rather than yet demonstrated across a client’s full-year P&L, is the size of the compounding effect when the foundation is built first. Our own tests of it are simulated. We’re confident in the direction and the mechanism. We’re not going to dress a model up as a result.
What the argument does settle is where the failure has been coming from, and it isn’t where most of the spend has gone. The ninety-five percent didn’t fail because the models couldn’t do the work. They failed because the work was never rebuilt to let the models reach it. Capability was added to the edges of organisations that were still built around the assumption that judgement is scarce and human — and on that assumption, the capability had nowhere to compound.
The question for anyone deciding where the next tranche of AI budget goes is therefore not which function to point a tool at. It’s whether the foundation underneath the functions exists yet. Without it, every tool you add is another endpoint hitting the same wall alone. With it, the same tools start doing a different job.
Real change, or activity. The two have looked similar for a couple of years now. They’re about to stop.