The Conversation With No Owner: Accountability Dissolves Across an Agent Handoff Chain

A support request comes in: "My subscription got charged twice, cancel one and refund it." A router agent classifies it as billing and hands off. A billing specialist looks up the account, confirms two charges, and hands the refund to a tool-calling sub-agent. The sub-agent issues one refund, then a summarizer writes back to the customer: "Done — your duplicate charge has been refunded." Every step is individually correct. The customer was charged three times, not two. One duplicate is still on their card, and the summarizer had no way to know, because by the time the conversation reached it, the number "2" had already hardened into fact four steps upstream.

Now run the postmortem. Whose bug is it? The router classified correctly. The specialist read the two charges it was given. The tool agent refunded exactly what it was told. The summarizer summarized accurately. Pull up each agent's trace in isolation and every one of them passes. The system failed and no component did. This is the conversation with no owner, and it is the defining operational failure of multi-agent architectures — not a model being dumb, but responsibility diffusing across a handoff chain until no single agent is on the hook for the outcome the user actually experienced.

We already know how this ends because we've watched it happen to org charts. A request enters a company, bounces between four teams that each do their part, and comes out wrong — and the retro concludes that "the process" failed, which is the corporate way of saying nobody did. Multi-agent systems reproduce the same pathology in software, faster and with less visibility. The uncomfortable finding from recent research is that this isn't a rough edge you'll polish away with better prompts. Berkeley's MAST study annotated over 1,600 execution traces across seven multi-agent frameworks and found failure rates between 41% and 87% — and the majority of those failures were properties of interaction, not of any individual agent. You cannot fix an interaction failure by making each participant smarter.

Step-Level Correctness Is Not Conversation-Level Correctness

The trap is a category error that feels like rigor. You test each agent. The router hits 98% classification accuracy on your eval set. The billing specialist answers its questions correctly. The refund tool has unit tests. You ship, reasonably confident, because every piece is measured and green. Then production hands you outcomes that no single piece is responsible for.

The distinction that matters is between step-level correctness — did this agent do the right thing given its inputs — and conversation-level correctness — did the user get the outcome they asked for. These are different properties, and the second does not decompose into the first. An agent can be correct given its inputs while its inputs are already wrong, and it will confidently build on the error because nothing in its context tells it the ground is soft. MAST's taxonomy sorts the 14 documented failure modes into three buckets, and the shape is telling: Specification Issues (about 42%), Inter-Agent Misalignment (about 37%), and Task Verification (about 21%). Roughly four out of five failures live in the seams — in how work is specified and passed between agents — not in the agents themselves.

Here's the part that makes it dangerous in production: every one of those failures returned HTTP 200. There is no stack trace for "the summarizer believed a number that was wrong two hops ago." A subtly wrong intermediate output passes through the pipeline intact, and every downstream agent treats it as fact. The error doesn't cancel out across steps — it compounds, silently, with no alert, because from each agent's local vantage point everything is fine. Your dashboards are green. Your customer is not.

Handoffs Diffuse Responsibility the Way Silos Do

Why does adding agents make ownership worse rather than better? Because a handoff is a place where context gets lossy and nobody is contractually on the hook for what survives the crossing.

When the router passes to the billing specialist, it passes a compressed summary of intent, not the full conversation. When the specialist passes to the tool agent, it passes a further-compressed instruction. Each boundary is a lossy re-encoding of the user's actual request, and — critically — each agent optimizes for its local task, not the global outcome. Unlike microservices, where team A calls team B through a typed contract that fails loudly on a schema mismatch, agent-to-agent handoffs ride on natural language. A planning agent's ambiguous briefing to a downstream agent doesn't throw an error. It just gets interpreted, plausibly and wrongly, and execution continues.

This is exactly the incentive structure of organizational silos. Each team is measured on its own SLA, so each team optimizes its own slice and lets the cross-team outcome be somebody else's problem. More specialization doesn't help — it fragments the request across more boundaries, and every new boundary is a new place for intent to leak and for ownership to evaporate. The most-cited failure mode in production handoff graphs is the infinite loop: A hands to B, B hands to C, C hands back to A, and each agent keeps replanning because none of them owns getting to done. Specialization was supposed to buy reliability. Past a certain point it buys diffusion.

The Accountability Primitives That Actually Help

None of this is an argument against multi-agent systems. It's an argument that if you fan work out, you have to deliberately re-concentrate accountability — it will not happen on its own. Three primitives do most of the work.

A single owning agent that stays on the hook end to end. Somebody has to be responsible for the outcome the user experienced, not for a step. Concretely: one supervisor agent holds the original, uncompressed user request for the whole lifetime of the conversation, dispatches to specialists, and validates their returns against what the user actually asked for — not against what it delegated. When the tool agent reports "refunded one charge," the owner is the one that remembers the user said "twice," notices the arithmetic doesn't close, and reopens the task. Ownership means the buck stops at an agent that can see the whole outcome, not just its own hop. If no agent in your topology can, you don't have an accountability gap you can prompt away — you have a missing role.

Explicit contracts at each handoff boundary. Borrow from delegation theory: a handoff should carry the task, the authority granted, the work product expected back, and the acceptance criteria for that work. Instead of "handle the billing thing," the contract is: refund all charges matching this transaction signature; you may refund up to the disputed amount; return the count and IDs of every refund issued; success means refunded count equals duplicate count. Now the boundary has a predicate that can fail loudly instead of an instruction that gets interpreted quietly. You're trading natural-language vibes for something closer to a typed interface — the thing that made microservices debuggable in the first place.

An outcome-level trace that survives the fan-out. Give the entire conversation one correlation ID, and thread it through every agent call, tool invocation, and handoff, so the whole thing reconstructs as a single trace from initial query to final response — not as disconnected logs you reassemble by hand at 2 a.m. This is distributed-systems observability applied to agents: one trace, many spans, parent-child relationships preserved across every handoff. The point isn't just faster debugging. It's that the trace becomes the artifact you can attach a conversation-level verdict to. You can finally ask "did this whole interaction succeed?" as a first-class question, because there's finally a single object that represents the whole interaction.

Design for the Postmortem You'll Actually Run

The tell that you have this problem is a specific, deflating postmortem: the outcome was wrong, you replay every agent, and every agent was right. If that meeting sounds familiar, the fix is not another eval on an individual component. It's asking, before you add the next specialist to your graph, three questions.

Which single agent is accountable for the outcome this user experiences — and can it actually see that outcome, or only its own hop? What is the explicit contract at each handoff, and does a violation fail loudly or get quietly interpreted? And when this conversation goes wrong, will there be one trace that represents the whole interaction, or four sets of logs that each look fine?

Specialization is genuinely useful; the mistake is assuming it's free. Every agent you add divides the work, and unless you deliberately re-concentrate accountability, it also divides the ownership until there's none left at the level the user cares about. The systems that hold up in production aren't the ones with the most agents or the cleverest routing. They're the ones where, no matter how far the work fans out, one agent never stops being responsible for the answer the user actually got.