In a multi-agent LLM system, how does an orchestrator agent differ from a subagent?

## Two roles, not two kinds of software An *agent* here means a language model running in a loop: it decides an action, calls a tool, reads the result, and repeats until it is done or out of budget. In a multi-agent system, an **orchestrator** (also called a lead or coordinator) and a **subagent** (worker) are both exactly that. They are frequently the same model, running the same harness code. What distinguishes them is what each one is responsible for and, above all, what each one can see. The orchestrator is responsible for the *goal*. It interprets the user's request, decides how the work divides, decides who does what, decides when enough has been done, and writes the final answer. The subagent is responsible for one *bounded piece* — "find what these five papers say about dosing intervals and report back" — and nothing else. It has no view of the overall goal beyond what its brief tells it, and no authority to decide the shape of the answer. ## Separate context windows are the point A context window is the finite span of tokens a model can attend to on a single call. Every message, tool definition, tool result and reasoning trace consumes part of it. In a single-agent design all of that accumulates in one window: the model's forty-second search result sits next to the user's original request, and the model must attend to both. When the orchestrator spawns a subagent, the subagent begins a *new* conversation. It contains the task brief, the subagent's own tool definitions, and whatever the subagent then discovers. It does not contain the orchestrator's history. Conversely, the orchestrator's window never accumulates the subagent's intermediate observations — the dead ends, the tool errors, the raw page dumps. This is why subagents are described as *context-isolated*. ## The delegation brief must be self-contained Because the subagent cannot see the parent conversation, everything it needs has to be written down explicitly: the objective, the scope boundaries ("only these sources"), the expected output shape, and the tools it may use. A brief like "research this further" produces workers that duplicate each other's effort or drift onto different interpretations of the same task. Under-specified briefs are the single most common cause of bad multi-agent output, and the failure is invisible from the outside — you see a plausible summary that answers a subtly different question. ## The return contract is a summary, not a transcript What comes back is a condensed result: findings, an answer, a short structured report — deliberately not the working. A literature-review worker that read forty abstracts returns a 300-word finding with its citations, not the forty abstracts. Handing the whole transcript back would re-import exactly the noise the split was meant to keep out, and would leave you paying multi-agent prices for single-agent context behaviour. The practical consequence is that anything the orchestrator will need later must appear in the summary. Detail the worker saw but did not report is gone. Well-designed systems make the summary format explicit in the brief, and often have workers persist their raw output somewhere the orchestrator can fetch on demand rather than carrying it inline. ## What stays with the orchestrator Decisions, the plan, the user-facing interaction, and the synthesis all stay with the orchestrator. Subagents advise; the orchestrator decides. Keeping decision authority in one place is what makes the results composable — a set of workers that each independently decided how the answer should look produces contradictions no summary can reconcile. ## Common misreadings *"A subagent is just a tool call."* Superficially similar — you send input, you get output — but a tool is deterministic code with a fixed contract, while a subagent is a whole agentic loop that can plan, call tools, and fail in model-shaped ways. Treat its output as untrusted content, the same as any other model output. *"Subagents must be smaller or cheaper models."* Common, not required. Mixing a strong orchestrator with cheaper workers is one cost strategy, but the role split is about context and responsibility, not model size. *"Multi-agent means parallel."* Parallelism is a frequent *consequence* — independent subtasks can run at once — but a system that spawns one worker at a time is still multi-agent, and plenty of work is strictly sequential and cannot be parallelized at all.