The Agent Stack Is Getting Protocols Before It Gets Governance

The agent stack is standardizing the easy part first.

That is not an insult. It is the normal order of infrastructure. Before teams can govern distributed work, they need a way for the work to move. Before they can inspect a handoff, they need a handoff. Before they can operate agent teams, the agents have to be able to reach tools, share tasks, and talk across product boundaries.

That layer is arriving.

Agent protocols such as MCP and A2A are standardizing the communication layer. MCP gives AI applications a more common way to connect to tools, data, and external systems. A2A gives agents a protocol shape for communicating with other agents, discovering capabilities, exchanging tasks, and returning artifacts. Agent SDKs are packaging handoffs, guardrails, sessions, and tracing into developer primitives instead of leaving every team to invent the same glue.

Good. The protocol layer matters.

But protocol compatibility is not production readiness.

The question that matters after agents can talk is not only, "Did the message arrive?" It is: who authorized the work, what authority traveled with the request, what evidence survived the handoff, where did review happen, what changed, and who owns recovery if the chain is wrong?

That is the governance gap in agent systems right now.

Protocols are making exchange legible faster than the industry is making delegated work accountable.

Protocols are plumbing, not permission

A protocol can describe how one system talks to another. It can define message shapes, task objects, artifacts, authentication schemes, transport behavior, and capability discovery. Those are important abstractions because bespoke integrations break at exactly the moment teams try to scale past demos.

The mistake is treating that plumbing as permission.

There is a difference between:

this agent can reach a tool,
this agent is allowed to use that tool for this user,
this request has enough evidence to proceed,
this action is reversible,
this output can leave the building,
and this chain has an owner when it fails.

Those are not transport questions. They are operating questions.

Protocols can move work between agents. Governance decides whether that work should be allowed to keep moving.

MCP is a useful example because its own documentation is careful about this boundary. It describes MCP as an open standard for connecting AI applications to external systems. It also includes authorization and security guidance, including concerns around permissions, token handling, confused-deputy risks, SSRF, and scope minimization. That is exactly the point. The protocol can expose the security surface and provide mechanisms. The application, organization, and operator still have to decide the authority model.

A2A has a similar shape. Google's announcement frames it as an open protocol for agents to communicate, securely exchange information, and coordinate actions across enterprise applications. The A2A specification describes interoperability between independent, potentially opaque agent systems. That is valuable. It also makes the next layer more urgent: if systems are intentionally independent and opaque, the receiving side needs a way to understand what it is being asked to trust.

The road can be well paved while the traffic rules are still immature.

Governance means control of work, not committee theater

"Governance" is a dangerous word because it can sound like a policy binder dropped on top of engineering.

That is not the version worth building.

In agent systems, governance means the control layer around delegated work. It is the practical answer to five questions:

Authority: what is this agent allowed to do, for whom, in which context, against which system?
Review: which actions need a human, policy, or peer check before side effects happen?
Evidence: what sources, tool results, assumptions, and prior decisions shaped this action?
Recovery: can the system stop, replay, compensate, or roll back when the chain goes wrong?
Ownership: which human or team owns the outcome after the work crosses agent boundaries?

That is not bureaucracy. That is how production systems stay operable.

The control layer can be lightweight. It can be mostly automated. It can live in product surfaces, logs, policies, approval gates, traces, or runtime checks. But it has to exist somewhere. Otherwise a multi-agent workflow becomes a sequence of confident local decisions with no durable chain of responsibility. The scary failure mode is not an agent that obviously breaks. It is a chain that keeps moving after the authority, evidence, or owner fell out of the envelope.

This is where the protocol conversation is too small.

A protocol can carry a request. It cannot know whether the request is appropriate for the user's role, the customer's risk, the organization's policy, the freshness of the data, or the reversibility of the action. It cannot decide whether a manager's approval for one step should travel to the next three steps. It cannot decide whether a summary from a previous agent is enough evidence for a production mutation.

Those decisions sit above the protocol. The useful primitive is a governed handoff envelope: request, scoped authority, evidence bundle, review state, recovery owner, and outcome owner.

The handoff is the design object: request plus authority, proof, review state, and a named recovery owner.

