The last post ended on a question I didn't have a clean answer to: if the authority emerges from the chain, not from any individual agent within it, and most organisations don't even know where those chains begin and end — then who's responsible for the chain as a whole?
The more i think about this, the more I think it's actually two questions that look like one.
The first is an architectural question: is there a technical layer that connects these agents, and could that layer be where governance lives? The second is a human question: even if that layer exists, who's accountable when the chain does something nobody intended?
I want to take them in order, because I got the first one wrong before I got it right.
The Microservices Parallel — and Where It Stops Holding
When this problem comes up in conversations, the first instinct — mine included — is to reach for a familiar frame. We've built distributed systems before. We had teams owning independent services, shared dependencies, integration contracts, and the same awkward question about who owns the logic that crosses a boundary. That's the microservices problem. We mostly solved it.
So is the agentic version just the same problem restated?
Partly, yes. The structural pattern is recognisable. Independent units built by independent teams. Shared dependencies — a product catalogue, a customer record, a knowledge base — used by more than one agent. A need for something above the individual unit that holds coherence across all of them. If you squint, the three-agent CRM chain from the last post looks a lot like a three-service architecture diagram from five years ago.
But here's where the analogy starts to strain. Microservices fail loudly. A service returns a 500, a timeout, a null response. You can write a test for it. You can set an SLA on it. The failure is visible, reproducible, and bounded.
Agents fail softly. An agent returns something — it's just subtly wrong, or confidently incomplete, or contextually misaligned with what the chain needed it to produce. There's no error code for "the summarisation agent made a reasonable inference that happened to be slightly off." The failure doesn't throw an exception. It propagates — quietly, plausibly, as a slightly different input into the next agent's reasoning.
By the time the outreach message reaches a customer, nobody in the chain flagged anything unusual. The individual outputs each looked reasonable. It was the accumulated drift that caused the problem — and accumulated drift across a chain you didn't design isn't something a service contract catches.
Actually, There Is a Technical Layer
MCP — the Model Context Protocol, introduced by Anthropic in late 2024 and now adopted broadly across the major AI platforms — has become the connective standard for agents in roughly the way REST became the connective standard for services. It lets agents discover and call other agents and tools across platform and vendor boundaries, without custom integrations. Within about a year of launch, thousands of MCP servers existed, and major enterprise platforms had adopted the standard.
The November 2025 spec update added something directly relevant to the chain problem: formalised trace propagation. The same OpenTelemetry conventions that distributed systems use to follow a request across service hops now apply across agent hops. If the agents in the three-team CRM example from the last post are all speaking MCP, the plumbing to follow a decision from the first agent through to the third — across platforms, across vendors, across teams — now exists at the protocol level.
So there is a technical orchestration layer. MCP is doing for agents what REST did for services.
But REST didn't solve who owns the business logic that crosses service boundaries. And MCP doesn't solve who owns the judgement that crosses agent boundaries.
Those are different things. An API contract specifies the shape of the data. It says nothing about whether the decision the data encodes was the right one. The trace tells you what happened. It doesn't tell you whether what happened was what anyone intended — across the chain, as a whole, over time.
The Judgement Layer Has No Owner
Here's the problem that's harder to route around.
When a microservices architecture drifts — when services start behaving differently from their original intent — there's usually a team who owns each service, an API contract that defines expected behaviour, and a change process that should have caught the drift. The governance model has anchors.
The three-agent chain doesn't have those anchors in the same way.
Each agent was built by a team with a specific, local intent. The CRM team built a summarisation tool. The sales team built a prioritisation tool. The outreach team built a drafting tool. None of them designed a customer engagement system. None of them are responsible for the system that emerged from their three tools being connected.
So when the combined output starts drifting — when the summaries shift because the model behind the first agent was quietly updated, and that shift flows through as a different prioritisation score, and that score produces subtly different messages going to customers — who notices? And if they notice, who owns it?
In a well-governed microservices environment, you'd escalate to an architect or a service owner. There's a chain of accountability as well as a chain of calls.
In the agentic equivalent, the chain of calls exists. The chain of accountability often doesn't.
This is what Dr. Raj Ramesh (drrajramesh.com) describes as the Conductor role — and I think he's naming something real. The Conductor in an orchestra doesn't play an instrument. They hold the coherence of the whole. They hear when the individual sections are technically correct but collectively off. Their job is the emergent output, not the individual contributions.
The enterprise architect in an AI-native environment needs to become that kind of Conductor. Not the owner of every agent — that would collapse back into centralised control and defeat the point. But the person who holds accountability for whether the chain, as a whole, is doing what the organisation intended. Someone who can ask: is the customer engagement system we didn't design still aligned with the customer engagement strategy we did?
Why This Is Harder Than It Sounds
Conducting a traditional orchestra works because everyone rehearsed the same score. The musicians know what they're meant to play. The Conductor is aligning execution against shared intent.
The three-agent chain wasn't rehearsed. There's no score. Three teams built three things, independently, against three different briefs. The chain emerged from those three things being connected — not from a plan that anyone wrote down.
So the Conductor of an agent chain is being asked to govern something that was never composed. And they're being asked to do it while the musicians keep updating their own parts.
The human parallel I keep landing on isn't really an orchestra. It's more like a band that formed gradually, where each member joined thinking they were playing a different gig, and nobody has told them yet that they're now the house band.
Getting to something like coherent governance from that starting point isn't just a process question. It's a culture question. It requires the teams who built independently to be willing to see their work as part of something larger than what they were originally asked to build. And it requires an architect with enough context, and enough authority, to make that case — not as a mandate, but as a narrative that makes sense of what everyone is looking at.
That's harder than a framework suggests. I'm not sure I've seen it done cleanly. But I'm increasingly convinced it's the actual job.
What the Conductor Role Actually Requires
If I try to land this practically — what does it look like to play the Conductor role in an organisation that has chains it didn't design?
A few things seem necessary, none of them purely technical.
The first is naming the chain. Before you can govern it, you have to be willing to say: these three agents, built by three teams, are functioning as a system. That system has emergent behaviours. Those behaviours need an owner. This sounds obvious. In practice, it requires someone willing to reframe work that three teams believe they separately own.
The second is distinguishing tracing from governing. The tooling to trace a chain end-to-end is maturing fast. But a connected trace isn't the same as governance. Someone has to look at the trace and ask: is this chain doing what we intended — not just technically, but in terms of the decisions it's making in the world? That question requires context the trace doesn't carry. It requires a person who knows what the chain was for.
The third is accepting that the judgement layer is human. MCP gives agents a common protocol. OpenTelemetry gives you a connected trace. Neither of those replaces the human who holds the intent of the chain over time — who remembers what it was built to do when the individual teams who built it have moved on to other things, and who notices when its outputs have quietly drifted from that intent.
This is, I think, the core of what makes the Conductor role genuinely new. It's not just change management in the traditional sense — helping people adapt to new tools. It's accountability for emergent systems. Systems that weren't designed, can't easily be tested as a whole, and will keep evolving regardless of whether anyone is watching them.
We've got MCP for connectivity. We've got observability tooling for visibility. What we don't yet have, in most organisations I'm aware of, is a clear answer to who holds the judgement layer.
That's the gap the Conductor is meant to fill.
And I think most organisations are going to discover that gap the hard way — not when an agent fails loudly, but when a chain that's been quietly running for months starts producing outputs that no longer match the intent of the people who originally asked for it.
Thoughts? I'd love to hear them — find me on LinkedIn.