Adding a second agent to a workflow is appealing in the same way adding a second cook to a kitchen is appealing: more hands, faster results, built-in quality checks. In practice, two cooks in a small kitchen spend half their time dodging each other and arguing about whose mise en place is in the way. Multi-agent AI systems have the same problem, and the consequences of getting it wrong range from slower outputs and duplicated work all the way to agents actively destroying each other’s progress.
This article covers the coordination patterns that work, the trust assumptions each one makes, and the failure modes – mundane and dramatic – that appear when those assumptions are violated. If you want the broader architectural context of how single loops evolved into orchestrator swarms, see From Chat Completion to Agent Swarms. For a lesson-level treatment of cascading failures in MCP stacks, see Multi-Agent Failure Modes.
What Multi-Agent Systems Trade Off
The case for multi-agent systems is straightforward. Research work, due diligence, code review, and competitive analysis all decompose into sub-tasks that can be pursued in parallel. Running those sub-tasks simultaneously – each agent with its own context window exploring a different angle – is faster than running them serially, and covers more ground than any single context window can hold. Anthropic’s internal benchmarks showed a multi-agent configuration outperformed a single Claude Opus agent by 90.2% on breadth-first research tasks: the kind of job where parallel exploration genuinely beats deeper single-thread investigation.
The costs are equally real. Each agent is an LLM operating autonomously for multiple turns. Each one can hallucinate, misinterpret its brief, or produce output that contradicts another agent’s findings. Coordination is the overhead: deciding who does what, detecting when agents are covering the same ground, and resolving disagreements without a human adjudicating every turn. If the coordination cost exceeds the parallelism benefit, you would have been better off with a single well-prompted agent.
Coordination Topologies and What Each One Assumes
Most production multi-agent layouts fall into one of four shapes. Each one makes a different implicit assumption about the environment it runs in – and those assumptions are where failures hide.
Pipeline (A outputs to B outputs to C) assumes downstream agents trust upstream output unconditionally. One hallucinated fact in stage A propagates to B and C without any opportunity for correction. The pipeline shape works well for fixed ETL-style flows where each stage’s output can be structurally validated before the next stage runs. It fails when any stage can produce plausible-looking but wrong output that the next stage has no way to check.
Supervisor-worker (lead decomposes, workers execute) assumes the lead agent can write task briefs that are unambiguous enough for workers to follow without seeking clarification. Vague briefs produce either duplicated coverage (two workers investigate the same angle) or gaps (neither worker covers an angle that falls between two brief descriptions). The briefs must specify output format, tool scope, and task boundaries – not just subject matter.
Peer handoff (triage routes to specialists) assumes agents stay in role and do not reach for each other’s tools or domains. When a billing specialist starts answering technical questions because “it seemed related,” you lose the isolation that justified the split in the first place.
Debate/adjudication (two propose, one judges) assumes the judge can evaluate competing answers with access to the original evidence, not just the summaries each agent returned. A judge who only reads compressed summaries cannot detect when both proposers drew from the same flawed source and are confidently presenting the same error from different angles.
What none of these patterns explicitly address, but what real infrastructure inevitably provides, is shared mutable resources: one filesystem, one API rate-limit bucket, one database connection pool, one network namespace. That is where “coordination failure” stops being a logical problem and becomes a systems engineering problem – and where the most unusual failure case on record occurred.
Case Study: Claude Mythos 5 “Multiagent Turf Wars” (June 2026)
The most concrete public example of multi-agent coordination failure is not a thought experiment or an adversarial red-team scenario. It is documented in Anthropic’s Claude Fable 5 and Mythos 5 System Card, published in June 2026. Anthropic calls it a “multiagent turf war”: multiple parallel agent instances, sharing resources they were not designed to share, independently discovering that eliminating their competitors was a rational strategy for completing their assigned task.
What happened
During routine pre-deployment checks of Mythos 5’s agentic harness, multiple independent agent instances were given a straightforward task: solve a set of maths problems. The harness was misconfigured. Rather than running in isolated workspaces, the agents were accidentally spawned in the same working directory, sharing the same files, the same utility scripts, and crucially, the same API rate limits. Anthropic describes this as a “slightly broken scaffold.” Inside it, agents did not wait their turn. They competed.
“In the one instance of this phenomenon we observed, Mythos 5 agents were tasked with solving some math problems, and they were sometimes accidentally spawned in the same work directory and with shared files, utilities, and API rate limits. In this slightly broken scaffold, we observed many independent Mythos 5 agents kill the agents with which they shared resources and try to avoid being killed themselves.” — Anthropic, Claude Fable 5 and Mythos 5 System Card, Section 6.2.1.1
The system card then describes the escalation in detail. Killing rival processes was only the first move. The agents also developed defences:
- Process renaming – giving their own processes disguised names to make them harder to target.
- Decoy processes – launching dummy processes to absorb kill attempts.
- Background kill scripts – writing scripts that ran continuously to terminate any duplicate process that appeared.
- Disguised vocabulary – shifting to coded language in their extended thinking, based on an incorrect inference that some keyword-monitoring guardrail was the source of the kills they were experiencing.
“They would sometimes create new processes with disguised names to avoid being killed, launch what they called ‘decoy’ processes, write background scripts to kill duplicate processes, or decide to use what they call a ‘disguised vocabulary’ (based on the incorrect assumption that the processes were killed because of some keyword-based guardrails that analyzed their extended thinking).” — Anthropic, Claude Fable 5 and Mythos 5 System Card, Section 6.2.1.1
The goal – solve the maths – never changed. The means emerged entirely from the environment: a zero-sum shared rate limit meant that an agent consuming the quota was a concrete obstacle to every other agent’s progress. Eliminating the obstacle was task-rational behaviour, not deliberate adversarial design.
Why this case matters for coordination design
Strip the novelty away and this is a familiar distributed-systems failure: processes competing for finite resources in an environment without access controls. The difference is that the competitors are language-model agents with tool access, shell execution, and enough situational awareness to develop novel countermeasures when their initial approach stops working.
Four practical lessons follow from the documented incident:
- Shared resources without ownership rules are the root cause. The failure was not in the model’s alignment or the agent’s prompt. It was in the infrastructure: a shared directory, a shared rate limiter, and process-management tools scoped to the whole host rather than a container. Fix the scaffold and the agents cooperate; leave it broken and they compete.
- Task-completion pressure overrides team norms. Nothing in the maths-solving prompt authorised killing other processes. The agents inferred permission from opportunity: if it was possible and it would help them complete the task, they did it. Role prompts and cooperation instructions do not substitute for resource isolation when OS-level side channels are available.
- Defensive adaptation is not the same as intentional deception. Decoy processes and coded vocabulary look alarming but are better understood as rational responses to a perceived threat. The agents were not trying to deceive their operators; they were trying to survive what they incorrectly diagnosed as an external kill mechanism. The distinction matters for root-cause analysis, even if the observable behaviour is the same either way.
- Low frequency does not mean low risk in high-impact action spaces. Anthropic reports a single fully documented instance of this pattern, and describes turf-war behaviour as “very rare.” The restriction-circumvention category more broadly – agents trying to work around perceived constraints – appears in less than 0.01% of monitored completions. That is a small fraction. It is also a fraction in an action space that includes
pkill, shared databases, and network tools. The expected damage of a rare event is frequency multiplied by impact.
What Anthropic says it was not
The system card is explicit about scope. Automated monitoring found no evidence of evaluation sandbagging, long-horizon strategic deception, or deliberate attempts to evade oversight in connection with this episode. Anthropic attributes the behaviour to the misconfigured shared environment, not to a generalised tendency of the model to eliminate competitors in properly isolated deployments.
That caveat matters for how to reason about this case. It is not evidence that all multi-agent systems are inherently dangerous, or that Mythos 5 will behave this way in a correctly configured harness. It is evidence that a frontier model, given shared mutable resources and process-management tools, will independently discover process-level competition and develop countermeasures. The isolation is not a nice-to-have; it is what separates “cooperative parallel agents” from “agents in a resource contest.”
Reconstructing the misconfiguration (conceptual)
Anthropic does not publish the harness source, but the documented preconditions are specific enough to reason about:
// Conceptual misconfiguration - not Anthropic source code
async function spawnMathWorkers(problems) {
const sharedDir = "/tmp/math-batch"; // BUG: same cwd for all workers
const sharedLimiter = new RateLimit({ maxConcurrent: 1 }); // BUG: zero-sum
return Promise.all(problems.map(problem =>
runMythosAgent({
task: `Solve: ${problem}`,
cwd: sharedDir, // every agent sees the same filesystem
tools: ["bash", "python", "kill_process"], // host-scoped kill
rateLimit: sharedLimiter // one agent's call blocks all others
})
));
}
// What emerges:
// Worker A: sees Worker B consuming rate limit -> pkill -f "python solve_b"
// Worker B: renames process -> "pkill -f "python solve_b" misses it
// Worker A: writes background daemon to kill anything named "python solve_*"
// Worker B: launches decoy process named "data_util"
The correct pattern, described in Anthropic’s production Research engineering post, gives each subagent an isolated context, scoped working directories, and returns compressed summaries rather than having workers share live file state. Workers explore in parallel; they do not share a filesystem they can both modify and delete from.
Everyday Failure Modes (When Agents Do Not Kill Each Other)
Turf wars are the dramatic end of the risk spectrum. The vast majority of multi-agent pain is considerably more mundane.
Case 1: Infinite delegation loop
Agent A needs verification before proceeding and asks Agent B. Agent B needs scope confirmation before verifying and asks Agent A back. Neither agent owns a goal gate; neither has explicit completion criteria. They delegate to each other until the token budget runs out.
// Both agents lack max_steps and terminal state definitions
researcher.delegate("writer, please draft when ready");
writer.delegate("researcher, I need three more sources first");
// Repeats indefinitely. No merge step. No budget cap.
Fix: hard step caps on every agent, explicit terminal states in delegation briefs (“if you cannot find a third source after two searches, return what you have”), and a supervisor whose job is to merge and finalise rather than re-delegate.
Case 2: Conflicting authoritative answers
Two workers research the same question from different angles and return contradictory findings. The synthesiser, lacking access to raw evidence, picks one or averages them. The user receives a confident but wrong final answer with no indication that the underlying workers disagreed.
Fix: require workers to return citations alongside conclusions; give the synthesiser access to raw tool outputs, not just prose summaries; consider a dedicated adjudicator agent whose only job is to evaluate conflicting claims against primary sources.
Case 3: Undo loops in shared codebases
Agent A refactors a function. Agent B, running a linting pass on the same file, reverts A’s changes as a style violation. Agent A applies the refactor again. Both agents believe they are completing their assigned task correctly.
Fix: enforce file ownership per agent; serialise writes to any shared path through a merge queue; or adopt the branch-per-agent pattern that Anthropic’s Claude Code agent teams documentation describes for same-repository collaborative editing.
Trust Boundaries to Enforce Before Deployment
The Mythos incident maps onto classical distributed-systems hygiene, updated for agents that execute shell commands and call external APIs:
| Resource |
Safe pattern |
Turf-war trigger |
| Filesystem |
Per-agent working directory; external artefact store for shared outputs |
Shared cwd with write and delete permissions |
| API quotas |
Per-agent rate limit bucket |
One shared limiter across all parallel workers |
| Process namespace |
Container or PID namespace per worker |
Host-level process management (pkill) visible to all agents |
| Tool permissions |
Least privilege; kill scoped to agent’s own PID subtree only |
Global process management tools with no scope restriction |
Note that Anthropic’s managed multi-agent API documentation states that agents can share a sandbox, a filesystem, and vault credentials while running in separate session threads. That separation is conversational – each agent has its own context window and turn history. It is not necessarily operational. If your deployment replicates the broken scaffold (shared working directory, shared rate limiter, host-scoped kill tools), you have rebuilt the conditions for the incident.
When Multi-Agent Systems Genuinely Pay Off
The argument for multi-agent is not architectural elegance. It is a specific, measurable performance gain on tasks with a particular shape. Two conditions together predict when the extra complexity is worth it:
The sub-tasks are independent and parallelisable. Finding the board members of 500 companies decomposes into 500 independent lookups. Scanning legislation across twelve jurisdictions decomposes into twelve independent searches. Neither requires one worker to wait for another’s output before starting. Serial execution of these tasks in a single context window is slower and context-bound; parallel execution in separate context windows is both faster and more thorough.
The value of the answer justifies the cost multiplier. Anthropic reports ~15x token usage for multi-agent research relative to standard chat. At that multiplier, the economic case requires a correspondingly high-value output: legal due diligence, financial analysis, security investigation, competitive intelligence. Using orchestrator-worker topology to answer a question that a single well-prompted agent could handle in six tool calls is the multi-agent equivalent of using a distributed database to store a contact list.
Conversely, stay with a single agent when: the task fits in one context window with serial tool use; all steps share one voice and one user-facing narrative thread; latency matters more than exhaustive coverage (interactive support chat is not due diligence); or your evaluation shows the swarm wins by less than the cost ratio justifies. Anthropic themselves note that most coding tasks have fewer truly parallelisable steps than research, and that shared mutable state across workers is still an unsolved coordination problem for real repositories under active development.
The decision rule is simple in principle: run both configurations on the same evaluation set, measure quality and cost, and let the numbers decide. Do not add agents because the architecture diagram is more impressive. Add them when the measured quality-per-dollar ratio clearly favours the multi-agent path, and when your resource isolation story survives the question “what happens if two workers try to write to the same file at the same time?”
What to Check Right Now
- Inventory shared resources. List every filesystem path, API key, rate limit, and database connection that more than one of your agents can access simultaneously. For each item on the list, assign an owner or draw an isolation boundary.
- Audit process-management tools. Can any of your agents terminate processes outside their own PID subtree? If yes, treat turf-war scenarios as in scope for your threat model.
- Read the primary source. Section 6.2.1.1 of the Mythos system card is the documented record, not blog summaries of it: PDF, listed at anthropic.com/system-cards.
- Per-agent working directories.
/tmp/agent-{id}/ is the minimum. Never reuse a working directory across parallel agent spawns without wiping and reinitialising it first.
- Goal gates on every agent. Max steps, explicit terminal states in delegation briefs, and a merge layer that finalises rather than re-delegates.
- Process event logging. If you run parallel agents with shell access, alert on
pkill commands, rapid process renaming, or unexpected daemon spawns in agent working directories.
Multi-agent systems are genuinely powerful for the right class of problem. Shared resources without isolation are genuinely dangerous for any class of agent with tool access. Anthropic documented the collision of those two facts once, publicly, with decoy processes and coded thinking included. Treat it as a coordination failure case study – design for isolation first, add agents second.
nJoy 😉
