Chapter 2. Orchestration Patterns: A Catalog of Swarm Architectures

An orchestration pattern is not a source of extra intelligence; it is a mechanism for spending tokens in parallel and partitioning context to fit the structure of a specific task. In Anthropic's BrowseComp analysis, token spend alone explains 80% of the variance in quality (Anthropic, 2025), so the main question when choosing an architecture is not "which topology is smarter" but "does the task decompose, and does it read or write." Below is a catalog of patterns with honest applicability boundaries — including the ones that did not survive the replications of 2025–2026.

The Complexity Ladder: The Zero-Pattern Rule

Before picking a swarm topology, check whether you need a swarm at all. Anthropic's canonical principle from Building Effective Agents (December 2024): "add complexity only when it demonstrably improves the outcome." The same post gives the base taxonomy of five workflow patterns the entire industry still cites: prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer. The Azure Architecture Center (updated 2026-02) frames it as an escalation ladder — direct model call → single agent with tools → multi-agent system — with "use the lowest level of complexity that reliably meets the requirements."

The economics reinforce the caution: a single agent burns ~4× the tokens of a chat, and a multi-agent system ~15× (Anthropic). A swarm pays off only where the value of the task covers that multiplier.

Orchestrator-Worker: The Pattern With the Best Production Evidence

Anthropic's Research feature is the reference implementation: a lead agent (Opus 4) plans, decomposes the query, and spins up 3–5+ parallel subagents (Sonnet 4), each in its own context window; a dedicated CitationAgent places citations at the end. The result: +90.2% over single-agent Opus 4 on an internal research eval, and two levels of parallelism (subagents plus parallel tool calls inside each) cut research time by up to 90% on complex queries (Anthropic, 2025-06-13).

flowchart TD
    U[User query] --> L[Lead agent plans and decomposes]
    L --> S1[Subagent 1 own context]
    L --> S2[Subagent 2 own context]
    L --> S3[Subagent N own context]
    S1 --> R[Synthesis by a single agent]
    S2 --> R
    S3 --> R
    R --> C[CitationAgent adds citations]

Anthropic states the applicability criteria explicitly: wide parallelization, information volume beyond a single context window, many complex tools. The explicitly bad fit: coding and tasks with tight interdependencies. A key practice: effort-scaling rules are baked directly into the orchestrator's prompt — simple fact-check: 1 agent and 3–10 tool calls; comparison: 2–4 subagents at 10–15 calls each; complex research: 10+ subagents with clearly divided zones. Without such rules, early versions "spawned 50 subagents for simple queries."

Two honest caveats. First, the 90.2% comes from an internal, non-public eval with no described methodology. Second, the comparison is not compute-matched: compute-controlled studies from 2026 (Tran & Kiela) show that at an equal budget of "thinking" tokens, single agents catch up with or overtake multi-agent systems on multi-hop reasoning. Both claims are compatible: a swarm is a way to spend more tokens in parallel and route around the limit of a single context window, not an intelligence multiplier.

The Catalog: Nine Patterns and Their Boundaries

A separate mention goes to stigmergy (coordination through a shared artifact instead of messages): CodeCRDT showed 100% convergence and zero merge conflicts across 600 runs of parallel coding through a CRDT document, but with a spread from a +21.1% speedup to a −39.4% slowdown depending on the task. Task structure, once again, decides everything.

The Tenth Pattern: The Outer Loop (Ralph-loop)

Beyond the catalog lies a pattern where the orchestrator is not an agent but a plain while loop: one task per iteration, fresh context on every pass, a plan file as shared state. The folklore origin is Geoffrey Huntley's "Ralph Wiggum" loop (ghuntley.com/ralph, July 2025): by his own reports, a $50,000 contract was delivered as an MVP ("delivered, tested + reviewed") for $297 in API costs (Amp, 2025-07-11), and at a YC hackathon an overnight while loop produced 1,100+ commits across 6 repositories — including a nearly complete port of Browser Use from Python to TypeScript — for less than $800 for the entire overnight run. Both facts are self-reported (a screenshot of a conversation and a hackathon anecdote) with no independent audit — cite them as evidence that the pattern exists, not as a benchmark.

