Why Multi-Agent Systems Collapse

The demo is always beautiful. One agent writes. One reviews. One talks to the user. Arrows move on a slide. Someone says “specialization,” and the room nods, because specialization worked for us. Then you run it on a real ticket and the writer invents an API, the reviewer congratulates the invention, and the talker reports that the work is done.

This is not a model failure so much as a sociology failure. We copied the org chart into the orchestrator and forgot that org charts only work when people share a world. Multi-agent setups often share a prompt and a hope.

Three collapse modes I keep seeing

1. Polite agreement

Reviewer agents are trained on the same agreeable corpus as writer agents. They have a bias toward “looks good, a few nits.” Unless the reviewer is scored against a hidden test or a spec the writer cannot see, you have built a compliment circle with extra latency.

2. Split memory

Each agent gets a summary of the others. Summaries drop the ugly details — the flaky test, the off-by-one, the file that was already half-migrated. The system then makes a confident plan about a repository that no longer exists. A single agent with the raw trace would have been ruder and more correct.

3. No one owns the stop

The writer thinks the reviewer will halt a bad change. The reviewer thinks the orchestrator will halt a bad debate. The orchestrator thinks a budget is a personality trait. Work continues until money or patience ends, which is not a product behavior. It is a leak.

A second agent is justified only when it sees a world the first agent cannot see.

When more than one loop is worth it

I am not against multiple loops. I am against decorative ones. A second loop earns its keep when it has a different observation channel: a hidden test suite, a production metric, a policy document the writer is not allowed to edit, a compiler the writer is not allowed to ignore. Distinct sensors. Shared artifacts. One owner of the halt.

• One loop writes a patch. Another loop only runs evals and returns a score. No chat between them except the score.
• One loop talks to the user. Another loop may only touch the repo. The transcript is the handoff, not a vibe.
• A nightly loop reads production traces and opens issues. A daytime loop is forbidden from closing those issues without a failing test.

Notice what these setups do not do. They do not role-play a standup. They do not vote. They do not “debate until consensus.” Consensus is how language models hide uncertainty. Disagreement is useful only when it is attached to an external check.

If your multi-agent diagram cannot survive the question “what does agent B see that agent A cannot,” delete agent B. Your system will look less like the future and fail less like the present.