AI
Multi-Agent Orchestration: Subagents Explained
August 20268 min read
Multi-agent orchestration is a design where a lead agent breaks a large task into smaller scoped jobs and delegates them to specialized subagents. Each subagent runs in its own context window, works in parallel, and returns a distilled result. The lead then combines those results into a final answer.
A subagent is a scoped worker with its own context window, its own system prompt, and often a limited set of tools. It handles one narrow task and returns only a short summary, so its raw tool output never clutters the lead agent's context. The main agent stays focused on planning and synthesis.
Each agent runs its own context window, so several agents means several parallel conversations, each consuming tokens. Anthropic reported its multi-agent research system used roughly fifteen times more tokens than a normal chat. That extra spend only pays off on broad, high-value tasks.
Use a single agent when the task is narrow, sequential, or depends on shared state throughout. Splitting such work across subagents fragments the context, adds coordination overhead, and costs more tokens for a worse result. Both Anthropic and OpenAI advise starting with one agent and adding specialists only when they clearly help.
The most common are fan-out and gather, where a lead runs independent subagents in parallel and merges their output; worker pool, where a manager calls specialists as tools; critic or verifier, where one agent checks another's draft; and pipeline, where agents transform output in sequence. Real systems usually mix these.
Key Takeaway
Multi-agent orchestration is a design where a lead agent splits a large task into scoped jobs and spawns specialized subagents that each run in their own context window, work in parallel, and return a distilled result. It buys broad coverage and context isolation, but costs more tokens and coordination, so single-agent setups often win for narrow tasks.
You give an agent a big research question and watch its context window fill up. Search results, file dumps, tool logs, half-finished reasoning, all of it piling into one conversation until the model starts losing the thread. Past a certain size, more context stops helping and starts hurting.
Multi-agent orchestration is one answer. Instead of one agent doing everything in one context window, a lead agent plans the work and hands scoped pieces to subagents that each run on their own. This post explains the model, the patterns behind it, and the honest tradeoffs, so you know when it earns its keep and when a single agent is the smarter call.
A single agent keeps its entire history in one context window: the system prompt, every tool call, every result, and every reasoning step. That works beautifully for focused tasks. It breaks down when the task is broad, because the window fills with material the model has to re-read on every turn.
Two limits show up together. First, capacity: a wide research task can need more source material than any single window holds. Second, focus: as the window fills with raw tool output, the signal the model actually needs gets buried in noise, and answer quality drifts. Anthropic notes that breadth-first questions with many independent directions are exactly the case a single agent struggles to cover well.
In the orchestrator-worker model, a lead agent owns the overall goal. It analyzes the request, decides how to split it, and spawns subagents, each with a narrow brief. Every subagent gets its own context window, its own system prompt, and often its own limited set of tools. It does its scoped job and returns a short, distilled result to the lead.
Two properties make this powerful. Context isolation means a subagent's messy tool output stays inside the subagent, and only the summary reaches the lead, so the orchestrator's window stays clean. Parallelism means several subagents explore different branches at once instead of one after another. Anthropic reports this cut research time substantially on complex queries by running subagents and their tool calls concurrently.
Give each subagent a single clear objective and tell it exactly what to return. A vague brief makes it wander and burn tokens; a sharp one keeps the distilled result small and genuinely useful to the lead.
Most real systems are combinations of a few recurring shapes. Pick the one that matches how your task actually decomposes.
Orchestration is not free. Running multiple agents means running multiple context windows, and token usage climbs fast. Anthropic reported its multi-agent research system used roughly fifteen times more tokens than a normal chat, and that token spend explained most of the performance difference. That only pays off when the task is valuable and genuinely wide.
There is coordination cost too. The lead has to write good briefs, subagents can misread scope, and stitching partial results into one coherent answer is its own work. Both Anthropic and OpenAI give the same advice: start with one agent, and add specialists only when they clearly improve capability isolation, prompt clarity, or coverage. Splitting too early just adds prompts and traces without making the result better.
More agents does not mean better answers. If a task shares one thread of state or needs tight real-time coordination, subagents fragment it, and you pay extra tokens for a worse, harder-to-debug result.
Reach for multiple agents when the task is broad, the branches are independent, or a side job would flood your main context with output you will never reference again. Keep a single agent when the work is narrow, sequential, or depends on shared state throughout.
Multi-agent orchestration trades tokens and coordination for parallel coverage and clean, isolated context. Used on broad, valuable, independent work it can outperform a single agent by a wide margin; used on narrow tasks it just adds cost and fragility. Start with one agent, measure, and split only when the work clearly demands it.