Multi-Agent Development Systems

Anthropic’s research system runs a lead agent that fans out to subagents, and on their own internal eval it beats a single agent by a wide margin. It also spends roughly fifteen times the tokens of a chat. Both numbers are the lesson: multi-agent is not free speed, it is a trade.

Everything you have built so far took one agent, one session, one terminal. That is still the right shape for most work, and the fastest way to waste a weekend is to summon a fleet of agents for a job one of them could finish. This module is about the exceptions: what they look like, what they cost, and how to run one tonight.

Start by assuming you do not need this

Anthropic’s January 2026 guidance on multi-agent systems puts the order of operations first: exhaust what a single agent can do before you add a second one. A sharper prompt, a /clear, a plan you actually read — those cost nothing. A second agent typically costs three to ten times the tokens of one agent doing the same task.

The sharpest counter-argument is Walden Yan’s Don’t Build Multi-Agents at Cognition, June 2025. Two principles: agents must share context — the full trace, not a tidy summary — and every action an agent takes carries a decision it never announces. His example is two subagents building one game, a Mario-style background and a bird that does not match it, leaving the lead to merge incompatible assumptions. One correction before you repeat that post: its claim that Claude Code subagents cannot write code in parallel was true in mid-2025 and is not true now. The principle survives; the product description does not.

Three reasons to split, and one bad way to split

The January 2026 post names three cases where a second agent earns its keep. Context protection: the side work would flood your main window, so it happens in someone else’s. Parallelisation: the facets are genuinely independent. Specialisation: a narrow tool set, prompt or domain beats a generalist. It also names the split that fails, and this is where most people go wrong.

Run the same job three ways and watch what changes

Same job — review a forty-file pull request — in three shapes. Run all three and read the verdicts, not just the numbers.

Five shapes, and the one Anthropic actually shipped

The vocabulary comes from Building effective agents by Erik Schluntz and Barry Zhang, December 2024. Five patterns — you have already used three of them without naming them — and one piece of default advice that has aged well: start with the simplest thing, and add complexity only when it measurably improves the result.

The worked example is Anthropic’s multi-agent research system, June 2025: a lead Opus 4 agent plans the search and spawns Sonnet 4 subagents that run in parallel, each searching in its own clean context window and returning a condensed summary to the lead. It outperformed single-agent Opus 4 by 90.2% on their internal research eval.

Now the honest half of the same post. Token usage alone explained about 80% of the performance variance on a browsing benchmark — the architecture works largely because it spends more tokens, in more windows, at once. The post also says tasks that need shared context or carry many dependencies are a poor fit, and that most coding work has fewer genuinely parallel parts than research does.

What this looks like in Claude Code tonight

The docs put every parallel option on one page. Here is the ladder, in rising order of how much rope you hand over:

• Subagents. Workers inside one session, each with its own context window, tools and model. Define one at .claude/agents/<name>.md; set model: haiku for cheap work and isolation: worktree when it will edit files. They nest up to three layers below the main conversation, and spawning fails once twenty are running at once.
• Worktrees. A second working directory of the same repo on its own branch, so two sessions can never touch the same file. This is not a way to go parallel; it is the layer that keeps the others from colliding.
• Background and cloud sessions. claude agents — a research preview — gives one screen to dispatch and monitor background sessions, each moving into its own worktree before editing. claude --cloud runs the task in an Anthropic-managed VM that clones your branch, so push first; claude --teleport brings the work back to your machine.
• Agent teams. A lead plus teammates with a shared task list and a mailbox. Experimental and off by default. Three to five teammates, five or six tasks each, one owner per file — teammates are not worktree-isolated, so partitioning the files is your job.
• Dynamic workflows. Claude writes a script that a runtime executes in the background, and only the final answer returns to your context. Sixteen concurrent agents by default, a thousand per run, with a warning once a plan passes about twenty-five.

# one isolated checkout per parallel task
claude --worktree signup-form
# -> .claude/worktrees/signup-form/ on branch worktree-signup-form

git worktree list          # every parallel checkout you have open

