Governing the Fleet, Not Just the Agent

The last post ended with a question I deliberately left open: if every agent needs constitutional design — explicit intent, authority, scope, policy, proof and your organisation is deploying dozens of them, how do you govern the fleet, not just the individual?

Here's the scenario I keep coming back to when I try to think about that.

An agent reads customer feedback and summarises it into a CRM record. A second agent reads those records and uses them to prioritise customer outreach. A third agent drafts the outreach message based on the priority score. Each of these, on its own, is a sensible thing for a team to build. None of them required a large project. None of them would have looked unreasonable in a design review, if they'd been through one at all.

Strung together, they form a chain that nobody owns. If the first agent starts summarising slightly differently - because the feedback it's reading has shifted in tone, or a prompt got tweaked, or the model behind it was upgraded, that change propagates through the second agent and shows up as a different kind of message from the third. Nobody approved that chain. Nobody is watching it as a chain. Three teams each made a reasonable local decision, and the result is something none of them own.

I think this is the portfolio problem and the air traffic problem at the same time, and looking at it that way is what's clarified things for me. But the two halves turned out to have very different answers when I actually went looking.

The Portfolio Question: Do You Know This Chain Exists?

Dr. Raj Ramesh (drrajramesh.com) names Portfolio Management as one of the essential skills for enterprise architects in an AI world. My first reaction was that this felt familiar. I've sat through capability portfolios and application rationalisation before. Surely this is the same discipline applied to a new asset type.

What I'm less sure about is whether it transfers as cleanly as that. A software portfolio grows through approval. Someone has to ask for budget, which means someone eventually has to write it down. An agent portfolio doesn't seem to work that way. Once a platform like Copilot Studio exists in an organisation, building something like the CRM agent in my example doesn't require a budget conversation. It requires someone with access and an afternoon.

Which means the first question — "do we know this three-agent chain exists?" might not have a confident answer in most organisations. I've heard the broader version of that question asked directly in a room: how many AI agents are running in your environment right now? And watched the room go quiet. Not because anyone was hiding something. Because nobody had actually counted.

If that's true, then before there's a portfolio to manage, there's a discovery problem. You can't assess the risk of a chain you don't know is there. And unlike the next problem, I don't think there's a tooling answer to this one . it's an organisational question about who's responsible for knowing what's been built.

If You Did Know — What Would You Even Ask?

Say the chain gets discovered. Someone finds all three agents and lists them. What's the next question?

My instinct is that the most useful thing to ask isn't "what does each agent do" . it's "what is each agent authorised to do." The summarising agent only writes to a record. The prioritisation agent only reads and scores. The outreach agent drafts a message , but does it send it, or does a person send it? That last distinction changes everything about how much this chain matters.

The next instinct, once you know what each agent is authorised to do, is to ask what the worst case looks like for each one on its own. For the summarising agent, that might be "writes a slightly off summary that sits in a record, unnoticed." Asked in isolation, that sounds like a low-priority entry in a register, easy to file under "low risk" and move on.

But I'm not sure that's the right question anymore. The more I think about the three-agent chain, the more it seems like the question that actually matters is: what does this agent contribute to something bigger than itself? The summarising agent looks harmless on its own. Inside a chain that ends with a message going to a customer, it's the first link in something that can act in the world — and its harmlessness on its own might be exactly what lets it go unexamined.

I think the question that should sit in a portfolio register, for every agent, is closer to: what is this agent part of, and does that bigger thing have an owner? "What's the worst this agent could do alone" and "what authority does this agent contribute to a chain" are different questions, and I suspect most registers, to the extent they exist, are still asking the first one.

I don't think this is a complete answer to portfolio management for agents. But it feels like the right first question. and I suspect most organisations haven't asked it about most of their agents yet.

The Air Traffic Question: Is Anyone Watching the Chain Itself?

An air traffic controller doesn't ask whether each individual aircraft was a good purchase. They're watching the airspace right now is anything about to conflict with anything else.

The three-agent chain is, in that sense, an airspace. Each agent might be perfectly fine on its own. The question is whether anyone has visibility into the chain as a thing that exists and behaves as a unit.

When I went looking at what's actually available here, I expected to find a gap. What I found instead was a maturing tooling category — agent observability platforms that trace exactly the kind of chain I'm describing. The current generation of these tools captures multi-step agent execution as structured traces, with parent-child relationships across handoffs, so you can follow a decision from the first agent through to the third. OpenTelemetry has even standardised this. there are now defined span types specifically for "an agent invoked another agent" and "an agent invoked a tool," with a parent span that wraps the whole chain. Several major platforms added multi-agent visualisation specifically. the kind of view that would show you where in a chain a problem originated.

