What is Supervisor Agent?
Supervisor Agent is the centralized control-loop role in a multi-agent system that owns shared task state, delegates bounded work to specialists, evaluates returned evidence, and decides whether to continue, retry, escalate, or terminate.
How It Works
A Supervisor Agent is an architectural role, not a standardized protocol or a requirement that every control decision use an LLM. A common implementation keeps the user-facing conversation and global task state in one LLM-backed manager while exposing specialist agents as tools; a hybrid can keep open-ended decomposition in the model and enforce budgets, permissions, state transitions, and release actions in deterministic code.
This differs from a Router Agent, which commonly classifies once and dispatches without owning a multi-step run, and from a Handoff, which transfers active control to another agent. Use a supervisor only when the execution path depends on intermediate results and specialization, context isolation, or parallel work creates measurable value. Fixed paths belong in a deterministic workflow, and simple tasks should stay with one agent.
Each Worker needs a versioned capability description, least-privilege Tool set, input and output Schema, context policy, timeout, retry semantics, and explicit failure result. The Supervisor must track task IDs, dependencies, state Revision, evidence, attempts, Token and Tool budgets, deadlines, Checkpoints, completion criteria, and a terminal reason.
Worker output is untrusted input: validate it before changing shared state, and protect external side effects with idempotency keys, authorization checks, approval gates, and durable records outside the Supervisor Prompt. Common failures include wrong delegation, duplicated work, stale or lost state, silent Worker failure, retry storms, premature completion, endless loops, context compression loss, and a synthesis bottleneck.
Evaluate the whole trajectory and final environment state against a single-agent or deterministic baseline rather than assuming more agents improve reliability.
Key Characteristics
- Central state ownership: keeps the run objective, task graph, dependencies, accepted evidence, attempts, and terminal status coherent
- Contract-based delegation: selects Workers from versioned capabilities and sends bounded inputs with explicit output and error Schemas
- Adaptive control loop: can delegate sequentially or in parallel, inspect results, ask for clarification, retry, replan, escalate, or stop
- Bounded execution: enforces workload-derived limits for steps, Tokens, Tool calls, concurrency, deadlines, retries, and recursion
- External safety boundary: applies least privilege, idempotency, authorization, approval, and durable state outside model-generated decisions
- Traceable evaluation: records every delegation and state transition for end-state, trajectory, cost, latency, and fault-injection tests
Common Use Cases
- Coordinating independent research tracks and synthesizing evidence with source provenance
- Managing multi-domain support while preserving per-Worker data and Tool permissions
- Delegating software analysis, implementation, testing, and review as separately auditable tasks
- Running adaptive investigations whose next step depends on the result of a previous specialist
- Escalating consequential or ambiguous actions to a human while preserving a resumable Checkpoint
Example
Loading code...Frequently Asked Questions
How is a Supervisor Agent different from a Router, Planner, or Handoff?
A Router commonly classifies an input and dispatches once. A Planner proposes tasks but need not execute or own state. A Handoff transfers active control to a specialist. A Supervisor remains responsible for the multi-step run: it delegates repeatedly, receives results, updates shared state, decides what happens next, and produces or approves a terminal outcome.
Does a Supervisor Agent have to be an LLM?
No. The role can be implemented by an LLM, deterministic code, or a hybrid. Use model reasoning for genuinely open-ended decomposition or synthesis, and keep predictable routing, budgets, Schema validation, authorization, idempotency, and irreversible-action gates in code. A fixed workflow does not become better merely because an LLM chooses every edge.
When is a Supervisor Agent better than one agent or a deterministic workflow?
Use one when the path cannot be known in advance, specialists need meaningfully different context or permissions, and intermediate results determine later work. Keep one agent when a bounded Tool set fits one context, and use a deterministic workflow when the sequence and conditions are known. Compare task success, risk, latency, Token use, and operator burden before accepting the extra coordination layer.
How do you prevent loops, duplicate work, and repeated side effects?
Give every task a stable ID and state, cap steps, retries, concurrency, Tokens, Tool calls, and elapsed time, and require an explicit terminal reason. Checkpoint before expensive stages, validate Worker status separately from content, and attach idempotency keys to external writes. A retry may repeat a read, but it must not silently repeat a payment, message, deployment, or deletion.
How should a Supervisor Agent be evaluated?
Test delegation accuracy, task completion, evidence coverage, duplicate or omitted work, retry and escalation correctness, budget compliance, tail latency, cost, and termination behavior. Inject Worker timeouts, malformed outputs, stale state, conflicts, and unavailable Tools. Evaluate the final environment state and full Trace, calibrate any LLM Judge against human labels, and compare with simpler baselines.