Supervisor Architecture
One coordinating agent delegates sub-tasks to specialised worker agents with isolated contexts — buying tool partitioning and parallelism at the price of coordination overhead and a single bottleneck.
The shape
A supervisor is an agent whose tools are other agents. The user talks to the supervisor; the supervisor decomposes the request, calls a Research agent, a Coding agent, a Data agent, or a Review agent as if they were functions, receives their results as text, and composes a final answer. Each worker has its own system prompt, its own tool subset, and its own context window that the supervisor never sees.
Delegation is a tool call: delegate(agent="research", task="find the three most recent papers on X", budget=8 steps). The worker runs a single-agent loop and returns a summary. The supervisor only sees the summary, which is the whole point: a 40-step research task compresses to 500 tokens in the supervisor's context.
This is the pattern covered in depth in Supervisor Pattern; here the concern is when it is the right architecture at all.
What you buy: partitioning and isolation
The supervisor solves the two hard limits of the Single Agent. Tool partitioning: 40 tools split into four workers of 10 each, so each model call sees only tools that are plausible for its sub-task; selection accuracy goes back up. Context isolation: the raw output of grep, web pages, and SQL results stays inside the worker; the supervisor's context holds only summaries and stays small across long tasks.
Isolation also has a security benefit. A Research worker that reads untrusted web pages can be given zero write tools; a Coding worker that writes files can be denied network access. A prompt injection in a web page can at most corrupt the research summary, not directly trigger a git push. That is least privilege applied at the agent boundary, per Tool Permissions and Least Privilege.
Independent sub-tasks can run in parallel. If research and data queries do not depend on each other, the supervisor dispatches both and waits; wall-clock latency is the max, not the sum.
- Each worker: narrow system prompt, ≤ 10 tools, its own step and token budget.
- Workers return structured summaries (
findings,sources,confidence), not transcripts. - Supervisor tools are exactly the
delegate_*functions plus afinishtool — it should not call raw tools itself. - Parallel dispatch only for sub-tasks with no data dependency; otherwise sequence them.
What you pay: coordination and the bottleneck
Every delegation costs at least two extra model calls: the supervisor deciding to delegate and the supervisor reading the result. With four workers that is eight or more calls before any real work, so simple requests get slower and more expensive than a single agent would make them. If your traces show the supervisor delegating a one-tool task to a worker that does one tool call and returns, the architecture is fighting you.
The supervisor is a serial bottleneck. It must read every result, and its own context grows with each summary. A poorly compressed worker output — a worker that returns its whole transcript — defeats isolation and pushes the supervisor into the same saturation problem you were escaping. The challenge When Not to Use Multi-Agent is exactly this trace.
Information loss is the subtler cost. The supervisor makes decisions from summaries, so a detail the worker dropped is gone. Workers cannot see each other's context, so the Review agent may critique code without knowing the requirement the Research agent found. Mitigate with a shared, typed artifact store (files, a state dict) that workers read and write, instead of passing everything through the supervisor's prose.
1WORKERS = {2 "research": dict(system=RESEARCH_SYSTEM, tools=[web_search, fetch_page], max_steps=8),3 "coding": dict(system=CODING_SYSTEM, tools=[read_file, write_file, run_tests], max_steps=15),4 "data": dict(system=DATA_SYSTEM, tools=[sql_readonly], max_steps=6),5 "review": dict(system=REVIEW_SYSTEM, tools=[read_file], max_steps=5),6}7 8def delegate(agent: str, task: str) -> dict:9 spec = WORKERS[agent]10 transcript = run_agent(task, tools=spec["tools"], system=spec["system"], max_steps=spec["max_steps"])11 # Compress: the supervisor must never see the raw transcript.12 return summarise(transcript, schema={"findings": str, "artifacts": list, "confidence": float})13 14supervisor_tools = [make_tool(f"delegate_{name}", lambda task, n=name: delegate(n, task)) for name in WORKERS]Properties
Complexity is high: you maintain N+1 prompts, N tool subsets, N budgets, a result schema, and a coordination policy. Latency is the highest of the common architectures for simple tasks (several serial model calls) but can beat a single agent on large parallelisable tasks. Cost is roughly the sum of all worker runs plus the supervisor's growing context — budget it per worker and per request.
Reliability is mixed. Isolation improves it on long tasks; coordination hurts it because each hand-off is a place where intent can be lost. Debuggability is the weakest point: a failure may be in the supervisor's decomposition, in a worker's execution, or in the summary between them, and you need hierarchical traces with parent-child span ids to tell which, as Tracing Agents describes.
The honest guidance: most teams that adopt a supervisor early would have been better served by a Router Architecture or a Workflow State Graph. Use a supervisor when the sub-tasks are genuinely open-ended and cannot be pre-planned, and when a single agent's tool count or context length has measurably broken.
- Complexity: 4 — many prompts, budgets, and one coordination policy.
- Latency: 4 for simple requests; can be 2–3 for parallelisable heavy tasks.
- Cost: 4 — sum of workers plus supervisor overhead.
- Reliability: 3 — isolation helps, hand-offs hurt.
- Debuggability: 2 — requires nested traces and per-worker replay.
Key points
- A supervisor is an agent whose tools are other agents; each worker has an isolated context and a narrow tool subset.
- It fixes tool overload and context saturation, and enables least-privilege isolation and parallel sub-tasks.
- Every delegation costs at least two extra model calls; simple requests become slower and pricier.
- The supervisor is a serial bottleneck and decides from summaries, so information loss is structural.
- Workers must return compressed, structured results — never raw transcripts.
- Prefer a router or a workflow unless sub-tasks are open-ended and a single agent has measurably broken.
When to use — and when not to
- A single agent is failing on tool selection because it has more than ~20 tools with overlapping purposes.
- Sub-tasks are open-ended, need many steps each, and their raw output would saturate one context.
- Sub-tasks need different privilege levels (read-untrusted-web vs write-to-repo) that must be kept apart.
- Several independent sub-tasks can run in parallel and wall-clock latency matters more than cost.
- The task decomposition is known in advance — a workflow graph gives the same partitioning deterministically.
- Requests are mostly single-intent — a router dispatching to one handler is cheaper and faster.
- Latency budget is tight (< 3 s); the extra supervisor round trips alone exceed it.
- The team cannot yet produce nested traces; you will not be able to debug it.
Failure modes
- Supervisor bottleneck: worker outputs are too verbose, the supervisor's context saturates, and it starts ignoring results.
- Ping-pong delegation: supervisor and worker hand the same unclear task back and forth until budgets run out.
- Lost detail: a worker summarises away the one fact the final answer needed.
- Over-delegation: trivial requests are routed through three workers, tripling latency and cost.
- Conflicting workers: coding and review agents disagree and the supervisor has no tie-break policy.
- Privilege leak: a worker is given the union of tools "to be safe", removing the isolation benefit.
Tradeoffs
Latency drops to ~3 when sub-tasks parallelise; debuggability rises with proper nested traces.