The agent you build today won't survive the year — so build the kitchen, not the dish

These are stories about the gap between a dazzling demo and a number on a finance report — and what it actually takes to close it.

I read a piece this week from QuantumBlack, McKinsey's AI arm, on building a "future-proof" enterprise agentic platform. It could have been dry. It wasn't — because underneath the architecture diagrams is a very human problem. Companies are buying AI everywhere and seeing it almost nowhere on the bottom line.

I've watched this happen up close. The teams are smart. The tools are real. And still the value leaks out somewhere between the pilot and the process. The piece gave me a clean way to think about why. So here it is, as a set of stories rather than a stack of layers.

Everyone bought the copilot. Nobody moved the number.

It's the last week of the quarter. Maya, who runs transformation at a mid-size bank, is staring at a slide she has to present tomorrow.

For nine months she has rolled out AI assistants. The sales team got a copilot. The support team got a chatbot. Legal got a contract summariser. Every demo landed. People clapped. One executive called it "the future, today."

Then the CFO asked the only question that matters: show me where this changed a real number. Cycle time, cost-to-serve, revenue per head — anything. And Maya realised she couldn't. The assistants were everywhere. The impact was a rounding error.

McKinsey has a name for this: the gen AI paradox. Adoption is sky-high and measurable business impact is stubbornly low. The reason is a quiet distinction most companies miss. There are horizontal tools — copilots and chatbots that sit beside the work, easy to deploy, loosely bolted onto the actual process. And there are vertical tools — agents that live inside a workflow, doing the credit write-up, drafting the code, moving the case forward. The horizontal ones are easy and shallow. The vertical ones are hard and transformative. Maya had bought a building full of the easy kind.

The teaching: "A copilot sits next to the work and whispers. An agent does the work. Only one of them ever shows up in the quarterly numbers."

The bank that built two brilliant agents that couldn't talk to each other

Two floors of the same headquarters. Two teams. Neither knew what the other had built.

On the third floor, a small team shipped an agent that could pull a customer's history, summarise it, and draft a credit memo. Genuinely good. On the fifth floor, another team built an agent that could check a loan against policy and flag the risks. Also good.

Then someone in the room asked the obvious thing: can the credit-memo agent just ask the risk agent for a check? Silence. No, it couldn't. Different runtime. Different security model. Different idea of what a "tool" even was. To connect them, someone would have to rebuild half of each. So nobody did. Two islands of value, a channel of cold water between them.

This is the failure the QuantumBlack piece is really arguing against, and its answer is to stop thinking in agents and start thinking in platform. Four layers, like a building. At the top, the agentic systems — the actual agents people use, from off-the-shelf productivity bots to custom, purpose-built ones. Beneath them, the runtimes that execute the agents — your AI Foundry, your Vertex, your Bedrock, or open-source engines like Ark and Kagent. Below that, the interfaces and orchestration layer — the wiring that lets agents on different runtimes coordinate. And underneath everything, the shared services: observability, evaluation, security, memory. The plumbing every agent needs and no agent should reinvent.

The two-floors problem isn't a people problem. It's a missing third layer.

The teaching: "Stop building agents. Build the kitchen they cook in — one set of plumbing, many dishes. The team that builds dishes ships ten islands. The team that builds the kitchen ships a restaurant."

The engineer who hand-built a memory store, then watched the world ship a better one for free

Raj spent six weeks building a way for his agent to remember things between conversations.

It was careful work. A little database, some logic to decide what to keep, a way to pull the right context back at the right moment. He was proud of it, and he should have been — it worked.

Four months later, an open-source memory framework landed that did everything his store did, plus things he hadn't thought of, maintained by a community of hundreds. His six weeks were now six weeks of code he had to keep alive himself, for no advantage. He hadn't built a moat. He'd built a liability with good intentions.

This is where the piece offers its sharpest idea, and it's almost a pun: build a platform that is composable and compostable. Composable, so you can snap pieces together. Compostable, so you can let a piece rot away and be replaced when the market overtakes it. The decision rule is refreshingly blunt. Buy when a clear market solution exists, and favour the modular, interoperable one. Partner when you can't buy it yet — but never build a capability that's about to become a commodity. Build only where it makes you genuinely different from your competitors, and even then, build on open-source bones.

Raj's memory store failed every part of that test. It wasn't a differentiator. It was about to commoditise. And he'd built it from scratch. The lesson isn't "never build" — it's "know which of your code is a moat and which is just maintenance you signed up for."

The teaching: "Build only the thing that makes you different. Everything else, rent — and be glad when the market makes your old code obsolete. The best component is the one you can throw away without flinching."

Why the boring decision — protocols, not vendors — is the one that ages well

