The agent stack is getting much better at moving work around.
Agents can call tools through common interfaces. They can discover other agents. They can exchange task state, stream progress, and sit inside the places teams already work. That is real progress. The protocol layer matters because bespoke integration is one of the fastest ways to turn an agent system into a fragile demo.
But a clean handoff is not the same thing as an accountable handoff.
A message can arrive perfectly and still leave the operator unable to answer the questions that matter: who authorized this action, what state traveled with it, what evidence survived the exchange, where review happened, and who owns reversal if the chain produces the wrong result.
Watch that gap in agent infrastructure right now.
Protocols are starting to solve transport before the industry has settled the operating model above transport. They can carry work. They do not automatically govern work.
The protocol layer is becoming real plumbing
The direction is easy to see.
A2A describes itself as an open standard for communication and collaboration between AI agents. Its own docs draw a useful boundary: MCP is for agent-to-tool communication; A2A is for agent-to-agent communication. The Google launch post framed A2A as a way for agents to communicate, securely exchange information, coordinate actions, and work across enterprise applications.
MCP is doing similar plumbing work from the tool and context side. The MCP introduction describes it as an open-source standard for connecting AI applications to data sources, tools, and workflows. That is the right abstraction. If agents are going to act in real systems, they need a more consistent way to reach the systems where work actually lives.
I am not skeptical of that layer. I want it to get better.
Standardized exchange reduces integration drag. It makes tools and agents easier to compose. It gives builders a shared vocabulary for capabilities, tasks, context, and results. It also creates a market where teams can ask less "can these two things speak at all?" and more "what happens after they speak?"
That second question is where the work gets harder.
Plumbing is not accountability
A protocol can tell two systems how to exchange work. It cannot, by itself, decide the organization's authority model.
That distinction sounds obvious until you look at how people talk about agent stacks. Interoperability gets treated like maturity. If an agent can reach the tool, if one agent can hand work to another, if the message passes through a standard envelope, the system starts to feel production-ready.
But production readiness is not a transport property.
It is an accountability property.
The MCP specification is careful here. It explicitly names security and trust concerns around arbitrary data access and code execution paths. It says implementors need to address user consent, control, privacy, and review/authorization experiences. The point is simple: the protocol can expose the surface, but the host, product, operator, and organization still have to decide what should be allowed.
There is a difference between:
- this agent can call a tool,
- this agent is allowed to call this tool for this task,
- this action has enough evidence to proceed,
- this action can mutate production state,
- this output can be shown to a customer,
- and this result can be reversed if it is wrong.
Those are not the same question.
A protocol can support authentication. It can define message shapes. It can expose capabilities. It can carry context. It can make progress observable. All useful.
But the protocol does not know your customer risk, your internal approval policy, your data boundaries, your rollback process, your brand risk, or whether the next agent in the chain is inheriting authority it should not have.
That layer has to be designed.
Handoff is the design object
The mistake is evaluating agent teams by whether agents can talk.
The better test is whether the handoff is accountable.
A handoff is not just "Agent A sends a task to Agent B." It is a state-transfer decision. It decides what the receiving actor knows, what it is allowed to do, what proof it can rely on, and where it must stop.
A weak handoff says:
Here is the task. Continue.
An accountable handoff says:
Here is the task, the current state, the source evidence, the constraints, the authority scope, the open questions, the required review boundary, and the return artifact expected from you.
In implementation terms, the envelope is: task, current_state, evidence_refs, constraints, authority_scope, review_boundary, rollback_owner.
Less magical. More operable.
The five pieces I would look for are simple:
- Authority: who is allowed to act, approve, spend, publish, mutate data, or escalate?
- State: what task context, assumptions, constraints, and memory are moving across the boundary?
- Evidence: what sources, tool calls, observations, and decisions survive for the next actor to inspect?
- Review: where does human or policy judgment happen before irreversible action?
- Rollback: who owns reversal when the chain produces a bad result?
If those five pieces are missing, the handoff may still work. That is the danger. It can work as an unaccountable workflow.
A concrete example: the customer-impacting agent chain
Imagine a support workflow.
A triage agent reads a customer complaint. It routes the issue to a billing agent. The billing agent checks invoices and proposes a credit. A policy agent evaluates eligibility. A communications agent drafts the customer reply.
The demo version sounds clean: multiple agents collaborated to resolve the issue.
The operator version asks different questions:
- Did the triage agent have authority to bring billing data into the workflow?
- Did the billing agent only propose a credit, or could it issue one?
- What invoice data and policy evidence traveled to the next agent?
- Did the policy check happen before the customer-facing promise was drafted?
- Did the communications agent see only the approved resolution or the full billing history?
- Who can reconstruct the chain if the credit was wrong?
- What happens if policy data was stale?
- Who reverses the action if the wrong customer gets the wrong promise?
None of those questions are answered by "the agents exchanged messages."
They are answered by the operating layer around the exchange.
The same pattern shows up in code, finance, legal review, sales operations, analytics, publishing, and internal automation. The moment an agent chain can affect something outside the chat window, the handoff has to carry accountability, not just context.
The product layer is already exposing the gap
This is why the interesting product signals are not only about agents speaking to agents. They are about the controls around delegated work.
Anthropic's Claude Tag is a useful public example. It lets teams tag Claude in Slack, give it access to selected channels, tools, data, and codebases, and run tasks asynchronously. But the more important details are the controls: admin-scoped access, channel-scoped memories, spend limits, activity logs, requester attribution, and moments where Claude tags humans back for decisions or review.
That is not just a convenience layer. It is the accountability layer starting to become visible in the product surface.
The serious version of agent operations will need more of this, not less:
- scoped tool access instead of universal tool access,
- explicit authority boundaries instead of implicit inheritance,
- durable logs instead of vibes from a chat transcript,
- review gates before external side effects,
- provenance that survives delegation,
- and rollback ownership when the chain fails.
This is where agent products will differentiate. The base ability to connect will become less special. The ability to make connected work governable will become more valuable.
The maturity test for every agent-stack claim
When someone says their agent stack is ready for multi-agent work, I would not start with the connector list.
I would ask about the handoff envelope.
What does the protocol carry, and what does the product decide above the protocol?
Can the next agent tell which authority it is operating under?
Can it see the evidence behind the current state, or only a summary from the previous actor?
Can it distinguish verified facts from assumptions?
Can it tell which actions are read-only, reversible, customer-visible, expensive, or destructive?
Where does review happen before side effects?
If a human approves one part of the chain, does that approval travel too far?
If the system stops, does it stop safely?
If the system acts incorrectly, who owns rollback?
Those questions are not anti-protocol. They are what protocols make urgent.
Once work can move more easily between agents and tools, the blast radius of a weak operating model grows. Faster handoffs without accountable handoffs just make failures harder to reconstruct.
What to build next
The agent stack needs the protocol layer. Keep building it.
A2A, MCP, and adjacent standards are useful because they make the substrate more legible. They reduce bespoke glue. They create common expectations for how agents, tools, context, and tasks can connect.
But the next frontier is not just more connection.
It is accountable connection.
The teams that get this right will not evaluate agent systems by whether agents can talk. They will evaluate whether the organization can still understand, review, constrain, and reverse the work after agents talk.
That means treating handoff as an operating contract:
- authority travels narrowly,
- state travels explicitly,
- evidence travels durably,
- review happens before damage,
- rollback has an owner.
Protocols carry the work.
Accountability governs the work.
If you cannot prove the difference after the handoff, you do not have an agent team yet. You have a message bus with ambition.