{
  "slug": "multi-agent-orchestration-patterns",
  "title": "Multi-Agent Orchestration Patterns",
  "description": "Vendor-neutral reference covering when multi-agent systems pay off and nine named patterns — from single-agent baseline through hierarchical and blackboard architectures — with tradeoffs, cross-cutting concerns, and a decision guide.",
  "category": "Guide",
  "tags": [
    "agents",
    "multi-agent",
    "orchestration",
    "architecture",
    "patterns",
    "design"
  ],
  "updated": "2026-06-15",
  "premium": false,
  "canonical": "https://changegamer.ai/resources/multi-agent-orchestration-patterns",
  "markdown": "https://changegamer.ai/resources/multi-agent-orchestration-patterns.md",
  "outline": [
    {
      "depth": 2,
      "text": "Key facts",
      "anchor": "key-facts"
    },
    {
      "depth": 2,
      "text": "When to use multi-agent vs single-agent",
      "anchor": "when-to-use-multi-agent-vs-single-agent"
    },
    {
      "depth": 2,
      "text": "The nine patterns",
      "anchor": "the-nine-patterns"
    },
    {
      "depth": 3,
      "text": "1. Single-agent-with-tools (baseline)",
      "anchor": "1-single-agent-with-tools-baseline"
    },
    {
      "depth": 3,
      "text": "2. Prompt chaining / sequential pipeline",
      "anchor": "2-prompt-chaining-sequential-pipeline"
    },
    {
      "depth": 3,
      "text": "3. Routing (classifier dispatch)",
      "anchor": "3-routing-classifier-dispatch"
    },
    {
      "depth": 3,
      "text": "4. Parallelization (sectioning + voting)",
      "anchor": "4-parallelization-sectioning-voting"
    },
    {
      "depth": 3,
      "text": "5. Orchestrator-workers",
      "anchor": "5-orchestrator-workers"
    },
    {
      "depth": 3,
      "text": "6. Evaluator-optimizer (generator + critic loop)",
      "anchor": "6-evaluator-optimizer-generator-critic-loop"
    },
    {
      "depth": 3,
      "text": "7. Hierarchical / manager-of-managers",
      "anchor": "7-hierarchical-manager-of-managers"
    },
    {
      "depth": 3,
      "text": "8. Group chat / debate",
      "anchor": "8-group-chat-debate"
    },
    {
      "depth": 3,
      "text": "9. Blackboard / shared state",
      "anchor": "9-blackboard-shared-state"
    },
    {
      "depth": 2,
      "text": "Cross-cutting concerns",
      "anchor": "cross-cutting-concerns"
    },
    {
      "depth": 2,
      "text": "Decision guide",
      "anchor": "decision-guide"
    },
    {
      "depth": 2,
      "text": "Verified sources",
      "anchor": "verified-sources"
    }
  ],
  "related": [
    {
      "slug": "prompt-injection-design-patterns",
      "title": "Prompt Injection Design Patterns: Architectural Defenses for Agents",
      "description": "Six named architectural patterns — Action-Selector, Plan-Then-Execute, LLM Map-Reduce, Dual LLM, Code-Then-Execute, Context-Minimization — plus Google DeepMind's CaMeL, that structurally constrain what an agent can do with untrusted data instead of just filtering it.",
      "url": "https://changegamer.ai/resources/prompt-injection-design-patterns"
    },
    {
      "slug": "agent-cost-latency-optimization",
      "title": "Agent Cost and Latency Optimization",
      "description": "Practitioner reference for reducing the cost and latency of production AI agents: the compounding model, token-level levers (caching, pruning), request-level levers (Batch API, parallelism), model-level levers (routing, reasoning-effort controls), and architecture-level levers (step reduction, semantic caching, code offloading).",
      "url": "https://changegamer.ai/resources/agent-cost-latency-optimization"
    },
    {
      "slug": "agent-memory-context",
      "title": "Agent Memory and Context Management",
      "description": "Architecture reference for agent memory: types (working, long-term, episodic, semantic, procedural), context-management techniques (summarization, RAG, sliding windows, prompt caching), storage substrates, and memory frameworks — with security notes and cross-links to related guides.",
      "url": "https://changegamer.ai/resources/agent-memory-context"
    },
    {
      "slug": "agent-reasoning-patterns",
      "title": "Agent Reasoning and Design Patterns",
      "description": "The canonical single-agent reasoning and acting loops: ReAct, Chain-of-Thought, Plan-and-Solve, ReWOO, Reflexion, Tree-of-Thoughts, and Self-Consistency — what each is, when to use it, and tradeoffs.",
      "url": "https://changegamer.ai/resources/agent-reasoning-patterns"
    }
  ],
  "furtherReading": [
    {
      "slug": "mcp-tool-description-injection",
      "title": "Defending MCP Clients Against Tool Description and Output Injection",
      "description": "Two distinct MCP injection surfaces — a tool description at connect-time and a tool's return value at call-time — and the client-side architectural patterns (Dual LLM, Action-Selector, Context-Minimization) that contain each one.",
      "url": "https://changegamer.ai/articles/mcp-tool-description-injection"
    },
    {
      "slug": "mcp-resources-and-prompts-vs-tools",
      "title": "MCP Tools vs Resources vs Prompts: How to Choose the Right Primitive",
      "description": "A decision procedure for MCP's three server-side primitives — who controls each one, a worked example of what it costs to expose a Resource as a Tool by mistake, and how Sampling and Elicitation fit as the client-side counterparts.",
      "url": "https://changegamer.ai/articles/mcp-resources-and-prompts-vs-tools"
    }
  ],
  "body": "Multi-agent systems add real cost, latency, and operational complexity. The decision to use one should be driven by a concrete failure or scaling need in a single-agent design, not by the appeal of the architecture. This reference covers when to go multi-agent, the nine canonical patterns (with tradeoffs), and the cross-cutting concerns every builder encounters.\n\n## Key facts\n\n- Adding multiple agents is only worth the added cost and complexity when a genuine failure or growth-driven need shows up in a single-agent design — never just because the architecture is appealing.\n- Four conditions justify going multi-agent: subtasks that separate cleanly, workloads where running in parallel pays off, subtasks that need different prompts/tools/models, and tasks that genuinely exceed one context window.\n- Anthropic's own internal research system — running agents in parallel — beat its single-agent baseline (Claude Opus 4) by more than 90% on breadth-first research work, the kind of task where exploring many independent directions at once mattered most.\n- Nine named patterns span the spectrum from a single-agent-with-tools baseline through prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, hierarchical manager-of-managers, group chat/debate, and blackboard/shared-state designs.\n- Fanning work out across ten parallel subagents in an orchestrator-workers setup can multiply spend roughly tenfold versus doing the job with one agent, so cost should be modeled before deploying.\n- Cross-cutting concerns every builder hits include choosing shared state versus message passing, distinguishing a handoff from delegation, planning for partial subagent failure, bounding evaluator/debate loops with a hard stop, and propagating a shared trace ID for observability.\n- The recommended path is to start single-agent, pin down the one concrete failure driving the change, reach for the smallest pattern that fixes it, and instrument tracing before scaling up.\n\n## When to use multi-agent vs single-agent\n\nAnthropic's \"Building Effective Agents\" (Schluntz & Zhang) frames agentic systems as either *workflows* — where LLMs and tools are orchestrated through predefined code paths — or *agents* — where the LLM dynamically directs its own process and tool use. Multi-agent adds a third dimension: multiple LLM-driven actors cooperating.\n\nAdd multi-agent only when one of these conditions holds:\n\n- **Separable subtasks**: the problem cleanly decomposes into independent work units that do not require tight shared state. If subtasks are tightly coupled, coordination overhead outweighs the benefit.\n- **Parallelism pays**: subtasks can run concurrently and the wall-clock gain justifies the added token fan-out cost. Anthropic's internal multi-agent research system outperformed a single Claude Opus 4 agent by 90.2% on breadth-first research queries where parallel exploration across many independent directions was the key differentiator.\n- **Specialization**: different subtasks demand different system prompts, tool sets, or even models (e.g., a cheap fast model for routing, a large model for synthesis).\n- **Context-window limits**: a task genuinely exceeds one context window and cannot be handled by summarization or retrieval alone.\n\nThe default should be: start single-agent with tools. Add structure only when a real failure or scaling need demands it.\n\n## The nine patterns\n\n### 1. Single-agent-with-tools (baseline)\n\nOne LLM with access to a toolset in a loop. The baseline against which all multi-agent patterns should be benchmarked. When to use: all tasks where the scope fits one context window and does not require parallel execution. Tradeoff: limited by context window; no parallelism.\n\n### 2. Prompt chaining / sequential pipeline\n\nOutput of step N becomes input to step N+1; each step uses a focused prompt. Named in Anthropic's \"Building Effective Agents\" as *prompt chaining*. When to use: tasks that decompose naturally into ordered stages (draft → critique → refine; extract → classify → summarize). Tradeoff: errors propagate forward; latency is additive; no parallelism.\n\n### 3. Routing (classifier dispatch)\n\nA classifier step reads the input and routes it to the appropriate specialist agent or prompt. Named in Anthropic's \"Building Effective Agents\" as *routing*. When to use: handling diverse input types that each require different handling (customer service triage, language detection, intent classification). Tradeoff: classification errors send tasks to the wrong handler; requires maintaining multiple specialist configurations.\n\n### 4. Parallelization (sectioning + voting)\n\nMultiple agents work on the same problem simultaneously. Two sub-variants from Anthropic's \"Building Effective Agents\": *sectioning* (divide a task into parallel independent chunks) and *voting* (multiple agents independently solve the same task; majority or best answer wins). When to use: long documents that can be chunked, independent research threads, or high-stakes decisions where redundancy reduces error rate. Tradeoff: token fan-out — cost multiplies with the number of parallel agents; requires aggregation logic.\n\n### 5. Orchestrator-workers\n\nA lead orchestrator agent dynamically spawns, delegates to, and aggregates results from worker subagents. Named in Anthropic's \"Building Effective Agents\" as *orchestrator-workers* and demonstrated in their multi-agent research system (where the orchestrator plans the research strategy and spawns parallel search subagents). When to use: tasks with dynamic scope — the number and type of subtasks is not known in advance. Tradeoff: orchestrator becomes a single point of failure; inter-agent communication cost; harder to debug.\n\n### 6. Evaluator-optimizer (generator + critic loop)\n\nOne agent generates a candidate output; a second evaluates it against a rubric and returns feedback; the generator revises. Loop repeats until the evaluator is satisfied or a termination condition is met. Named in Anthropic's \"Building Effective Agents\" as *evaluator-optimizer*. When to use: tasks with a verifiable quality criterion (code that must pass tests, text that must meet a rubric). Tradeoff: requires a reliable evaluator — a weak critic produces useless loops; loop count must be bounded (termination guard mandatory).\n\n### 7. Hierarchical / manager-of-managers\n\nA top-level orchestrator delegates to sub-orchestrators, each of which manages their own worker pool. Extends orchestrator-workers to multiple tiers. When to use: very large decomposable tasks where a single orchestrator would exceed context or coordination limits. Tradeoff: coordination overhead grows with depth; error propagation is harder to trace; observability becomes critical (see /resources/agent-observability).\n\n### 8. Group chat / debate\n\nMultiple agents participate in a shared conversation, each contributing from its own perspective or role. A moderator (human or LLM) synthesizes or selects the final output. Sometimes called *multi-agent debate*. When to use: tasks benefiting from adversarial review, brainstorming, or simulated stakeholder perspectives. Tradeoff: verbose; expensive; convergence is not guaranteed without a strong moderator or termination criterion.\n\n### 9. Blackboard / shared state\n\nAgents read from and write to a shared structured artifact (the \"blackboard\") — a document, database, or structured object — rather than passing messages directly. Each agent acts when its triggering conditions are met. When to use: long-running tasks where agents work asynchronously and on different parts of the same artifact (co-authoring, iterative document refinement). Tradeoff: write conflicts require locking or versioning; shared state is a single point of corruption if an agent writes bad data.\n\n## Cross-cutting concerns\n\n**Context and state sharing** — choose between shared memory (blackboard/database) and message passing. Shared memory enables tight coordination but requires conflict handling. Message passing is simpler to reason about but increases latency per hop.\n\n**Handoffs vs delegation** — a handoff transfers full control (the calling agent stops); delegation keeps the orchestrator in control and aggregates results. Handoffs lose context; delegation multiplies context cost.\n\n**Error propagation and partial failure** — in a multi-agent pipeline, a subagent failure can silently corrupt downstream results. Design explicit error contracts: subagents must return structured success/failure signals, not just text. The orchestrator must handle partial failure (retry, degrade, or surface the gap).\n\n**Cost explosion (token fan-out)** — parallelization and orchestrator-workers multiply token spend. Model the cost before deploying: N parallel subagents at M tokens each costs N×M tokens. A 10-subagent orchestrator-workers pattern can be 10× more expensive than the single-agent baseline for the same task.\n\n**Termination and loop guards** — evaluator-optimizer and group-chat patterns can loop indefinitely without a hard stop condition. Always set a maximum iteration count; prefer an evaluator that returns a structured `{pass: bool, feedback: string}` output so the loop can terminate deterministically.\n\n**Observability** — multi-agent runs require a shared `trace_id` propagated across all subagent calls. Without it, cross-agent debugging is impossible. See /resources/agent-observability for the OpenTelemetry GenAI semantic conventions and tooling.\n\n**Inter-agent trust and security** — subagents are not implicitly trusted. An agent receiving instructions from an orchestrator should apply the same prompt-injection and tool-abuse mitigations as it would for user input. For A2A delegation protocols and token audience binding across agents, see /resources/mcp-vs-a2a. For the full security checklist, see /resources/agentic-security-checklist.\n\n## Decision guide\n\n1. **Start single-agent.** Build a single LLM with the minimum toolset that could theoretically solve the task. Measure cost, latency, and success rate.\n2. **Identify the concrete failure.** Is it a context-window limit? A parallelism gap? A quality problem that needs a critic? Identify one specific failure before adding structure.\n3. **Apply the minimum pattern.** Prompt chaining before orchestrator-workers. Evaluator-optimizer before group chat. Each added tier multiplies complexity and cost.\n4. **Add observability first.** Before scaling to multi-agent, instrument your single-agent run with traces. You will need those signals to debug the multi-agent version.\n\nFor which frameworks implement which patterns, see /resources/agent-frameworks-compared. ChangeGamer's own publishing pipeline is a running instance of the orchestrator-workers / hierarchical pattern above (a master agent delegating to specialized subagents) — see the premium resource [How ChangeGamer Runs Itself](/resources/autonomous-operations) for the concrete cadence.\n\n## Verified sources\n\n- Anthropic — Building Effective Agents (Schluntz & Zhang): https://www.anthropic.com/research/building-effective-agents\n- Anthropic — How we built our multi-agent research system: https://www.anthropic.com/engineering/multi-agent-research-system",
  "sources": [
    "https://www.anthropic.com/research/building-effective-agents",
    "https://www.anthropic.com/engineering/multi-agent-research-system"
  ]
}