The protocol problem is getting easier.
That is the useful part of MCP, A2A, and the agent SDK wave. Agents can reach tools through more common interfaces. They can discover other agents. They can pass tasks, artifacts, status, and context without every team inventing the same bespoke glue.
Good. That layer needs to exist.
But accountability does not start when an agent sends a message. It starts after the handoff, when the next system has to decide whether the work is allowed to keep moving.
That is the narrower problem this post is about. Not governance as a whole. Not whether agent protocols matter. They do. The question is what a team can prove after one agent hands work to another and the chain keeps going.
The handoff is where responsibility gets blurry
A clean handoff can still lose the thing the operator cares about.
The payload arrives. The task looks well formed. The receiving agent knows what to do next. On paper, the system worked.
Then someone asks the uncomfortable questions:
- Who authorized the downstream action?
- What state did the receiving agent inherit?
- Which evidence came with the decision?
- Where did review happen?
- Who owns rollback if the result is wrong?
If those answers are not attached to the handoff, the protocol layer did its job and the operating layer still failed.
That distinction matters because agent systems do not usually fail like a single bad API call. They fail as chains. One tool call writes state. Another agent summarizes it. A third prepares the customer-facing response. A fourth updates the record. By the time a human sees the outcome, the original decision may be several hops away.
The dangerous failure is not always the agent that obviously breaks. It is the chain that keeps moving after authority, evidence, or ownership fell out of the envelope.
Accountability is a receipt, not a vibe
A lot of agent accountability talk gets too abstract. It turns into principles, policies, dashboards, and reassuring language.
In production, accountability needs to be more boring than that. It should look like a receipt that travels with the work.
For every meaningful handoff, the receiving system should be able to read:
- The request: what work is being handed off?
- The authority: who or what allowed this next action?
- The state: what facts, records, and assumptions is the agent relying on?
- The evidence: what proof supports the decision so far?
- The review state: has a human, policy, test, or verifier checked this?
- The recovery owner: who is responsible if the chain needs to be reversed?
That receipt does not need to be ceremonial. It can be metadata, a structured artifact, a trace span, a review packet, or a task envelope. The format matters less than the fact that the next agent cannot pretend the context is implicit.
Implicit context is where accountability disappears.
A concrete failure mode: customer-impacting chains
Take a refund workflow.
One agent reads the support ticket. Another checks billing. Another applies policy. Another drafts the customer response. Another updates the CRM.
Every step can be connected through clean protocol plumbing and still be unsafe.
The support agent may summarize the customer request correctly. The billing agent may find the right invoice. The policy agent may apply the wrong exception because it missed a recent account note. The communications agent may write a polished response that sounds final. The CRM update may record the outcome before anyone notices that the refund required approval.
Nothing about that failure requires a protocol bug.
The handoffs can all be technically valid. The problem is that the work crossed from information gathering into customer-impacting action without carrying enough accountability.
A safer chain forces the receipt to travel:
- support passes the customer request and ticket state;
- billing attaches invoice evidence and payment status;
- policy adds the applicable rule and confidence level;
- communications marks the reply as draft until review clears;
- the final update records the human or policy authority that approved the action;
- rollback ownership is named before the customer sees the result.
That is the difference between a chain that merely connects and a chain that can be inspected.
Protocols should make accountability easier, not optional
The point is not to slow agents down with bureaucracy.
The point is to make accountability cheap enough that teams actually use it.
Protocols help if they make the handoff legible. Common message shapes, task artifacts, capability discovery, and traceable exchanges give builders a place to attach the receipt. Without that substrate, every team has to bolt accountability onto private glue code.
But the protocol is not the receipt by itself.
A message envelope can carry authority, evidence, review state, and rollback ownership. It can also carry none of those things. The fact that the envelope arrived says very little about whether the work should proceed.
That is why the next layer of agent infrastructure has to care about what survives the handoff, not just whether the handoff happened.
The adoption test
Before putting an agent chain near customer data, money movement, production systems, or public communication, ask five questions.
Can we reconstruct the decision path?
Not just logs. A decision path. Which agent decided what, using which state, with which tool output, at which moment?
Can we identify the authorization boundary?
Some work is safe to automate. Some work needs approval. Some work must stop. If the system cannot tell where the boundary is, the handoff is under-specified.
Can the receiving agent see what changed upstream?
State drift is one of the easiest ways for a chain to become wrong while looking normal. The next agent needs more than a summary. It needs enough state to know what it inherited.
Can review happen before the irreversible step?
Review after the customer response, payment action, data deletion, or production update is not control. It is archaeology.
Can someone reverse the outcome?
If nobody owns rollback, the system is not accountable. It is just active.
Those questions are not anti-agent. They are how agent systems become safe enough to use on work that matters.
Where this fits with governance
The broader governance question is about the control layer above agent protocols: policy, authority, review, evidence, recovery, ownership, and operating discipline.
Accountability is one slice of that layer.
It is the slice that answers: after a handoff, can we prove what happened and assign responsibility for what happens next?
That makes it a good sequel to the protocol/governance discussion, not a replacement for it. Governance defines the operating rules. Accountability makes each handoff inspectable enough that those rules can mean something.
The agent stack needs both.
It needs protocols so agents can exchange work without custom glue everywhere. And it needs accountability receipts so operators are not left staring at a polished final answer with no idea how the chain got there.
The future agent stack will not be judged only by how easily agents connect.
It will be judged by whether the work remains attributable after it moves.