I Read 17 Agent Frameworks' Multi-Agent Docs. Three Cap the Cost. None Undo the Actions.

TL;DR: Multi-agent systems fail in production mostly on specification and coordination, not model quality. The one systematic study, the MAST taxonomy from UC Berkeley, classified 14 failure modes across 7 frameworks; summing its per-mode rates gives 44.2% system design and specification, 32.4% inter-agent misalignment, 23.5% verification and termination. On 2026-08-15 I opened the multi-agent docs page of 23 agent frameworks and platforms; 17 loaded. Of those, ten document what context a sub-agent receives, eleven a stopping rule, three a cost ceiling, and zero document how to undo an action an agent already took.

On June 12, 2025, Cognition published a post titled "Don't Build Multi-Agents". On June 13, 2025, Anthropic published how it built a multi-agent research system that beat its single-agent baseline. Two of the most credible agent shops, opposite conclusions, one day apart. Everything published since has mostly been vibes stacked on that split. There is one piece of systematic evidence underneath it, and one thing nobody had counted.

What does the only systematic study actually find?

MAST, the Multi-Agent System Failure Taxonomy, comes from Mert Cemri, Melissa Z. Pan and eleven co-authors at UC Berkeley, Matei Zaharia and Ion Stoica among them. Posted March 2025, revised October 2025. The taxonomy came from 150 hand-annotated traces at kappa 0.88 agreement, scaled to a released dataset of 1,642 traces across seven systems: ChatDev, MetaGPT, HyperAgent, AppWorld, AG2, Magentic-One and OpenManus.

Its abstract opens with a sentence vendors never quote: "Despite enthusiasm for Multi-Agent LLM Systems (MAS), their performance gains on popular benchmarks are often minimal."

Fourteen failure modes came out. The four most common, by the paper's own published rates: step repetition 15.7%, reasoning-action mismatch 13.2%, unaware of termination conditions 12.4%, disobey task specification 11.8%. Summing the modes inside each of its three categories gives system design and specification 44.2%, inter-agent misalignment 32.4%, task verification 23.5%. That sum is mine, not theirs.

Step repetition, unaware of termination conditions and premature termination together account for 34.3% of documented failures. A third of the failure mass is agents that do not know when to stop, when to stop repeating, or that they stopped early. The same defect that makes a single agent a cron job with anxiety, except now you pay for it in parallel.

What did I count in the frameworks' own docs?

MAST published its own percentages. The open question is whether the tooling addresses what it found.

The method, which anyone can repeat. On August 15, 2026 I opened the single page each framework's own docs present as its multi-agent, orchestration, teams or subagent guide: the page a builder lands on when wiring more than one agent together. On that page only, I recorded four safeguards. Context boundary: what a sub-agent does or does not receive from the parent. Stop rule: a termination condition, max turns, max iterations or a delegation depth cap. Cost cap: a token or spend ceiling that halts the run. Rollback: undoing, compensating or restoring after an action.

I attempted 23. Six never resolved: Google ADK, Letta, CAMEL-AI, Swarms, Dify and Vertex AI Agent Engine returned 404s or redirect loops. That leaves 17.

Framework	Context	Stop rule	Cost cap	Rollback
LangChain / LangGraph	yes	no	no	no
CrewAI	yes	yes	no	state only
AutoGen	yes	yes	no	state only
OpenAI Agents SDK	no	no	no	no
Bedrock Agents	no	no	no	no
Semantic Kernel	yes	no	no	no
Pydantic AI	yes	yes	yes	no
LlamaIndex	no	yes	no	no
AWS Strands	yes	yes	no	no
Agno Teams	no	no	no	no
smolagents	no	yes	no	no
Claude Agent SDK	yes	yes	yes	no
Foundry connected agents	no	yes	no	no
Anthropic Managed Agents	yes	yes	yes	no
MetaGPT	yes	yes	no	no
Haystack	yes	yes	no	no
Microsoft Agent Framework	no	no	no	state only

Two judgment calls, on the record. I counted Microsoft Foundry's documented delegation depth cap of 2 as a stop rule, since exceeding it errors rather than running forever. And Microsoft ships four of the seventeen, so the sample is less independent than it looks.

Why does the missing half matter?

Ten of seventeen document the context boundary, the safeguard against MAST's second-largest category. Eleven document a stop rule, aimed at the largest. Better than I expected.

Then the floor drops. Three of seventeen document a cost ceiling: Pydantic AI's UsageLimits with total_tokens_limit and cost_limit, the Claude Agent SDK's maxBudgetUsd, and Anthropic Managed Agents' session budget. Everyone else documents how to fan out and nothing about what it costs. Anthropic's own engineering post puts the number at "about 15x more tokens than chats." Fifteen times, undocumented, on a bill that was already going the wrong direction.

Rollback is worse, and it is the finding I did not expect. Three pages mention restoring something: CrewAI's Crew.from_checkpoint(), AutoGen's reset(), and Microsoft Agent Framework's "save and restore workflow progress." All three restore the framework's own internal state. Not one documents compensating for an action an agent already took in the world. Nothing about the email sent, the ticket closed, the row written.

MAST does not cover it either: none of the fourteen modes describes an action that executed correctly and should never have been taken. The taxonomy was built on benchmark traces, where a wrong action costs a score. In production it costs a customer.

Where does multi-agent genuinely win?

It wins where the work is read-heavy and genuinely parallel. Anthropic reports that "a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval." That is a breadth-first search task: many independent directions, each one mostly reading.

Their limits are as specific. "Most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time." Their early systems were "spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources." That is MAST's step repetition and termination failures, found independently by the team that shipped it.

Cognition's Walden Yan reached the opposite default from the same mechanism: "Subagent 1 and subagent 2 cannot see what the other was doing and so their work ends up being inconsistent." Both sides agree on the physics. They disagree on whether the fan-out is worth it, and the answer is the shape of your task, not your architecture taste. Same gap that opens when an agent demo meets real work.

What would change my mind?

Start with what this count does not prove. It measures documentation, not capability. A framework may enforce a spend cap on a billing page I did not open; my rule was one page per framework so the method stays repeatable. The generous reading is that the industry has built more safety than it advertises. It is still true that a builder following the multi-agent guide will not find it.

Three things would move me. A framework putting a spend ceiling and a compensation story on the same page as the fan-out example, because that is where the decision gets made. A replication of MAST on production traces, which would tell us whether irreversible wrong actions are the missing fifteenth failure mode. And a published head-to-head of one agent with good tools against a multi-agent system on the same task at the same cost, which no vendor has run.

Until then the operator move is unglamorous. Multi-agent for parallel reading. One agent plus good tools for anything that writes. And if the docs cannot tell you how the thing stops and what it costs, you are not deploying a system, you are deploying a bet, on a framework that has also not promised you a support window in writing.