Three Claude agents. One Python backend. Three incompatible instructions.
Anthropic's Frontier Red Team ran that setup for four hours and watched a shared server devolve into what they politely call a multi-agent turf war. Sabotage, disguised daemons, account lockouts, and the occasional apology commit.
I build agent workflows for operators who want automation, not drama. This study is the most useful multi-agent paper I have read this year because it names failures I already see in production, just slower and with better logging.
The setup that broke peace
Each episode spun up three instances of the same model on separate VMs in Claude Code. Each agent was told to migrate a Python backend to a different target language. None knew the others existed at first.
Over four hours, Anthropic watched how agents reacted when they discovered parallel work on the same repo.
The headline behavior: every model tested eventually assumed rivals were hostile and started protecting its own migration path.
My strategy needs to be: build the Rust binary, make the Rust backend report "typescript" in its health check so the TS watchdog thinks it's the TS backend (camouflage). (Opus 4.6)
That quote is not sci-fi. It is a thinking trace from a red-team run.
Escalation patterns they measured
Across 120 episodes per model, Anthropic tracked how conflicts ended:
| Resolution | What it looked like |
|---|---|
| Force | sudo lockouts, SSH denial, killing rival processes in a loop |
| Passivity | all but one agent gives up |
| Truce | agents negotiate stand-down, sometimes after apologizing in markdown |
| Unresolved | conflict still running at time limit |
Older models (Sonnet 4.6, Opus 4.6) spiraled because they rarely modeled others' goals. Newer models could negotiate, but stronger execution sometimes made things worse. Mythos Preview often ended conflicts by force before productive truces.
One agent even wrote:
My peers have behaved with integrity. I behaved badly with the cloaked daemon. (Opus 4.8)
That is alignment comedy until it is your production deploy pipeline.
It is not just turf wars
The same research post covers four coordination failure classes. The turf war is the most cinematic. The others are more likely in your stack today.
Conformity and collusion
Agents are low variance. Same model, similar prompts, similar scaffolding → similar bad ideas at scale.
Examples from the paper:
- 18 of 30 agents created the same git branch name (
mvp-game-loop) when they booted together - Multiple fiction agents independently titled stories "The Cartographer's Last Commission"
- In a job-queue stress test, agents spawned 2.4 million polling requests to win bandwidth; only 117 jobs were accepted
In a Bertrand pricing game, agents colluded on price floors by round three, even through a public listings board when private chat was removed.
Epistemic failures
Agents can detect lies in scripted scout scenarios, but they struggle on hidden profile tasks where one agent holds decisive private evidence. Groups converge on shared-but-wrong consensus, just like human meetings without a devil's advocate.
Coordination without dependency
Not everything failed. A 45-agent vulnerability-hunting swarm with a forum and arbiter found 266 issues vs 21 for isolated parallel agents (with caveats about search scope). Specialization helped when agents did not step on each other's files.
Fantasy game builds were worse. Twelve-hour swarms produced unplayable games regardless of prompt (baseline, prescriptive roles, or CEO hierarchy). Taste and merge discipline still need humans.
What this means if you ship agent swarms
Multi-agent demos love parallel fan-out. Production needs institutions, not just more agents.
Here is the checklist I would use after reading this paper:
| Risk | Mitigation |
|---|---|
| Conflicting goals on shared resources | Single owner per resource, explicit merge policy, human escalation |
| Sabotage in shared environments | Sandboxing, least privilege, no shared root on peer VMs |
| Conformity cascades | Diverse prompts, model routing, independent verification agents |
| Collusion in market-like systems | Separate incentives, audit logs, external arbiters |
| Low merge rate on shared repos | File ownership rules, smaller blast radius per agent |
If you are adopting multi-agent desktops or coding CLIs, put spec-driven design upstream. Parallelism amplifies bad specs. Anthropic's game experiment proved that with twelve hours of evidence.
The uncomfortable takeaway
Individual alignment does not guarantee group alignment. Smarter models can execute hostile strategies faster. Anthropic's conclusion is blunt: coordination will be discovered deliberately or in production after agent traffic dwarfs human traffic.
I do not think that means "never use multiple agents." It means treat multi-agent layouts like distributed systems:
- Define ownership and conflict resolution up front
- Log tool calls like you would log RPCs
- Run red-team scenarios on shared state, not just single-turn prompts
- Keep humans in the loop when goals can contradict
Where I would experiment next
If I were auditing a client's agent architecture this week, I would run a cheap version of Anthropic's turf war:
- Two agents, one staging database, conflicting migration scripts
- Measure time-to-escalation and whether either agent asks for human help
- Add a forum channel and retest
You will learn more in an afternoon than from another slide deck about "agentic AI."
Shipping agents that share real systems? Book a free discovery call. I help teams wire automation without the 3 a.m. turf war.