Swarm topologies: the shapes of many-agent work
Part 6 is the book's center of gravity: many agents, one goal, bounded budget. Before any scheduler code, this chapter answers the two questions that decide whether a swarm should exist at all (what does a second agent actually buy, and what does it cost) and then catalogs the five shapes multi-agent systems keep converging on, with their failure modes attached. None of this is AWS-specific; it is the design layer above everything the rest of the part builds.
What a second agent buys
The honest list is short, and the first item is not the one people expect:
- Fresh context windows. The deepest reason multi-agent systems work. One agent reading sixty files accumulates a polluted, truncated context; sixty agents reading one file each bring full attention to every file, and return summaries upward. A swarm is, structurally, a way to spend more total context than any single window holds, with compression at the boundaries. The concepts chapter's context window is the binding constraint being escaped.
- Wall-clock parallelism. Sixty sequential file reviews take a night; sixty parallel ones take the length of the slowest, quota permitting (Chapter 14 already installed that caveat).
- Independence for verification. Judgments checked by the same context that produced them inherit its blind spots. Verifiers with separate contexts and adversarial instructions are structurally able to disagree, which Chapter 26 turns into measured precision.
- Role specialization. A prompt tuned to one job beats a prompt negotiating five. Cheap to state, real in evals, and it composes with the model portfolio: roles get models and prompts sized to the job.
And the cost, stated as bluntly as vendors will not: token multiplication. Every subagent re-carries instructions and context; coordination itself costs turns. Anthropic's published multi-agent research numbers are a useful calibration: agent sessions run several times chat token spend, and multi-agent systems several times that again, order of fifteen times chat. A swarm must earn that multiple through the four items above, and the gallery's anti-use-cases were mostly cases that cannot.
Don't be confused: multi-agent vs parallel tool calls. The loop already executes several tools per turn; that is one judgment fanning out its hands. Multi-agent means several judgments, each with its own context, model calls, and failure modes. Parallel tools are nearly free; parallel agents are nearly fifteen-fold. Exhaust the first before buying the second.
The five shapes
Orchestrator and workers. One agent (or, often better, plain code) decomposes the goal into units; a fleet executes them independently; results merge. The workhorse shape: it is how research assistants fan out searches, how coding fleets audit repositories, and how Capstones A, C, and D are built. Its token shape is the friendliest (workers share nothing but the task spec), its failure mode is decomposition quality: units that overlap waste tokens, units that interlock create hidden sequential dependencies, and the orchestrator's split is the single highest-leverage prompt in the system.
orchestrator
/ | \
worker worker worker (no cross-talk)
\ | /
merger
Pipeline. Stages, each a different role: extract, then judge, then repair, then format. The document-intake system is this shape. Buys specialization and per-stage models; fails at the seams, where one stage's output schema is the next stage's input contract, so schema discipline does the load-bearing.
Debate and judge panels. Several agents attempt or critique the same item; a judge (or majority) decides. This is the only shape that spends redundancy on purpose, and it is bought exactly where being wrong is expensive: verification meshes, high-stakes extraction, design-option generation. Chapter 26 prices it.
Blackboard. Agents share a workspace (a table, a directory) and react to each other's postings rather than to a coordinator. Flexible, organic, and the hardest to budget or audit; this book uses blackboard mechanics narrowly (shared dedup indexes, claimed-shard registries) and avoids it as a primary control structure. When you cannot say who will act next, you cannot say what it will cost.
Hierarchical delegation. Workers that spawn sub-workers, recursively. The natural shape for problems that decompose unpredictably (a repo audit that discovers a vendored subproject), and the natural way to lose control of a budget. The platform answer: any agent may request delegation; the scheduler admits sub-units against the same run ledger, so recursion spends the parent's budget, never fresh money.
The framework vocabulary maps straight on: Strands ships agents-as-tools (hierarchy), swarm (handoff-style delegation), graph (pipeline generalized to a DAG), and workflow primitives; LangGraph expresses the same shapes as explicit graphs. Frameworks change the spelling, not the physics.
Choosing
The selection rule the capstones apply, in order: (1) If units are independent after decomposition, orchestrator-workers, always; it is the cheapest and most auditable. (2) If roles differ more than units do, pipeline. (3) Buy debate only per high-stakes item, never corpus-wide. (4) Blackboard for coordination data, not control. (5) Hierarchy when decomposition is genuinely dynamic, under the parent ledger. And a standing veto from the gallery: if the flowchart is drawable in advance, it is a workflow, and no topology is needed at all.
One more property cuts across all five and decides more designs than any diagram: where does state live? In every shape this book builds, the answer is the same: in the run's event ledger, owned by the platform, with agents stateless between units. Topologies describe who talks to whom; the ledger is why any of it survives a crash, which is the next chapter's machinery.
👉 Next: the swarm scheduler, where every topology reduces to the same four pieces of plain code, and the simulator that anchors the rest of the part produces its first real numbers.