Where handoffs break

The failure modes are not exotic. They are ordinary operator problems wearing agent clothes.

A support agent routes a refund case to a billing agent. The billing agent has tool access. A policy agent checks eligibility. A communications agent drafts the customer reply. The demo headline is simple: multiple agents collaborated to resolve a customer issue.

The operator questions are different:

Did the support agent have authority to bring billing data into the workflow?
Did the billing agent only recommend a refund, or could it issue one?
What policy version did the policy agent use?
Did the communications agent see approved facts or raw private history?
What evidence traveled with the handoff?
Who can reconstruct the chain if the refund was wrong?
Who reverses the action if the wrong promise goes to the wrong customer?

None of those questions are answered by "the agents exchanged messages."

Customer-facing chains need review and rollback before the polished answer reaches the customer.

The same pattern shows up in code review, sales operations, finance, legal intake, analytics, incident response, and publishing. Once an agent can affect something outside the chat window, the handoff is no longer just context transfer. It is authority transfer.

That is the part most demos hide.

The work appears to move smoothly because every local step has enough information to continue. But smooth continuation is not the same as safe continuation. Stale state can move forward. An approval can travel too far. A tool can be available without a review model. A summary can erase the evidence the next actor needed. A failed chain can leave no obvious recovery owner.

The system still "worked." That is the danger.

The control layer is starting to surface

The good news is that the market is already reaching for the missing layer.

OpenAI's Agents SDK does not only talk about agents. It includes handoffs, guardrails, sessions, and tracing. That vocabulary matters because it moves the discussion from "can an agent do a task?" toward "can we constrain, observe, and debug the flow of work?"

OWASP's excessive-agency risk makes the same point from the security side. The problem is not merely that a model might make a bad decision. It is that an application may give the system too much functionality, too many permissions, or too much autonomy. The recommended mitigations include minimum permissions, user approval for high-impact actions, and complete mediation in downstream systems instead of trusting the model to decide authorization by itself.

NIST's AI Risk Management Framework and generative AI profile are not agent-protocol standards, but they point at the same operating concerns: governance, provenance, testing, incident handling, transparency, and accountability across systems and value chains.

Different vocabulary, same direction.

The durable advantage will not belong to the team with the longest connector list. Connectors will become table stakes. The advantage will belong to teams that make connected work governable: scoped authority, visible state, durable evidence, review before damage, and recovery when the chain fails.

The operator's adoption checklist

When a vendor, framework, or internal platform says it supports multi-agent workflows, I would not start with the protocol diagram.

Do not ask only whether agents can hand off. Ask what survives the handoff. I would ask for the governance envelope around each handoff.

Before trusting a connected agent chain, ask:

What authority does each agent receive, and how is it narrowed at the boundary?
Which actions are read-only, reversible, expensive, destructive, customer-visible, or compliance-sensitive?
What evidence travels with the task, and what gets dropped as a summary?
Can the next agent distinguish verified facts from assumptions?
Where does human or policy review happen before side effects?
Does approval attach to one action, one task, or the whole chain?
Can the workflow stop safely when required metadata is missing?
Can an operator replay the decision path after the fact?
Who owns rollback, customer communication, and incident response?

That checklist is not anti-protocol. It is what protocols make necessary.

The easier it becomes for agents to exchange work, the more important it becomes to know what kind of work is being exchanged. A fast handoff without authority, evidence, and recovery is just a faster way to lose the thread.

Protocols will matter more when governance catches up

The agent stack needs protocols. MCP, A2A, and adjacent runtime primitives are useful because they reduce bespoke glue and give builders a shared language for tools, agents, tasks, messages, artifacts, and traces.

But the next wave is not just agent interoperability.

It is agent governance.

Not governance as theater. Governance as the operating contract that makes delegation survivable:

authority travels narrowly,
state travels explicitly,
evidence travels durably,
review happens before irreversible action,
recovery has an owner.

Protocols carry the work.

Governance decides whether the work should proceed, how it can be trusted, and what happens when it is wrong.

If you cannot prove that after the handoff, you do not have a production agent team yet. You have connected agents and an accountability debt.