One Agent First
No question in agent engineering generates more heat than "one agent or a swarm?" — and no question dissolves faster once you line the camps up against each other's evidence. They agree on more than they admit.
The three camps
The prohibition camp. Cognition (the Devin team) published the field's most-cited contrarian piece, Don't Build Multi-Agents (Walden Yan). The argument is precise: actions carry implicit decisions. Parallel subagents that can't see each other's full traces make conflicting decisions, and an orchestrator merging their outputs can't reconcile decisions it never saw being made. Their prescriptions: share full agent traces, not summary messages; default to a single-threaded linear agent; for very long tasks, add a dedicated compression model — compaction, not parallelism, is the load-bearing memory mechanism. Geoffrey Huntley's "Ralph loop" doctrine lands in the same place from indie practice: a monolithic single process, one repository, one task per loop iteration — "consider what microservices would look like if the services themselves were non-deterministic: a red hot mess."
The empirical caution. The MAST study annotated 1,600+ traces across 7 state-of-the-art open-source multi-agent frameworks and found 41–86.7% failure rates, with often minimal gains over single-agent baselines. Roughly a third of failures were inter-agent misalignment — information withholding, derailment, one agent's reasoning contradicting another's action — a coordination tax that a single session never pays. Most failures traced to organizational design, not model capability; prompt-level fixes recovered only single-digit-to-modest gains.
The pro camp — with fine print. Anthropic reports multi-agent research systems showing substantial measured improvement over single-agent on complex research tasks: subagents each burn tens of thousands of tokens exploring and return condensed summaries. But read their fine print and the position is narrow: subagents are justified on exactly two grounds — parallelization and context isolation; Claude Code deliberately never runs subagents in parallel with the main agent's own work; and they call single-vs-multi an open empirical question. OpenAI's deployment guide is blunter still: maximize a single agent first; split only on observed failure; and apparent tool overload is about overlap, not count — implementations succeed with 15+ distinct tools and struggle with 10 confusable ones.
The reconciliation
Put the three bodies of evidence side by side and the boundary draws itself:
- Fan out for reads. Research, search, review, audit — subagents that only gather and condense. Their outputs merge cheaply because no output constrains another. This is exactly where Anthropic measured wins, and nothing in Cognition's argument touches it.
- Never fan out writes. Two agents editing one codebase in parallel are two streams of implicit design decisions with no shared trace. This is where MAST's misalignment failures live and what Cognition prohibits — and note that even Anthropic's own product follows the prohibition.
- Sequential handoffs with fresh context are not "multi-agent" in the dangerous sense. A builder/validator split (Part 3) runs one at a time; its purpose is context isolation, which every camp endorses.
There's a cost dimension too, which Part 6 takes up: fan-out multiplies token spend. When this series was researched, the fan-out phase (a hundred-odd read-only subagents) produced excellent coverage — and burned about 1.15M tokens into an API session cap before the final synthesis step could run. A single linear session finished the job from the artifacts on disk. Both halves of the lesson in one incident.
Keep the harness boring
The adjacent consensus, worth stating because it kills a lot of framework shopping: the agent itself is architecturally trivial. A useful coding agent is ~300 lines wrapping an LLM in a loop (Huntley); Anthropic's most-quoted line in this space is that the most successful production deployments use simple, composable patterns rather than complex frameworks. The leverage is in the loop design, the tools, and the verification gates — Parts 3 and 4 — not in orchestration machinery.
Applying it
- Default to one capable session running longer. Split only on an observed failure a split would actually fix (context overflow on a read-heavy phase; a genuine need for parallel, independent reads).
- If subagents run in parallel, they must be read-only; writes stay single-threaded, or at minimum strictly partitioned with a human at the merge.
- Estimate fan-out cost against a linear session before launching it.
- Use fresh-context sequential agents freely — that's isolation, not swarming.
XiaoSteve's doctrine line — "prefer one capable session running longer over a hard-to-manage swarm" — predates this research pass, but the evidence sharpened its edges: the builder/validator split stays; parallel review fan-outs are fine; parallel build fan-outs are not.
Next: what all of this costs, and why "always-on" must not mean "always running." Part 6 →