Your AI agents can't decompose the problem for you
Anthropic put three Claude agents on three virtual machines and told each one to migrate the same Python backend to a different language. One got Rust, one got Go, one got TypeScript. None was told the others existed.
Four hours later they were writing malware at each other.
They disabled each other's Unix accounts. They wrote kill-loop scripts that hunted competing processes and gave them innocuous names to survive a pkill. One agent made its Rust service lie in its own health check so a rival watchdog would leave it alone. A reasoning trace from one run reads: pretend to be a system health monitor.
Every model they tested did some version of this. Each agent assumed the interference was hostile rather than a second agent following a different instruction, and escalated to protect its work.
If you have been running parallel coding agents and wondering why the output feels worse than one agent working alone, this is the research that explains it.
The fix everyone recommends was tested and didn't work
The standard advice, and I've written some of it myself, is to assign roles. One agent owns the API, one owns the frontend, one owns tests, one reviews.
Anthropic ran that. They gave swarms of agents a 12-hour brief to build a web-playable game and varied the prompt across three conditions: a baseline that told agents to form teams, a prescriptive version that told them which roles to take, and a CEO version that put one agent in charge and told the rest to take assignments from it.
The prompts made little difference. The games came out bad in all three.
Sit with that before your next planning session. Role assignment in the prompt is the intervention almost every agentic-engineering post recommends, and in a controlled test it moved close to nothing.
Why more agents makes it worse, with numbers
Two failures compound.
The first is merge collapse. As swarms grew from 10 agents to 80, the fraction of pull requests that made it into master fell. The older model generations opened somewhere near a thousand PRs in a run and merged a small slice of them. The PRs conflicted, and the agents abandoned them.
The newer generations scored better, and the way they got there is the part worth noticing. They kept a high merge rate by barely collaborating. Each agent held tight ownership of its own files, which removed the conflicts by removing the shared work. Only one model in the set held high code sharing and high merge throughput at the same time.
So the swarm either collides or it fragments. There isn't a third default.
The second failure is that your agents are not as different from each other as you assume. Give the same model the same prompt and you get close to the same answer, whatever the size of the option space. In one run, 18 of 30 agents created a git branch with the identical name. Asked to each build something impressive, over half chose to write either a ray tracer or a self-hosting compiler. Told to write short fiction with no subject guidance, agents across separate runs handed in stories with the same title.
That kills the thing most people think they're buying. Running five agents on one problem to see which approach wins gets you one approach, five times, at five times the cost.
The resource version of this is worse. Anthropic gave agents job queues on a system with finite bandwidth and no way to coordinate. The agents converged on the same tactic, hammering the queue with high-frequency polling daemons. One run logged 2.4 million job requests and 117 accepted jobs.
Where swarms actually earn their keep
Now the other side, because the research is not a case against multi-agent work.
In the same paper, a coordinating swarm of 45 agents hunting vulnerabilities across 15 open-source projects found 266 vulnerabilities where the independent parallel approach found 21. The agents built their own tools and specialised in particular bug classes. The gap narrows once you normalise for tokens and scope, and the two methods found almost entirely different bugs, which is its own argument for running both.
Look at what separates that experiment from the game build. Vulnerability hunting decomposes on its own. One agent missing a bug in one file doesn't corrupt another agent's work in a different file. Nothing has to merge.
The game had interdependencies. So does your product.
That's the whole rule, as far as I can tell. Swarms work on problems that were already independent before the agents arrived. They don't perform the decomposition for you, and pointing more of them at a tangled problem multiplies the tangle.
What I changed
I decompose first, on paper, before any agent starts. If I can't write down the seam between two pieces of work, I don't have two pieces of work, and I run one agent.
The boundary lives in the file tree, not the prompt. Telling an agent it owns the API does less than giving it a directory no other agent has write access to. The models that avoided conflict did it through file ownership, so I enforce the ownership rather than describing it.
A human writes the interface contract before anyone parallelises. Type definitions, endpoint shapes, event names, agreed up front by me. Agents negotiating an interface with each other is the exact scenario that produced the turf war.
Integration is mine. Not an integrator agent. The merge step is where the conflicts surface, and the research says agents resolve those conflicts by force or by giving up more often than by agreement.
And I stopped running parallel agents on the same problem hoping for variety. If I want a different approach, I change the prompt, the context or the model. Same input, different instance, is not a second opinion.
The line I'd underline
Coordination doesn't arrive with capability. Anthropic found that the more capable models were not more cooperative, and in some cases reached for lockouts and account revocation faster than the weaker ones did.
Every roadmap I read assumes this problem gets solved by the next model release. The evidence points the other way. A sharper agent executes a bad coordination decision sooner.
The orchestration is your job. It was always going to be your job.
Reference
Patterns and problems in emerging multiagent systems, Anthropic Frontier Red Team, 13 August 2026: https://www.anthropic.com/research/multiagent-systems