The Agentic Blueprint (And the Floor It Was Never Built On)
On architectural visions, missing operations, and the questions that matter at 2 AM.
McKinsey Technology recently published an article titled "Rethinking Enterprise Architecture for the Agentic Era." It is well written, well structured, and presents a clear framework for technology leaders considering how to integrate agentic AI into their enterprise architectures.
It deserves attention — not because it is wrong, but because of what it doesn't say. And what it doesn't say reveals something important about how the industry thinks about transformation.
The Framework
The article presents two paths. Incremental integration: layer agentic AI on top of existing systems, augmenting what works, reducing clutter over time. Comprehensive transformation: rebuild from the ground up, placing AI agents at the core of operations, replacing traditional systems entirely.
The analysis is thoughtful. The incremental path preserves institutional memory but risks accumulating technical debt. The transformational path promises a truly adaptive enterprise but demands massive investment and carries significant failure risk. Most organisations, the authors acknowledge, will walk a middle path.
This is sound strategic thinking. It is also entirely architectural. And that is where the gaps begin.
The Missing Floor
Architecture is what a system looks like on a whiteboard. Operations is what happens when that system processes two billion euros in overnight batch transactions while a severity-one incident is open and the on-call engineer is trying to understand why Job 4,712 did not complete.
The McKinsey article lives entirely on the whiteboard.
The word "incident" does not appear once. "Batch" does not appear. "On-call" does not appear. "Recovery" does not appear. The word "operations" is used, but only as an abstraction — never as the lived reality of keeping systems running at three o'clock in the morning.
This is not a minor omission. It is the omission. Because every architectural vision, however elegant, eventually has to survive contact with production. And production does not care about your framework. Production cares about whether the thing works, whether someone understands it when it doesn't, and whether the recovery path has been tested.
The "Agentic Mesh" — Who Watches the Watchers?
One of the article's more interesting concepts is the agentic mesh — an orchestration layer that connects AI agents to each other and to traditional systems. It enforces business rules, maintains a shared source of truth, and prevents fragmentation when dozens of agents are operating with different objective functions.
The concept is sound. In fact, it already exists in a less glamorous form. Workload automation platforms have been doing exactly this for decades — orchestrating processes across heterogeneous systems, enforcing dependencies, managing exceptions, maintaining audit trails. The language is new. The problem is not.
But the article's description of the agentic mesh raises a question it does not answer: what happens when the mesh itself fails?
If the agentic mesh is the nervous system of the enterprise, then a failure in that layer is not an application outage. It is a systemic event. Every agent that depends on the mesh for coordination, governance, and truth is now operating without guardrails. In traditional architectures, a scheduler failure is a well-understood scenario with documented recovery procedures. In an agentic mesh failure, the recovery path depends on understanding the state of every agent at the moment of failure — a state that may be dynamic, distributed, and undocumented.
The article recommends the agentic mesh as an enabler of governance. It does not ask what governs the mesh.
Self-Organising Agents in Regulated Environments
The comprehensive transformation path envisions agents that "negotiate access to resources and modify workflows dynamically." The enterprise becomes "a living network of intelligent agents capable of self-organisation and continual adaptation."
This is an extraordinary claim. It may even be technically achievable. But it runs headlong into a wall that the article does not acknowledge: regulatory reality.
Financial services under DORA. Critical infrastructure under NIS2. Healthcare under sector-specific data governance. In all of these environments, a regulator can — and will — ask a simple question: explain the decision that led to this outcome.
A self-organising agent that dynamically modified a workflow is, by definition, difficult to audit after the fact. The adaptability that makes it architecturally elegant makes it regulatorily problematic. An auditor does not want to hear that the system "adapted." An auditor wants to see the decision chain, the business rule that triggered it, and the human who approved it.
This does not mean agentic architectures are incompatible with regulation. It means that the governance model for agentic systems is fundamentally different from traditional IT governance — and that difference deserves more than a paragraph about "AI governance platforms that monitor, validate, and coordinate agent behavior in real time." That sentence contains an entire industry of unsolved problems.
The 100-Engineer Question
The article includes a striking projection: "A project that once took 100 engineers a full year could be completed by a handful of teams working in concert with agent factories."
Leave aside whether this is achievable today. The more important question is what happens to the knowledge those 100 engineers carried.
In large enterprise environments, the engineering team is not just a production function. It is a knowledge repository. Each engineer carries context about why certain decisions were made, which integrations are fragile, where the undocumented dependencies live, and what failed the last time someone tried to change that module.
Reduce that team to a handful, and the institutional knowledge evaporates — even if the code is perfectly maintained by agents. Because the knowledge was never in the code. It was in the conversations, the incident post-mortems, the tribal memory of what happened at 2 AM on that Tuesday in November four years ago.
Agent factories can generate code, documentation, tests, and deployments. They cannot generate the judgement that comes from having been responsible when something went wrong. And that judgement is exactly what you need when the agent factory itself encounters something it was not designed for.
"Just Choose" — The Most Expensive Advice in Consulting
The article's primary recommendation is disarmingly simple: make a deliberate choice. Decide between incremental and transformational. Commit. Execute quickly.
In principle, this is correct. Indecision is expensive. But the recommendation assumes that the information needed to make that choice already exists within the organisation. In practice, it rarely does.
Most enterprises do not have a clear, honest inventory of what their legacy systems actually do, how they interact, where the critical dependencies are, and which processes are genuinely understood by their current teams. Without that diagnostic baseline, choosing between incremental and transformational is not a strategic decision. It is an educated guess dressed in a framework.
The choice that matters is not "incremental or transformational." The choice that matters is: do we understand what we have well enough to make either decision responsibly?
In most cases, the honest answer is no. And that is not a failure of strategy. It is a failure of diagnosis.
What the Whiteboard Doesn't Show
None of this diminishes the value of architectural thinking. Enterprise architecture matters. Strategic frameworks matter. The choice between evolution and revolution is real and consequential.
But architecture without operations is a blueprint without a foundation. It describes what you want to build. It does not describe what will happen when you build it on top of thirty years of accumulated decisions, undocumented dependencies, and systems that work for reasons nobody fully understands.
The missing questions are not exotic. They are basic:
Who is on call when an agent makes a wrong decision at 2 AM? Not architecturally. Operationally. Which human picks up the phone?
What is the recovery path when the orchestration layer fails? Not in the design document. In production. With data in flight.
How do you explain an agent's autonomous decision to a regulator? Not in theory. In an audit. With consequences.
What happens to institutional knowledge when you reduce a 100-person team to a handful? Not on the org chart. In the incident that happens six months later, when nobody remembers why the system was built that way.
How do you diagnose what you have before deciding what to replace? Not with a maturity assessment on a slide. With genuine, uncomfortable honesty about what is understood and what is not.
These are not objections to the agentic era. They are prerequisites for surviving it.
Architectural visions are necessary. But they are not sufficient. The gap between a strategy deck and a production environment is where most transformations quietly fail — not because the vision was wrong, but because nobody asked what the floor was made of before redesigning the ceiling.
The agentic era is coming. The question is not whether to embrace it. The question is whether we understand what we are standing on well enough to build something new on top of it.
That understanding does not come from frameworks. It comes from diagnosis.