Most AI governance conversations treat the agent as a singular actor. One system. One request. One evaluation. One verdict.

Production multi-agent systems are rarely that clean.

An orchestrating agent delegates a task to a subagent. The subagent returns a result that contradicts the orchestrator’s prior evaluation. Two agents from different organizations connect via a protocol, and each carries distinct authority claims for the same resource. An agent in a pipeline produces an output that a downstream agent, operating under tighter governance constraints, refuses to process.

Nobody is writing governance frameworks for these scenarios. And they are happening right now in production systems at organizations that have not thought through what the conflict-resolution mechanism looks like, where accountability lies when things go wrong, or whether their governance infrastructure was designed to handle anything beyond a single agent making a single request.

The Multi-Agent Reality

Multi-agent architectures are the direction the industry is moving. Orchestrators that spawn subagents. Pipelines where agent outputs become other agents’ inputs. Networks where agents from different organizations, running on different platforms, with different governance configurations, collaborate on shared tasks.

This is the architecture that makes agentic AI genuinely useful for complex, long-horizon work. It is also the architecture that makes governance significantly harder.

A single-agent governance model assumes a known actor, a known authority context, and a single-point governance evaluation. The verdict is ALLOW, DENY, or ESCALATE. The agent proceeds, or it does not. Clean.

A multi-agent governance model has to answer questions that single-agent models were never designed to address.

When Agent A instructs Agent B to take an action that Agent B’s governance configuration would normally deny, which governance configuration wins? The answer is obvious in some cases and genuinely hard in others. Agent B should follow its own governance constraints regardless of what Agent A requested. An agent cannot inherit authority that was never issued. But what about cases where Agent A has been explicitly authorized to orchestrate Agent B, and the orchestration includes a scope expansion for this specific task? Who authorized that expansion? Was the authority to expand the scope included in the delegation? Can the scope be delegated at all?

The Confused Authority Chain

The problem of the confused deputy, which I have referenced in the context of human accountability, is even more acute in multi-agent systems.

In the classic formulation, a system with legitimate access to a resource can be manipulated by a less-privileged caller into using that access on the caller’s behalf. The system is the confused deputy. It has the authority. It was convinced to use it for something outside its mandate.

In a multi-agent chain, the confused deputy problem compounds. Agent A has legitimate access to a database. Agent A spawns Agent B and passes it a context that grants implicit database access using Agent A’s credentials. Agent B, operating under its own governance configuration, takes actions against the database that Agent A’s governance would have permitted but that Agent B’s governance would not. The question of whether those actions were authorized depends on which governance layer is evaluated, in what order, and with which authority claims.

This is not a theoretical edge case. It is the default architecture of most orchestration frameworks. Subagents inherit context from their orchestrators. Context includes credentials. Credentials carry authority. Authority can be exercised by agents that were never explicitly issued it.

Governance that evaluates each agent in isolation cannot detect this. The subagent’s request looks authorized from the subagent’s perspective. The orchestrator’s delegation looks authorized from the orchestrator’s perspective. The compound authority exercised by the chain is never evaluated as a unit.

When Verdicts Conflict

The disagreement problem has a different shape when two agents evaluate the same situation and arrive at different conclusions.

An orchestrating agent determines that a particular action falls within scope and issues the instruction. A subagent with a different governance configuration evaluates the same action and produces a DENY verdict. The pipeline stalls.

Which verdict takes precedence?

The governance-first answer is clear. The DENY verdict holds. An agent cannot be instructed out of its own governance constraints by another agent. The governance layer exists precisely to prevent authorized principals from overriding governance decisions, and another agent is not a principal with that authority.

But in practice, most orchestration frameworks lack a clean mechanism for handling this. The subagent returns an error. The orchestrator interprets the error as a service failure rather than a governance decision. The retry logic fires. The subagent DENY fires again. The pipeline fails and is logged as a technical failure rather than a governance event.

The audit trail records a failed API call. The governance decision that caused the failure is invisible.

This is not a minor logging issue. It is the difference between a system that produced a governance record and a system that silently bypassed governance through the operational path of least resistance.

Cross-Organization Multi-Agent Governance

The problem gets harder when the agents are from different organizations.

Two agents connect through the Agent Transfer Protocol or a similar standard. Each carries its own identity, its own authority claims, its own governance configuration. They are collaborating on a shared task that requires each to take actions in the other’s domain.

The governance question is no longer about which internal policy wins. It is about whether the governance frameworks of two different organizations can interoperate in a way that preserves both organizations’ accountability requirements.

Organization A’s agent may have been authorized to share certain data with external parties. Organization B’s agent may have been authorized to receive and process external data. But the specific combination of what is shared, how it is processed, and what actions result may fall into a space that neither organization’s governance configuration explicitly anticipated.

The audit trail for this interaction needs to satisfy both organizations’ evidence requirements, under potentially different regulatory frameworks and retention policies, and with potentially different evidence standards.

This is not a solved problem. The canonical Agent-ID work in AGTP addresses the identity layer. The governance interoperability layer, the mechanism by which two organizations’ governance frameworks can verify each other’s authority claims and produce a shared accountability record, is being built.

Where Accountability Lands

When a multi-agent chain produces an outcome that causes harm, the accountability question is genuinely complicated.

Agent A orchestrated. Agent B executed. Agent C processed the output. Each agent has a human owner. Each human owner made decisions about the agent’s design, scope, and deployment. The harm is a product of the chain, not any single link.

The accountability is distributed. It traces to the human who designed the orchestration, the human who authorized the delegation, the human who granted the scope that enabled the problematic action, and the human who failed to build the governance check that would have caught it.

This is why the multi-agent handoff is step 26 in the governance lifecycle. The governance layer has to evaluate the handoff itself. Accountability does not transfer with delegation. The compound authority of the chain is the unit of analysis, not the individual agent’s scope.

An organization that governs each of its agents individually without governing their interactions governs the components without governing the system.

What Multi-Agent Governance Actually Requires

The architectural requirements for genuine multi-agent governance are specific.

Every agent in a chain must carry a verified identity that persists across the interaction. The canonical Agent-ID, cryptographically derived from the genesis document, does this.

Authority delegation must be explicit, bounded, and verifiable. When an orchestrator delegates a task to a subagent, the scope of that delegation must be declared, not inherited by default. A subagent cannot operate under broader authority than was explicitly delegated to it for the specific task.

Governance verdicts must be respected across the chain. A DENY from a subagent is a governance event, not a service failure. The upstream system has to handle it as such.

The audit trail must span the entire chain, not just individual agent evaluations. The record of what Agent A instructed, what Agent B evaluated, what verdict resulted, and what action followed must be a single, connected record, not three separate logs that need to be manually correlated after an incident.

And the accountability chain must be resolvable. At the end of any multi-agent interaction, it must be possible to answer the question of which human is accountable for which decision in the chain.

These requirements are achievable. They are not the default. And the organizations that build multi-agent systems without addressing them are not just building governance gaps. They are building governance gaps that multiply with every agent added to the chain.

---

If you find this content valuable, please share it with your network.

Follow me for daily insights.

Book me to speak at your next event.

Start managing your agents for free.

Chris Hood is an AI strategist and author of the #1 Amazon Best Seller Infailible and Customer Transformation, and has been recognized as one of the Top 30 Global Gurus for Customer Experience. His latest book, Unmapping Customer Journeys, will be published in 2026.