So the air traffic question has more of an answer than I expected. The capability to trace a chain like this, even one spanning multiple agents — is real, and more mature than I assumed going in.

The Protocol Doing the Connecting

Part of why that capability exists now is a standard called the Model Context Protocol(MCP) . Anthropic introduced it as an open standard in late 2024, as a common way for an AI system to discover and call tools and data sources, Think of it as a shared adapter. instead of every agent platform needing a custom integration with every tool and every other agent, they can all speak MCP, and anything that speaks MCP can call anything else that does.

Adoption has been fast. Within about a year, there are thousands of public MCP servers, and major platforms, including Microsoft incorporated the standard. Practically, this matters for my three-agent example because it's increasingly how "one agent calls another agent's capability" actually happens. The summarising agent doesn't need a bespoke integration with the prioritisation agent. If both speak MCP, one can call the other as a tool.

The part that's relevant to the air traffic question is that MCP recently formalised trace propagation as part of its specification. a way of passing trace identifiers along with the call itself, using the same conventions OpenTelemetry already uses elsewhere. In practice, that means a trace starting in one agent's host application can follow a call through to another agent's server, and on to whatever that server calls next, and show up as a single connected trace even when the two ends are built on completely different platforms, in different languages, by different teams.

If my three agents, one in Copilot Studio, one in a low-code platform, one wired up with a vendor's SDK — are calling each other through MCP, the plumbing to follow that chain end to end now exists at the protocol level. Not bolted on by one vendor for their own ecosystem. Built into the thing that connects the agents in the first place.

Where the Gap Actually Is

Here's the catch, and it's the part of the original question I think I had wrong, though not in the direction I expected.

I assumed the three-platform, three-team nature of my example was where tracing would fall apart. No shared backend, no common vendor, nothing tying the pieces together. MCP's trace propagation is aimed at exactly that boundary, which is a more optimistic answer than I expected to find. But I don't think it closes the gap, I think it relocates it.

The propagation standard is new enough that whether three independently-built agents in mid-2026 are actually using it is still an open question. Adoption of any new protocol-level capability takes time, and "the capability exists" and "these three specific agents were wired up to use it" are different claims. There's also a gap between adoption and what's actually being captured. Recent industry surveys suggest the large majority of organisations now say they've implemented some form of agent observability — but my guess is that figure is mostly counting visibility into a single agent's own reasoning, not a connected trace across a chain like mine.

But even setting adoption aside, say the trace exists, end to end, perfectly connected. What would anyone do with it?

A trace is a record of what happened. It tells you the summarising agent processed a record, the prioritisation agent scored it, the outreach agent drafted a message. On its own, that's just a longer log. For it to mean anything as governance, someone has to be looking at that trace and asking a question it wasn't designed to answer: is this chain , behaving the way it's supposed to? Has its combined output drifted? Is it still doing what the three teams, individually, thought they were building?

Nobody's asking that question, because as far as I can tell, nobody's defined the chain as a thing that exists.

The trace can connect the dots. It can't tell you the dots form a shape that someone is meant to be watching.

Where This Leaves Me

The portfolio question and the air traffic question turned out to be different kinds of problems.

The portfolio question — do we know this chain exists? looks largely organisational. Before an organisation can govern agents, it first has to know what has been built, who owns it, and where it sits. That's harder than it sounds when agents can be created without projects, budgets, or formal approval processes.

The air traffic question — would we know if the chain started behaving differently, has more of a tooling answer than I expected. The plumbing to connect a trace across agents, even across different platforms and vendors, is being built faster than I assumed. But a connected trace isn't the same as governance. Someone still has to look at it and ask whether the chain it describes is doing what it's meant to and that requires knowing the chain is a thing in the first place.

But the more I think about it, the less convinced I am that the individual agent is the right governance unit in the first place.

The summarisation agent, the prioritisation agent, and the outreach agent might each appear low risk when viewed independently. One reads. One scores. One drafts. None of them look particularly concerning on an architecture diagram.

Yet together they form an autonomous customer engagement capability. The authority emerges from the chain, not from any individual agent within it.

That feels different from most of the governance models enterprise architects are used to. We govern applications because applications contain capabilities. Agentic systems increasingly don't. The capability emerges from multiple agents, owned by different teams, running on different platforms, and evolving independently over time.

If that's true, then perhaps the real governance challenge isn't understanding individual agents at all. It's understanding the authority that emerges when they're combined.

And I'm not sure most organisations even know where those chains begin and end.

---

Thoughts? Find me on LinkedIn.

← Your Architecture Diagrams Are Missing the Most Important Actor