AAperture
Back/harness engineering

Multi-Agent Coordination Patterns

Updated 2026-04-13
4 min read
841 words

Multi-Agent Coordination Patterns

Source: Anthropic official blog, translated by 宝玉xp Core principle: Start with the simplest pattern that works, observe where it bottlenecks, then evolve.

Pattern 1: Generator-Verifier

Best for: Output quality is critical and you can write explicit evaluation criteria.

How it works:

  1. Generator produces a draft
  2. Verifier checks against defined standards
  3. If failed, feedback is sent back to generator
  4. Loop until verifier approves or max iterations reached

Use cases: Code generation (one writes, one runs tests), fact-checking, compliance review, customer support email drafts.

Limitations:

  • Quality floor depends entirely on how detailed the verifier's rubric is
  • Assumes generation and verification are separable skills (not true for creative breakthroughs)
  • Can get stuck in infinite loops if generator cannot resolve verifier's objection

Pattern 2: Orchestrator-Subagent

Best for: Tasks decompose cleanly with clear subtask boundaries.

How it works:

  • A central orchestrator plans work, delegates to subagents, and synthesizes final results
  • Each subagent works in its own context window, returning distilled results

Real example: Claude Code uses this pattern. The main agent writes code and edits files, but spawns background subagents for large-scale searches or independent investigations.

Use cases: Automated code review (security, coverage, style, architecture checks), complex analysis with distinct dimensions.

Limitations:

  • Orchestrator becomes an information bottleneck
  • Subagents run sequentially by default unless explicit parallelism is added
  • Key details can be lost through repeated summarization

Pattern 3: Agent Teams

Best for: Parallelizable, independent subtasks that need long-running, multi-step execution.

How it works:

  • A coordinator spawns teammates as independent processes
  • Teammates pull tasks from a shared queue, complete multi-step work, and report back
  • Key difference from Orchestrator-Subagent: teammates persist across tasks and accumulate domain context

Use cases: Large codebase migration (each member owns one service module), long-running data pipelines.

Limitations:

  • Independence is both a strength and weakness — teammates don't easily share intermediate progress
  • Progress management is hard because completion times vary
  • Resource contention (multiple agents editing same files/databases) requires conflict resolution

Pattern 4: Message Bus

Best for: Event-driven pipelines and systems that will keep growing new agents.

How it works:

  • Agents communicate purely through publish and subscribe
  • A router pushes relevant messages to agents based on topics
  • New agents can join by subscribing to relevant topics without rewiring the system

Use cases: Security operations (alerts flow from triage → investigation → response), extensible automation pipelines.

Limitations:

  • Debugging is painful — tracing a cascade across five agents requires careful log correlation
  • Router accuracy is critical; a misclassified or dropped message causes silent failure
  • LLM-based routers add their own failure modes (hallucination, misinterpretation)

Pattern 5: Shared State

Best for: Highly collaborative tasks where agents need to build on each other's discoveries in real time.

How it works:

  • No central commander. Agents read from and write to a persistent shared store (database, filesystem, document)
  • Like a shared blackboard: agents pick up clues, work on them, and write findings back
  • System stops when time runs out, convergence threshold is reached, or a designated arbiter declares the answer good enough

Use cases: Cross-domain research (papers, patents, news, reports — each agent's finding becomes another's lead).

Limitations:

  • Without central control, agents may duplicate work or diverge
  • Reactive loops: Agent A writes, Agent B responds, Agent A responds back... burning tokens without conclusion
  • Must design hard stop conditions (time budget, convergence threshold, arbiter agent)

How to choose

Question Choose
Need explicit quality gate? Generator-Verifier
Short, well-defined subtasks? Orchestrator-Subagent
Long-running independent tasks? Agent Teams
Event-driven, ever-growing pipeline? Message Bus
Need real-time collaboration on shared discoveries? Shared State
Must eliminate single point of failure? Shared State

Orchestrator-Subagent vs Agent Teams

Ask: Do workers need to remember state across multiple tasks?

  • No → Orchestrator-Subagent
  • Yes → Agent Teams

Orchestrator-Subagent vs Message Bus

Ask: Is the workflow predictable?

  • Yes → Orchestrator-Subagent
  • No (event-driven, may change direction) → Message Bus

Agent Teams vs Shared State

Ask: Do agents need to reference each other's work in progress?

  • No → Agent Teams
  • Yes → Shared State

Message Bus vs Shared State

Ask: Is the goal processing a stream of events, or accumulating a knowledge base?

  • Stream of events → Message Bus
  • Accumulating knowledge → Shared State

Real-world architectures

These patterns are building blocks, not mutually exclusive. Common hybrids:

  • Orchestrator-Subagent for the main workflow, with a Shared State subtask for collaborative research
  • Message Bus for event distribution, with Agent Teams handling each event type

Sources

Linked from