Supervisor Pattern
One orchestrator agent decomposes work, delegates to specialist agents, and merges results — simple to reason about, but the orchestrator is the bottleneck and the single point of failure.
Mechanism
The supervisor is itself an agent whose tools are the other agents. delegate(agent="researcher", task="find 3 recent papers on X") is just a tool call whose implementation runs a sub-agent loop and returns its final answer as the tool result. This is why Supervisor Architecture was already reachable from the single-agent architecture lessons — it is single-agent with expensive tools.
The supervisor holds the plan and the running state; specialists hold only their sub-task. Good supervisors send narrow, self-contained briefs (goal, constraints, expected output format) because the specialist has no other context. Bad supervisors forward the entire conversation and pay the token bill three times.
1SPECIALISTS = {2 "researcher": Agent(system=RESEARCH_PROMPT, tools=[web_search, read_url]),3 "coder": Agent(system=CODER_PROMPT, tools=[read_file, write_file, run_tests]),4}5 6def delegate(agent: str, brief: str, max_turns: int = 8) -> str:7 """Run a specialist on a self-contained brief and return its final answer."""8 spec = SPECIALISTS[agent]9 return spec.run(brief, max_turns=max_turns, budget_tokens=20_000)10 11supervisor = Agent(system=SUPERVISOR_PROMPT, tools=[delegate, final_answer])Where it breaks
Every specialist result flows through the supervisor, so its context grows with the number of delegations. After 10 delegations returning 2k tokens each, the supervisor is carrying 20k tokens of results and its planning quality drops. Summarise results on the way in, or store them and pass references (Context Selection & Compression).
Delegations are sequential unless you make them parallel. A supervisor that issues one delegation per turn takes 5 × (specialist latency) for 5 independent sub-tasks. Use Parallel vs Sequential Tool Calls semantics: emit several delegate calls in one turn when tasks are independent.
The supervisor is also the place where "I have enough, stop" must be decided. Without an explicit budget it will keep delegating "one more check" (agent-loop-not-terminating).
- Give the supervisor a hard delegation budget (e.g. 6) and a token budget; make exceeding either a terminal state.
- Return structured results (
{summary, evidence, confidence}) from specialists so the supervisor can merge without re-reading everything. - Log each delegation as its own span with the brief and the result (Tracing Agents).
Evaluation
Evaluate specialists in isolation with their own golden briefs, then evaluate the supervisor on routing and merging with specialists stubbed to canned answers. If you only evaluate end to end, a regression in the coder looks identical to a regression in the supervisor's brief-writing.
Key points
- Specialists are tools from the supervisor's point of view.
- Send narrow briefs; never forward the whole conversation.
- Supervisor context grows with delegations — compress or reference results.
- Parallelise independent delegations; budget the total.
- Evaluate routing separately from specialist quality.
When to use — and when not to
- Sub-tasks are heterogeneous and need different tools or prompts.
- One party must own the overall plan and final answer.
- Sub-tasks are dynamic — you do not know in advance which specialists are needed.
- The order of steps is fixed — use Pipeline Pattern or a workflow graph.
- Specialists need to talk to each other frequently — the supervisor becomes a relay.
- A single agent with the union of tools performs equally well on evals.
Failure modes
- Supervisor context bloat from raw specialist outputs.
- Serial delegation makes latency additive.
- Vague briefs → specialists solve the wrong problem confidently.
- No termination budget → infinite "verify once more" loops.
- Supervisor rewrites specialist findings and introduces errors during merge.