Picture the early railways, before anyone agreed on the width of the track.

Every company laid its own gauge. The trains were marvels. But a carriage from one line physically could not run on another's rails, so goods got unloaded and reloaded at every border. The engineering was brilliant and the network was useless. The thing that finally unlocked the railways wasn't a faster train. It was everyone agreeing on a standard width.

Agent platforms are at exactly that moment now. And the QuantumBlack team's first design principle is to bet on the standards instead of the vendors. Two are emerging as the gauge. MCP — the Model Context Protocol — is how an agent reaches out to tools and data in a safe, consistent way. A2A — Agent2Agent — is how an agent on one vendor's runtime asks an agent on another vendor's runtime to do something. Adopt both, and Maya's two-floor problem dissolves: the credit agent can call the risk agent even if they were built by different teams on different stacks. Better still, when a vendor disappoints you, you can swap it out without ripping up the whole workflow.

It's the least glamorous decision in the whole architecture. Nobody demos a protocol. But protocols are what let you change your mind later without paying for it — and over a five-year horizon, the freedom to change your mind is worth more than any single vendor's best feature.

The teaching: "Bet on the standard, not the supplier. The flashy vendor wins the demo; the boring protocol wins the decade."

The demo that worked on Tuesday and lied on Thursday

The agent had done it perfectly in the dry run. So they put it live. By Thursday it was confidently writing nonsense into customer files, and nobody noticed for a day and a half.

Every team that ships agents eventually meets this ghost. The thing that worked is not the same as the thing that keeps working. Language models drift. Edge cases arrive. A prompt that was fine yesterday meets an input it has never seen, and the failure is silent — no stack trace, no red light, just a plausible sentence that happens to be wrong.

This is why the piece insists that four capabilities can't be bolted on later. They have to exist on day one, before the first agent goes live. Evaluation — automated, test-driven checks on latency, cost, consistency, and factual accuracy, so an agent is measured the way you'd measure any other production system. Marketplaces — a shared, governed place where teams discover and reuse each other's agents and tools instead of quietly rebuilding them. Memory management — persistent context, so an agent that solved something on Tuesday still knows it on Thursday. And feedback loops — a way for the system to learn from how it does in the real world, not just how it did in the lab.

The team with the Thursday ghost had a great agent and none of these four. They'd built a race car with no dashboard, no speedometer, no warning lights — and then acted surprised when they drove it into a wall they couldn't see coming.

The teaching: "If you can't measure an agent in production, you haven't shipped it — you've released it. The dashboard isn't paperwork you add later. It's the thing that lets you go fast without crashing."

The bank where agents work the night shift and humans review at dawn

The most striking story in the whole piece isn't a warning. It's a glimpse of what good looks like.

A global bank wired its software lifecycle so that agents do the heavy lifting overnight — writing, testing, refactoring — and engineers arrive in the morning to a queue of work that's already drafted, waiting for human judgement. The agents never touch production on their own. They run inside a deterministic workflow engine that says, in effect: you may do these steps, in this order, with these checks, and a human signs here. Autonomy, but inside fences. Elsewhere, another firm used AI-assisted code generation to move about 50% faster, with more than a hundred developers leaning on it every day. A European bank automated its credit write-ups and scaled the pattern across business units.

What separates these from Maya's clapping-but-flat copilots? They're vertical — embedded in a real process, not parked beside it. And they were built on a platform designed so any single part could be torn out. That last point is the quiet thread through the entire architecture: design for replaceability. Pick deterministic workflow engines to bound what agents are allowed to do. Decide deliberately which capabilities stay central and which get distributed to teams. And assume every component you choose today — every model, every runtime, every framework — will be the wrong choice within a year, so make sure you can replace it without a rebuild.

That sounds pessimistic. It's the opposite. It's the only posture that lets you move fast now, in a field changing this quickly, without betting the company on a guess.

The teaching: "Give agents the night shift and humans the morning judgement. Real value isn't an agent doing everything — it's an agent doing the heavy lifting inside fences you designed on purpose."

What I'm taking from it

The honest summary is shorter than the architecture diagram. Most companies are losing the AI race not because their agents are bad, but because they're building dishes when they should be building a kitchen — and pouring concrete where they should be making compost.

Build the platform, not the agent. Bet on protocols, not vendors. Buy what will commoditise, build only what makes you different, and be ready to throw any of it away. Measure everything in production from the first day. And give the machine the heavy lifting while keeping the judgement — and the fences — firmly human.

None of it is flashy. All of it ages well. And in a year, when today's best model is yesterday's news, the company that built to replace things will still be standing — calmly swapping out a part — while the one that built a monument is deciding whether to demolish it.