# a worktree is a fresh checkout: install deps again, and list the
# gitignored files (.env and friends) you need copied into each one
echo ".claude/worktrees/" >> .gitignore
echo ".env" >> .worktreeinclude

# push first, then hand a long job to a cloud session
claude --cloud "Execute the migration plan in docs/migration-plan.md"

One more before Lab 07: /batch <instruction> splits a single large change across five to thirty worktree-isolated subagents, each opening its own pull request. It is the fastest legitimate fan-out in the tool, and the fastest way to produce thirty PRs nobody has read.

The hard part is the split itself. This prompt forces it into the open before anything spawns.

Job: [one sentence].

Before you spawn anything, propose a split and show it to me. For each task:
  OBJECTIVE  one sentence: what is true when it is done
  FILES      the exact files it owns. No file may appear in two tasks.
  CHECK      the command that proves it worked, and its expected result
  BOUNDARY   what it must not touch, and what it should hand back to me
             instead of deciding on its own

Merge any two tasks that share a file or share a design decision.
If fewer than two tasks survive that rule, say so and just do the work
yourself in this session — do not spawn anything.

Then run the surviving tasks as worktree-isolated subagents, one per task,
on Sonnet. Each returns at most 15 lines: what changed, the check it ran,
and the output of that check. No narrative.

When they are all back, start a fresh subagent that wrote none of this code.
Its only job is to re-run every check and report what actually fails.

Where the money goes, and how to watch it go there

Parallel work multiplies token usage; that is the mechanism, not a side effect. The Claude Code cost docs describe an agent team as using “approximately 7x more tokens than standard sessions when teammates run in plan mode” — carry the condition with the number, because the multiplier is not a fixed property of teams.

1. Route models by role. Expensive model plans and synthesises, cheap model does the parallel legwork — the Opus-lead, Sonnet-workers shape from the research system. Set model: haiku on simple subagents; name the model when you spawn teammates.
2. Cap anything that loops. An iteration cap in the prompt, --max-budget-usd on scripted runs. Unbounded loops on an API key are where surprise bills come from.
3. Read /usage. It shows plan bars plus an attribution breakdown: skills, subagents, plugins, MCP servers, loops. /insights writes an HTML report on how you work; /context shows what is filling the current window.
4. Know what normal is. That same cost page puts enterprise use at roughly $13 per developer per active day, and under $30 per active day for 90% of users. If one afternoon of fan-out dwarfs that, it should have bought something you can name.

For a team that wants real observability rather than a slash command, Claude Code exports OpenTelemetry: CLAUDE_CODE_ENABLE_TELEMETRY=1 plus an OTEL_EXPORTER_OTLP_ENDPOINT gives you claude_code.token.usage, claude_code.cost.usage and claude_code.code_edit_tool.decision — that last one, how often edits are accepted, is the number nobody looks at.

The rule: independent, and independently verifiable

The largest published example of this working is Nicholas Carlini’s C compiler built by parallel Claudes, February 2026: sixteen Opus 4.6 instances, each in its own Docker container with its own clone, each in an endless loop, claiming tasks through lock files. Roughly two thousand sessions over two weeks, just under $20,000, about 100,000 lines of Rust that compiles Linux 6.9 on three architectures.

Two lessons scale down to your laptop. The agent optimises for exactly the problem the tests define, so weak tests produce a confidently wrong product — and sixteen agents produce sixteen times as much of it. And parallelism collapsed whenever every agent hit the same giant task; the fix was splitting that task against an external oracle, not adding agents.

Which gives you the rule that survives every system on this page. Parallelise only work that is independent and independently verifiable. Independent: separate files, no shared design decision. Independently verifiable: each slice carries its own check — a test, a build, a script — that passes or fails without a human reading the diff. Work that fails either half belongs in one session, in order.

Now go break something on purpose. Lab 07: Two Agents, Two Worktrees, One Merge runs two agents on two branches at the same time, reviews one branch with a subagent that did not write it, and merges both — including the conflict, which is the part that teaches.