By 2026 the pattern has been vendorized. Claude Managed Agents / Dynamic Workflows (announced 2026-05-19, released with Opus 4.8 on 2026-05-28): a lead agent writes a JS script and deploys anywhere from dozens or hundreds up to ~1,000 parallel subagents in a single session (docs), while the Outcomes grader scores each subagent's output against a rubric in a separate context window and sends it back for revision — a claimed task-success lift of up to +10 points (+8.4% docx / +10.1% pptx) (Anthropic). The caveat stands: these are the vendor's numbers about its own product. And the outer loop's main applicability boundary is procedural, not topological: without explicit terminal states and the rule that "an error is not a success" (covered in detail in the chapter on failure modes), the loop turns into a generator of plausible garbage commits.

What Didn't Survive Scrutiny: Debate, Judge Panels, Auto-Topologies

Debate. The original work by Du et al., 2023 showed hallucination reduction through multi-round debate, but the 2025–2026 replications are mostly negative: Zhang et al. (5 methods × 9 benchmarks × 4 models) — MAD "often fails to outperform simple single-agent baselines like CoT and Self-Consistency even at substantially higher inference compute." Debate or Vote (NeurIPS 2025 Spotlight) proves that debate is a martingale: by itself it does not change expected correctness, and most of the gain attributed to it comes from plain majority voting. The only durable lever is model heterogeneity: diversity, not conversation, is the active ingredient.

Judge panels. PoLL (2024) showed that a panel of small judges from 3 model families beats a single GPT-4 judge at 7x+ lower cost. The 2026 correction: Nine Judges, Two Effective Votes — across 9 frontier judges, correlated errors eat up ~75% of the nominal independence, the panel carries the information of only ~2 independent votes, and the best single judge is no worse than the entire panel. The takeaway: scale the diversity of error profiles (families, prompts, rubrics), not the number of judges.

Automated topology search. AFlow, ADAS, GPTSwarm, and DyLAN reported double-digit gains, but the MASS ablations (arXiv, Feb. 2025) showed that optimizing block prompts yields ≈+6%, adding topology optimization only ≈+3%, and "advantageous topologies make up only a small fraction of the full design space." Harsher still — The Illusion of Multi-Agent Advantage (June 2026): auto-generated MAS "consistently underperform CoT-SC while being up to 10× more expensive," with a diagnosis of "architectural bloat" — search spaces reward inflation because benchmarks do not price tokens. Both results are preprints, but the trend points one way: prompts matter more than topology.

The Harness Matters More Than the Model: Harness Engineering

If prompts matter more than topology, the next step in honesty is admitting that the harness — the tools, the context, the verification loops — often matters more than the model itself. LangChain's fixed-model experiment (gpt-5.2-codex) showed this in its purest form: harness changes alone lifted deepagents-cli from 52.8% to 66.5% on Terminal-Bench 2.0 — +13.7 points without a single new weight (LangChain, 2026-02-17). Among the findings is the "reasoning sandwich": maximum reasoning at planning and verification, economy in the middle (the xhigh-high-xhigh profile yields 63.6% against 53.9% for constant xhigh). The series' sequel flips the price logic as well: Nemotron 3 Ultra with a harness tuned to it scores 0.86 against Opus 4.8's 0.87 on the Deep Agents eval at ~10× lower cost per run ($4.48 versus $43.48), starting from a baseline of ~0.80 without the profile; the authors' principle — "evals are the training data of harness engineering" (LangChain, 2026-07-08).

