Multi-Agent Orchestration

A single agent hits three walls: context bloat, serial processing, and being a jack-of-all-trades, master of none. Multi-agent orchestration breaks work down among collaborating agents—from deterministic orchestration (chaining/routing) to agentic orchestration (orchestrator-workers). The core benefits are context isolation and parallelism.

Overview

A single agent (Agent Loop) doing everything itself hits three walls: context bloat (stuffing all work into one window dilutes mid-context information), serial processing (doing things step-by-step is slow), and being a jack-of-all-trades, master of none (a single system prompt trying to handle exploration, planning, execution, and review never excels at any). Multi-agent orchestration breaks work down among multiple collaborating agents to break through these three walls.

But let’s be realistic: most tasks don’t need multiple agents. If a single agent + a good set of tools can solve it, don’t go multi-agent—multi-agent introduces coordination overhead, context synchronization costs, and debugging complexity. First, confirm the benefits (using the same criteria as the "workflow vs agent" four gates in Agent Loop: complexity/value/feasibility/error cost), then proceed. This article clarifies: what orchestration patterns exist, what each solves, and how to implement them in the Claude ecosystem—and where they might fail.

From Deterministic Orchestration to Agentic Orchestration

Anthropic’s "Building Effective Agents" lays out multi-agent patterns from simple to complex. Key distinction: The first few are code-controlled deterministic orchestration (workflow)—steps and branches are hardcoded in code, with the model called once per step; only the last pattern (orchestrator-workers) is a true "agent-style" multi-agent approach where the model dynamically breaks down tasks itself.

Start with deterministic orchestration. If a task can be hardcoded using chaining/routing, don’t use orchestrator-workers—deterministic is more controllable, cacheable, and debuggable. Only when “how many subtasks to split into and what they are” cannot be predetermined do you need the model to act as coordinator.

Orchestrator-Workers: The Core of Agentic Multi-Agent

flowchart TD
    O["Orchestrator<br/>Understand goal → Dynamically decompose → Dispatch → Aggregate"]
    O -->|Subtask A + required context| W1["Worker A<br/>Independent window"]
    O -->|Subtask B + required context| W2["Worker B<br/>Independent window"]
    O -->|Subtask C + required context| W3["Worker C<br/>Independent window"]
    W1 -->|Result summary| O
    W2 -->|Result summary| O
    W3 -->|Result summary| O
    O --> R["Comprehensive output"]

Why it’s useful, three mechanism-level reasons:

• Context isolation: Each worker uses its own window to handle subtasks, sending back only result summaries to the orchestrator. The main context isn’t drowned out by raw content from twenty files—directly addressing Context Engineering’s “don’t overflow the window, don’t let mid-context get diluted.” This is the biggest benefit of multi-agent relative to “single agent reads everything.”
• Parallel fan-out: Independent subtasks run simultaneously, reducing wall-clock time from “sum of serial steps” to “duration of the slowest one.”
• Cost savings (without breaking cache): Subtasks can use cheaper models. But there’s a hard constraint from prompt caching: switching models mid-loop invalidates the entire cache segment (cache is bucketed by model). The correct approach is to spawn a separate subagent using a cheaper model, keeping the main loop on a single model—this preserves the main loop’s cache while saving on subtasks. Claude Code’s Explore subagent uses a cheaper model (e.g., Haiku) for read-only fan-out searches, following this pattern.

Implementation in the Claude Ecosystem

• Claude Code: Explore / subagent—dispatches breadth-first search and independent subtasks to sub-agents (often using cheaper models), sending result summaries back to the main agent; the main agent’s context and cache remain uncontaminated.
• OMC (oh-my-claudecode): Builds explicit team orchestration on top of Claude Code, splitting exploration/planning/execution/review among specialized agents, adhering to one principle: authoring and review run on separate lanes—the executing agent doesn’t self-review; instead, a reviewer/verifier evaluates in an independent context.
• Managed Agents multiagent (managed): Declare multiagent: {type: "coordinator", agents: [...]} on an agent to create a delegable roster; at runtime, each delegated sub-agent runs in its own thread—an event stream with context isolation, featuring independent model/system prompt/tools/skills. Mechanism details:
  • Shares container and filesystem, but not conversation history;
  • Roster of 1–20 agents, can generate multiple instances of the same agent, up to 25 concurrent threads;
  • Supports only one level of delegation (sub-agent rosters are not cascaded);
  • Cross-thread communication via agent.thread_message_sent/received, tool confirmations, etc., are routed back to the main thread for processing.

Best Practices

• Most tasks don’t need multiple agents. If a single agent + a good set of tools can solve it, don’t go multi-agent; first pass the four gates: complexity/value/feasibility/error cost.
• Start with deterministic orchestration, then dynamic coordination. If chaining/routing can handle it, don’t use orchestrator-workers—more controllable, cacheable, debuggable.
• Gain benefits through context isolation. Each worker uses its own window, sending back only result summaries, so the main context isn’t drowned out by raw content.
• Save money by spawning subagents, not switching models in the main loop. Switching models invalidates the entire cache segment; Claude Code’s Explore uses a cheaper model for read-only fan-out, following this pattern.
• Orchestrator explicitly writes required context into delegation messages. Threads don’t share history/tools; workers “don’t know the prior context,” so either write it into the message or save it to a shared file.
• Authoring and review run on separate lanes. The executing agent doesn’t self-review; instead, a reviewer/verifier evaluates in an independent context (see Evaluation and Observability).

Trade-offs and Failure Modes (with Fixes)

• Over-delegation: Opening a sub-agent for something solvable with a simple grep/read → Provide clear guidance: “Only delegate for parallel or independent workflows; read single files, sequential operations do directly.”
• Coordination overhead > benefits: Too many layers, too much back-and-forth, slower and more expensive than a single agent → Limit delegation depth (Managed Agents strictly allows only one level); don’t use dynamic coordination where deterministic orchestration suffices.
• Trap of non-shared context: Threads don’t share history/tools, workers “don’t know the prior context” → Orchestrator must explicitly write required context into delegation messages, or save to a shared file for workers to read.
• Switching models breaks cache: Switching models in the main loop to save money invalidates all cache, actually becoming more expensive → Isolate cheaper models using subagents, don’t switch in the main loop.
• Self-review endorsement: Executing agent self-evaluates its own work → Review on a separate lane (see OMC practices, Evaluation and Observability).

References

• Anthropic Official Documentation: "Building Effective Agents", Managed Agents Multi-Agent (platform.claude.com)

Keywords: multi-agent, orchestration, prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer, subagent, Explore, context isolation, fan-out, prompt cache invariant, model switch invalidation, Managed Agents multiagent, coordinator, threads, cross-thread messaging, one-level delegation, OMC team, authoring vs review lane