We are getting very good at making agents talk to each other.
That is real progress. It is also not the same thing as making those conversations accountable.
The agent infrastructure conversation is moving fast around protocols, interoperability, tool access, context sharing, and multi-agent coordination. MCP gives AI applications a more common way to connect to external systems: tools, data sources, and workflows. Anthropic described it as an open standard meant to replace fragmented integrations with a single protocol for connecting AI systems to the data they need. Google’s Agent2Agent work makes the same broad point from the agent-collaboration side: if agents are going to operate across products and platforms, they need a way to discover one another, exchange information, coordinate actions, and return useful artifacts.
Good. The plumbing matters.
A world where every agent integration is bespoke glue is a world where serious agent systems stay fragile. Protocol work lowers the cost of connection. It gives builders shared shapes for messages, capabilities, tools, tasks, and artifacts. It makes the next layer of the stack possible.
But there is a category error hiding in the excitement.
Transport is not governance.
A protocol can tell two agents how to exchange a task. It does not, by itself, decide whether the receiving agent is allowed to act, which state is safe to inherit, what evidence must survive the handoff, where human review belongs, or who owns recovery when the chain goes wrong.
That is the next bottleneck for agent teams.
Not whether agents can message each other. Not whether they can call a tool. Not whether they can package a result in a cleaner artifact format.
The harder question is whether a human operator can look at the system after the fact and answer five plain questions:
- Who had authority?
- What state crossed the boundary?
- What evidence justified the action?
- Who could review or override it?
- How does the system recover if the handoff was wrong?
If those answers are missing, you do not have an agent team yet. You have a demo with better plumbing.
The protocol layer is necessary, but it is not the operating model
The useful way to separate this is to split the stack into two layers.
The transport layer is about exchange. Messages. Tool schemas. Capability discovery. Context windows. Artifacts. Async task updates. Interoperability between agents and systems.
The governance layer is about responsibility. Authority. Scope. Memory boundaries. Evidence. Approval. Override. Rollback. Auditability.
Both layers matter. Confusing them is where teams get into trouble.
The nuance matters because current protocol work is not blind to these concerns. The A2A specification, for example, explicitly talks about enterprise readiness, authentication, authorization, security, privacy, tracing, monitoring, asynchronous work, human-in-the-loop interactions, and audit trails for sensitive operations. That is not trivial. It means protocol builders understand that agent collaboration touches real operational risk.
But a protocol affordance is not the same thing as your governance model.
Your system still has to decide what authority an agent receives when it accepts a task. Your system still has to define what context may cross from one boundary to another. Your system still has to preserve the evidence needed for review. Your system still has to know when to stop. Your system still has to recover from a bad handoff without turning the incident into a scavenger hunt.
Protocols can make handoffs legible. Governance makes them delegable.
That distinction is going to matter more as agent teams become less theoretical.
Where agent teams actually break
The scary failure mode is not always an agent that obviously crashes.
Sometimes the chain keeps moving after the authority, evidence, or owner fell out of the envelope.
Imagine a support workflow. A research agent summarizes a customer issue. A support agent uses that summary to decide the customer deserves a credit. A billing agent receives the request and changes account state.
Nothing in that story requires science fiction. It is just a chain of task delegation across specialized agents.
Now look at what can go wrong.
The support agent inherits more customer context than it needs. The billing agent receives the requested action but not the authority boundary around the request. The final account change is logged, but the evidence that justified the credit is buried in an earlier step. A human reviewer can see that something happened, but not why. Rollback requires reconstructing the chain manually because no one recorded who authorized what.
That is not a messaging problem. The agents may have communicated perfectly.
It is a governance problem.
OWASP’s 2025 LLM application guidance names “excessive agency” as a risk when LLM-based systems get too much functionality, too many permissions, or too much autonomy. Their prevention guidance points in the direction operators should already recognize: minimize permissions, require approval for high-impact actions, mediate downstream access, and log or monitor consequential activity.
That is the practical version of the problem. Once agents can use tools and pass work to other agents, authority becomes a design surface. If authority is implicit, the system will invent its own answer at runtime.
And runtime is the worst place to discover your governance model.
Minimum viable governance for agent teams
The answer is not to stop building protocols. The answer is to wrap protocol adoption in an operating model.
A serious agent team needs at least five governance primitives.
First: an authority budget.
Every agent should have an explicit boundary around what it may decide, request, mutate, approve, and escalate. Not a vague role description. A real boundary. The billing agent may draft a credit recommendation but cannot issue it above a threshold. The deployment agent may prepare a release but cannot ship if tests, review, or environment checks are missing. The research agent may summarize sensitive context but cannot pass the whole record downstream by default.
Second: a state-transfer contract.
A handoff is not just a message. It is a boundary crossing. The contract should define what context travels, what must be revalidated, what is deliberately withheld, and what assumptions expire at the boundary. Agent memory makes this more important, not less. A receiving agent should not inherit stale state, private context, or hidden assumptions just because the previous step had access to them.
Third: an evidence requirement.
Every consequential action needs a trail that survives the handoff. Not only the final output. The inputs, source artifacts, tool readbacks, approval state, and reason the agent believed the action was valid. NIST’s AI Risk Management Framework makes this point in broader governance language: documentation can improve transparency, human review, and accountability. In agent teams, documentation is not paperwork after the fact. It is how the next agent and the human operator know what they are allowed to trust.
Fourth: a human override point.
Human-in-the-loop is not a magic phrase. If every step asks for approval, the system becomes unusable. If no meaningful step asks for approval, the system becomes dangerous. The useful design question is sharper: which boundary crossings create enough risk that the system must pause?
High-impact account changes. Production writes. Sensitive data transfer. Customer-visible commitments. Security-sensitive tool calls. Anything where an agent’s confident mistake can create real cleanup work.
Those are override points. Design them explicitly.
Fifth: a rollback plan.
Failed handoffs should not require an archeological dig. The system should know what changed, which agent changed it, which evidence justified it, who reviewed it, and what recovery owner takes over when the chain breaks. Rollback is not only a database concern. It is an operating concern for delegated work.
The clean phrase for this is a governed handoff envelope: request, scoped authority, evidence bundle, review state, and recovery owner.
If an agent cannot carry that envelope across a boundary, it should not carry production authority across that boundary either.
The operator test
The more successful the protocol layer becomes, the more urgent this governance layer becomes.
That sounds backwards only if you think connection is the finish line.
Better interoperability means more agents can reach more tools, transfer more context, and coordinate across more surfaces. That is useful. It also expands the blast radius of bad assumptions. A brittle single-agent workflow can fail locally. A brittle agent team can pass the failure forward until it becomes hard to tell where the original mistake entered the system.
This is why I do not evaluate agent-team infrastructure by asking only whether the agents can collaborate.
I ask what survives collaboration.
Do not ask only whether the handoff works. Ask whether the authority model is visible. Ask whether the receiving agent knows what it is allowed to do. Ask whether state was scoped or dumped. Ask whether evidence crossed the boundary. Ask whether the system can stop before a high-impact action. Ask whether a human can reconstruct the chain without reading tea leaves in logs. Ask whether rollback is designed or improvised.
Protocols are how agent systems become interoperable enough for this problem to matter at scale.
Governance is how those systems become trustworthy enough to delegate to.
The teams that win will not be the ones with the fanciest handoff demo. They will be the ones whose handoffs can be inspected, trusted, and reversed.
That is the operator line.
Before you ask whether your agents can talk to each other, ask whether you can govern what happens after they do.