The production-scale version of the same idea is Azure SRE Agent: 35,000+ incidents mitigated autonomously by 1,300+ agents, Azure App Service time-to-mitigation cut from 40.5 hours to 3 minutes, savings estimated at 20,000+ engineer-hours per month (Microsoft's numbers about its own product; Microsoft, 2026-03). Their most transferable lesson is context engineering: replacing 100+ narrow tools with file access (read_file/grep/find/shell) raised the Intent Met metric from 45% to 75% on new incidents. Anthropic pushed the same "fewer tools, more code" principle to its limit: when an agent writes code that calls MCP servers instead of making direct tool calls, the task context shrinks from 150,000 to 2,000 tokens — a 98.7% saving (the Google Drive + Salesforce example; tool definitions are loaded from the file system on demand) (Anthropic, 2025-11-04).

Harness engineering is already being automated: RHO (Retrospective Harness Optimization) is a self-supervised method in which a single round of harness optimization from unlabeled past trajectories raised the SWE-Bench Pro pass rate from 59% to 78% with no external labeling, validated across three domains — software engineering, technical, and knowledge work (Pan et al., arXiv:2606.05922, 2026-06-04). For choosing an orchestration pattern this sets the order of operations: before adding agents — and even before switching models — squeeze the harness: the verification loop, the file-based context, the reasoning profile.

The Read/Write Rule and Why Swarms Fail

The public clash of June 2025 framed the entire debate: Cognition published Don't Build Multi-Agents (June 12) — "actions carry implicit decisions, and conflicting decisions produce bad results"; Anthropic followed the next day with the post about its multi-agent research. The reconciliation was formulated by LangChain: systems that mostly "read" are easier to build than those that "write." Research parallelizes; synthesis, writing, and coding should stay single-threaded. By 2026, Cognition itself had softened its position to "multi-agent works when writes are single-threaded and the extra agents add intelligence, not actions."

The failure data confirms that the bottleneck is orchestration, not the models. The MAST taxonomy (NeurIPS 2025, 1,600+ annotated traces, 7 frameworks, κ=0.88) identifies 14 failure modes in three clusters: specification and system design errors — 44.2%, inter-agent misalignment — 32.3%, verification failures — 23.5% (v3; the earlier v2: 41.8 / 36.9 / 21.3); the end-to-end failure rate of SOTA open-source frameworks runs 41–86.7%. Most swarm failures are orchestration specification bugs and missing result verification, which is why maker-checker loops and explicit output-format contracts pay off faster than adding agents.

The New-Information Criterion: When a Second Agent Is Justified

The read/write rule is complemented by a framework from Bojie Li's book ai-agent-book (ch. 10, table 10-2): the "swarm versus single agent" criterion rests on a single question — does the collaboration introduce new information unavailable to a lone agent at generation time. "Different agents arguing over the same text" brings no new information, and at equal compute that is parity with a single agent; a reviewer with code execution, visual rendering, or an external check does bring new information, and the gain is substantial. This is an editorial framework from a secondary source, but it leans on verifiable primary works, and one of them is telling: WebGen-Agent (Lu et al., arXiv:2509.22644, 2025-09-26) added multi-level visual feedback — a screenshot plus a vision-language model's description — and lifted Claude-3.5-Sonnet's accuracy on the WebGen-Bench benchmark from 26.4% to 51.9% (appearance score from 3.0 to 3.9), while Step-GRPO training lifted Qwen2.5-Coder-7B-Instruct from 38.9% to 45.4%.

The second consequence for orchestration is role asymmetry. Plan-and-Act (Erdogan et al., arXiv:2503.09572, ICML 2025) shows that planning quality is the decisive lever in a Planner–Executor pair: the architecture reached a SOTA 57.58% on WebArena-Lite and a text-only SOTA 81.36% on WebVoyager, and even an untuned Base Executor gains +34.39 points with a quality plan — up to 44.24%. The practical takeaway for any orchestrator-worker setup: give the strongest model and the best prompt to the planner, not the executors.

What to Apply Tomorrow

1. Classify the task along the read/write axis: reads (research, data gathering) — parallelize via orchestrator-worker; writes (code, text synthesis) — keep single-threaded or wrap in a reflect+executor loop.
2. Climb the Azure ladder — direct call → single agent → swarm — and at each rung, confirm that the added complexity demonstrably improves your metric before going further.
3. Bake explicit effort-scaling rules into the orchestrator's prompt, Anthropic-style: 1 agent for simple facts, 2–4 for comparisons, 10+ only for genuinely complex research.
4. Before experimenting with topology, optimize the block prompts — per MASS, that yields twice the gain (+6% versus +3%).
5. Add verification as a separate loop: maker-checker with a hard iteration cap, a defined fallback, and no more than 3 agents in the cycle; check output contracts — they account for 23.5% of failures per MAST.