An investigation agent working a case needed to know whether a claim had already been paid. Rather than query the claims system itself, it did the modern thing and asked the claims agent. The claims agent answered in one clean sentence, "paid on the 14th," and the investigation agent wrote that into its case summary as established fact and moved on. What the claims agent had actually done was read a record that was halfway through a reversal, hedge internally at something like sixty percent, and round that hedge up to a tidy sentence on the way out the door. None of the doubt fit in the sentence. By the time the answer reached the investigator, a maybe had become a fact, and the fact arrived with no fingerprints on it.
The part worth staring at is that both agents behaved reasonably. The claims agent gave its best available answer. The investigation agent trusted a system that was built to be trusted. The failure was not inside either agent. It lived in the space between them, in the hand-off, where one agent takes another agent's output and treats it as its own knowledge. That space is exactly what agent-to-agent protocol governs, and it is where most multi-agent systems quietly lose the ability to say where a conclusion came from.
The hand-off is the dangerous moment
Almost every conversation about multi-agent AI is about the agents. How many, how smart, how they divide the work. We spend our time somewhere less glamorous, on the seam between them. When a human analyst gets an answer from a colleague, the source usually rides along with it: "Priya thinks it's paid, but she wasn't certain, and she was looking at yesterday's export." Agents strip all of that off. Agent B returns a clean string, agent A ingests a clean string, and the qualification that made the answer honest does not survive the trip, because a string has no room for it unless the protocol makes room.
So each hop launders a little uncertainty into confidence. B's sixty percent becomes A's hundred percent. A's summary, which now reads as settled, gets consulted by a third agent that treats it as settled, and the doubt that should have followed the claim from the very first record is three hops gone. Nobody lied. The system simply had no mechanism to carry the truth across a boundary, so it carried the convenient version instead. In a single-agent workflow this rarely bites, because the reasoning stays in one place. Wire several agents together and the seam becomes the most important surface in the architecture, and usually the least examined.
Three things that have to survive the hop
We wrote earlier about the wiring beneath the agents, MCP and A2A together, as the part of an enterprise AI architecture that actually decides whether a program ships. This is the narrower version of that argument, aimed at one seam. When agent A acts on agent B's answer, three things have to cross the boundary intact, and in most stacks running today at least one of them does not.
The first is identity and authority. When A asks B to do something, B should act as A's delegate, carrying the original user's authority scoped down to the task, rather than acting as itself with whatever reach it happens to own. Skip this and A2A turns into a privilege-escalation ladder: A is not allowed to touch the payments system, but B is, so A asks B, and now A has done by proxy what it was forbidden to do directly. This is the classic confused deputy, wearing the costume of collaboration. We spent a whole post on the keys nobody signed for, the un-onboarded identities agents run under. A hand-off is where those identities either stay least-privilege or silently pool their permissions.
The second is provenance and confidence. B's answer should arrive with where it came from and how sure B is, not as a bare assertion. If B read the fact from a document, A should be able to see which document and how fresh it was, because a claim grounded in a record that was retired last week is not the same claim as one grounded in today's. If B was sixty percent sure, A should inherit sixty percent, not round it away. An answer that cannot say where it came from is a liability in a nice font whether a model produced it or a sibling agent did. The hop is where provenance is most likely to fall off, because passing a clean conclusion feels helpful and passing all the caveats feels like clutter.
The third is the trace. The audit record has to span the hand-off, not stop at it. A decision that crossed three agents is a graph of who contributed what, not a log line, and if the investigator's conclusion is challenged six months later, the trail cannot be allowed to dead-end at "the claims agent said so." Someone has to be able to walk it back: A concluded this because B told it that, and B said it because it read this record at this version under this authority. That chain either assembles from one trace or it does not exist.
Another agent's output is untrusted input
The mental shift that fixes most of this is uncomfortable and cheap. An agent on the other end of an A2A call is not inside your trust boundary just because it is also one of your agents. It can be wrong, it can be working from stale data, and on a bad day it can be compromised. The discipline you would apply to input arriving from an external system is exactly the discipline that belongs on input arriving from a sibling agent: check it, bound what it is allowed to cause, and refuse to let its confidence become yours by default.
This matters most when something has gone wrong upstream. A poisoned document read by B becomes B's answer, becomes A's action, and the injection has now traveled a hop further into your systems than the attacker had any right to reach. We described the blast radius of a helpful agent as the real security question for enterprise AI. In a multi-agent system the blast crosses agents, and it crosses them fastest precisely where one agent trusts another without inspection. The seam that makes the system powerful is the same seam that lets a single bad input ride from agent to agent wearing each one's credibility in turn.
Fewer hops, and cleaner ones
Part of the answer is to want fewer agents in the first place. We have argued against the swarm you didn't need, because every additional agent is another seam where accountability can leak, and the count of agents in a diagram measures how much control you gave away, not how advanced the system is. Each hop you remove is a hand-off you no longer have to govern.
But some work genuinely needs more than one agent. A sourcing agent on MatryxAI really should consult a compliance agent before it recommends a new supplier. An investigation agent on Throughline really does need to ask a claims agent what a policy paid. The answer for those cases is not to avoid A2A, it is to make each hop a governed event instead of a shrug. When identity is delegated, provenance rides along, and the trace spans the boundary, a hand-off becomes something you can defend rather than something you hope held. The goal is not the fewest possible agents at any cost. It is the fewest hops the work requires, each one carrying its full weight.
When one agent takes another at its word, the question is not whether the second agent was right. It is whether anyone can still say where the answer came from, and how sure the system had any business being.
This belongs under the stack, not in every agent
The contract for a hand-off, delegated identity, provenance carried forward, a trace that reads end to end, is the same contract for every pair of agents that will ever talk. That is the reliable sign it should not be reinvented inside each solution. If Throughline defines its own notion of what a hand-off carries and Clairant defines a different one and NeuraMed a third, the audit graph fragments at exactly the seams where a regulator will want it whole, and the confidence that survives a hop depends on which two teams happened to wire it.
In our architecture the A2A contract lives in Neura-Cortex, the shared substrate under the solutions, next to the identity, the guardrails, the routing, and the audit log. An agent handing work to another agent inherits the rules of the hand-off the same way it inherits its own identity: the authority is delegated and scoped by the platform, the provenance and confidence are carried by the protocol rather than by the goodwill of each caller, and the whole chain lands in one audit log because the layer that carried the call is the layer that keeps the record. Build the seam once, carefully, and every cross-agent call in the portfolio gets to be trustworthy the same way, instead of each pair of agents negotiating its own private definition of trust.
What we ask of every hand-off
Before one agent acts on another agent's answer in our workflows, there is a short list of questions the hand-off has to get through. Whose authority did the second agent act under, its own or a scoped-down delegation of the original user's? Where did its answer come from, which source, at what version, how fresh? How confident was it, and did that confidence survive into the first agent's decision or get rounded up to a clean fact along the way? Was its output treated as untrusted input and checked, or absorbed as gospel because it came from one of ours? And when the whole thing is questioned later, does the chain read as one trace, or as three separate logs in three systems that nobody can stitch back together?
A system that cannot answer those is not coordinating its agents. It is letting them vouch for each other and calling the vouching an architecture. Most multi-agent stacks in production today would stumble on at least two of these, for the same reason the claims answer went out clean: passing the tidy version across a seam feels like cooperation, and the machinery required to pass the honest version feels like friction, right up until the day someone has to explain how a maybe became a fact.
Find the last time one of your agents acted on another agent's output. Now answer two things. If the second agent had been wrong, how many further agents would have repeated its answer before anyone noticed, and how far would the mistake have traveled? And can you show, from a record rather than from memory, where the first agent's conclusion actually came from? If both answers come easily, you have a real seam. If the honest answer is that your agents trust each other because they are all yours, then the thing holding your multi-agent system together is a family resemblance, and a family resemblance has never survived an audit.
The claim that started this was reversed in the end. The payment came back three days later, and the investigator's summary still read "paid on the 14th," because nothing had told it otherwise. That is the quiet cost of a seam that carries only the answer. The mistake was small and it got caught, this time, by a person who happened to reread the file. The systems worth building do not lean on that person being there. They make the second agent hand over its doubt along with its answer, so that when the record moves, the conclusion resting on it moves too. That costs a little speed, and it buys back the one thing a multi-agent system cannot fake: the ability to say, months later and under questioning, exactly how it came to believe what it believed.
MTekLabs designs, deploys, and governs production-grade agentic AI platforms for government and commercial enterprises. Our solutions are built human-in-the-decision-loop where it matters and auditable by design. Explore them at mteklabs.com.
What does a hand-off carry between your agents?
We would be glad to walk through what actually crosses the seam when one of your agents acts on another's answer, and what it takes to make delegated identity, provenance, and an end-to-end trace ride every hop, so a multi-agent system stays as accountable as a single one.