Multi-agent systems in practice

One agent with a clean brief is powerful. Several agents — decomposing a problem, working isolated tracks in parallel, checking each other's work — are how large tasks compress from days to hours. Multi-agent is also where cost and failure modes multiply fastest, so this lesson teaches the patterns and the discipline: when to reach for a team, how to shape it, and when a single agent remains the honest answer.

Why isolation is the whole trick

The naive reading of multi-agent is "more workers, more speed". The deeper mechanism is the context lesson's isolation principle at scale: each agent gets its own context window containing only its brief and its work. The parent orchestrator never wades through three transcripts — it reads three reports. The verifier never sees the writer's reasoning — so it checks the artifact, not the narrative. Attention stays sharp precisely because nobody holds the whole thing in one window; the system's memory is the sum of clean parts, not one bloated whole.

The two shapes that cover most real work

Orchestrator–workers is the workhorse for parallelisable tasks. A lead agent decomposes the goal into genuinely independent tracks — module A's refactor, module B's, the test-suite sweep — and dispatches each to a worker with a complete, self-contained brief: the task, the constraints, the definition of done, and where to report. In Claude Code this is subagents plus git worktrees (each worker on its own branch and directory); via the Agent SDK it is subagent definitions; on the raw API it is the orchestrator-workers pattern from the workflow lesson, grown up. The two rules that make it work: decompose along real seams — tracks that touch the same files aren't parallel, they're a merge conflict scheduled for later — and brief completely the first time, because a worker that needs mid-task clarification has already spent the tokens you meant to save.

Writer–verifier is the quality shape. One agent implements; a second, with a fresh context, checks — runs the tests, audits the claims against the diff, hunts what the writer missed. Fresh eyes are the point: self-review inherits the writer's assumptions, while a verifier reading only the artifact does not. This is the evaluator-optimizer workflow upgraded with isolation, and it composes with everything — every worker in a fan-out can have its output verified before the merge.

The economics, honestly

A multi-agent run can spend many times a single agent's tokens: every worker re-establishes context, and every report gets re-read by the orchestrator. Prompt caching blunts the fixed costs (shared system prompt and tools cached across all sessions), but the real economics are structural — the parallel speedup pays when tracks are large and independent; it never pays for work one agent could finish in a handful of tool calls, where coordination overhead exceeds the task. So: match tier to role (a frontier model orchestrating, cheaper models on well-specified worker tracks — the router pattern, organisation-sized); cap the team size deliberately; and default to one agent until the task demonstrably fans out. "Could this be one agent with better context management?" is the question that saves the most money in this entire course.

Failure modes to design against

Multi-agent failures are coordination failures, and they have names. Duplicated work — two workers solving the same sub-problem — comes from decomposition along fuzzy seams. Conflicting edits come from tracks that shared files; worktrees make the conflict visible at merge instead of silent at write. Report drift — a worker claiming done for work that isn't — is why verifiers exist and why the evidence rule from the automation lesson applies to every report: claims carry their proof or they are not claims. Runaway spend is bounded the boring way: per-agent budgets, capped team sizes, and an orchestrator instructed to stop and report when tracks stall rather than spawning reinforcements. The merge point is where everything reconciles, so give it real engineering: a verifier pass over the combined result, or a human review of the assembled whole — assembled work has seams, and seams are where bugs live.

What to take into the next lesson

Isolation is the mechanism; orchestrator–workers and writer–verifier are the shapes; complete briefs and real seams make decomposition work; economics and failure modes decide when one agent was the right answer all along. What keeps any of this trustworthy — single agent or team — is measurement, and that discipline is next.