Patterns & reasoning

What is a Supervisor Agent (Orchestrator-Worker)?

Also called: orchestrator-worker, hierarchical agents

Updated July 6, 2026
Quick Definition

A supervisor agent is the coordinating agent in a hierarchical multi-agent system: it decomposes a task into subtasks, delegates each to a specialized worker agent, monitors the results, and integrates them into a single output. Because workers report only to the supervisor, control and context stay centralized in one place.

Why the supervisor pattern matters

A single agent degrades as a task widens. Its context fills with material for every subproblem at once, its instructions accumulate competing concerns, and its tool list grows past what the model can select from reliably. Splitting the work across a multi-agent system addresses that, but it raises a new question: who decides how the work is split, and who owns the final answer?

The supervisor pattern — often called orchestrator-worker — answers with a hierarchy. One agent holds the plan; the others hold expertise. In production this pays off twice. Each worker stays small and testable, with a narrow prompt and a short tool list. And the system gains a single control point: one place to watch delegation decisions, enforce approvals, and correct course when a subtask comes back wrong.

How it works

A supervisor run is an agent loop in which the available actions are other agents:

  1. The supervisor receives the task and drafts a plan — a set of subtasks and the order or grouping in which to run them.
  2. It delegates a subtask to the most suitable worker, passing instructions and only the context that worker needs.
  3. The worker completes the subtask with its own model, instructions, and tools, then returns its result to the supervisor. Workers do not talk to each other.
  4. The supervisor evaluates the result. It may accept it, send it back with corrections, re-delegate to a different worker, or revise the remaining plan.
  5. When every subtask is satisfied, the supervisor integrates the results into one deliverable.

Because delegation decisions are model outputs, the loop is adaptive: the supervisor can spawn follow-up subtasks it did not anticipate, retry a worker with sharper instructions, or stop early once it has enough to answer.

Supervisor vs. router

The two are often conflated because both sit in front of specialist agents. A router classifies once: it inspects the incoming request, forwards it to the single best-suited agent, and plays no further part. A supervisor stays in the loop for the whole run — it plans, delegates repeatedly, evaluates intermediate results, and produces the integrated answer itself. Choose a router when each request maps cleanly to one specialist; choose a supervisor when the task must be decomposed and its pieces recombined.

In practice

Multi-agent runtimes generally ship the supervisor as one coordination strategy among several — alongside routing, sequential pipelines, and swarms — with delegation expressed either as tool calls or as a structured handoff. Run on a durable execution layer, each delegation and worker result is checkpointed, so a long hierarchical run survives crashes and every decision the supervisor made can be audited afterward as part of its orchestration record. For the full set of coordination strategies, see the multi-agent strategies documentation.

Frequently asked questions

What is the difference between a supervisor agent and a swarm?

A supervisor centralizes control: it plans the work, delegates to workers, and integrates every result itself. In a swarm, control passes directly between peer agents through handoff conditions, and no single agent owns the overall plan.

When should I use a hierarchical supervisor instead of a flat multi-agent setup?

Use a supervisor when a task needs decomposition, ordering, and synthesis into one deliverable, or when you want a single control point for observability and approvals. Flat patterns suit conversational flows where the right specialist changes as the exchange unfolds.

Is the supervisor itself an agent?

Usually, yes. The supervisor is typically an LLM-backed agent whose available actions are the worker agents, so it reasons about delegation the same way a single agent reasons about tool calls. When the plan is fixed in advance, it can also be a deterministic workflow.

See also in the docs

Related terms