Multi-Agent Orchestration

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

Overview

A single agent (Agent Loop) doing everything on its own hits three walls: context inflation (stuffing all work into one window dilutes mid-context information), serial processing (can only proceed step-by-step, which is slow), and jack-of-all-trades, master of none (a single system prompt trying to handle exploration, planning, execution, and review, excelling at none). Multi-agent orchestration breaks work down among multiple collaborating agents to break through these three walls.

But let's temper expectations first: most tasks do not require multi-agent systems. If a single agent with a good set of tools can solve it, don't go multi-body—multi-body introduces coordination overhead, context synchronization costs, and debugging complexity. First, confirm the benefits (criteria are the same 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-body patterns from simple to complex. Key distinction: the first few are code-controlled deterministic orchestration (workflow)—steps and branches are hardcoded in code, merely invoking the model at each step; the last one (orchestrator-workers) is the "agent-style" multi-body where the model dynamically breaks down work 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-Body

flowchart TD
    O["Orchestrator<br/>Understand goal → Dynamically decompose → Schedule → 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 reasons at the mechanism level:

• Context Isolation: Each worker uses its own window to process subtasks, sending back only result summaries to the orchestrator. The main context isn't drowned by the raw content of twenty files—this directly corresponds to the "don't burst the window, don't let mid-context get diluted" principle in Context Engineering. This is the biggest benefit of multi-body relative to "single agent reads everything."
• Parallel Fan-out: Independent subtasks run simultaneously, reducing wall-clock time from "sum of serial steps" to "time of the slowest one."
• Cost Savings (without breaking cache): Subtasks can use cheaper models. However, there's a hard constraint with 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—delegates breadth search, 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): Performs explicit team orchestration on top of Claude Code, delegating exploration/planning/execution/review to specialized agents, adhering to one principle: authoring and review are two separate lanes—the executing agent does not self-review; instead, a reviewer/verifier is spawned to evaluate 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 models/system prompts/tools/skills. Mechanism details:
  • Shares container and file system, 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 do not cascade);
  • 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 do not require multi-agent systems. If a single agent with a good set of tools can solve it, don't go multi-body; 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, and debuggable.
• Gain benefits through context isolation. Each worker uses its own window, sending back only result summaries, preventing the main context from being drowned by raw content.
• Spawn subagents for cost savings, don't switch models in the main loop. Switching models invalidates the entire cache segment; Claude Code's Explore uses cheaper models for read-only fan-out, following this pattern.
• Orchestrator explicitly writes required context into delegation messages. History/tools are not shared between threads; workers "don't know the antecedents," so either write into the message or save to shared files.
• Separate authoring and review into two lanes. The executing agent does not self-review; instead, a reviewer/verifier is spawned to evaluate in an independent context (see Evaluation and Observability).

Trade-offs and Failure Modes (with Fixes)

• Over-delegation: Opening a sub-agent for something grep/read could solve → Provide clear guidance: "Only delegate for parallel or independent workflows; do single-file reads and sequential operations directly."
• Coordination overhead > benefits: Too many hierarchy levels, too many back-and-forths, slower and more expensive than a single agent → Control delegation depth (Managed Agents only allow one level); don't use dynamic coordination for tasks that can be deterministically orchestrated.
• Context non-sharing trap: History/tools not shared between threads, workers "don't know antecedents" → Orchestrator must explicitly write required context into delegation messages, or save to shared files for workers to read.
• Model switching breaks cache: Switching models in the main loop to save money, resulting in all cache being invalidated and actually costing more → Isolate cheaper models using subagents, don't switch in the main loop.
• Self-review endorsement: Executing agent self-evaluates its own work → Review in 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