Supervisor Pattern: Orchestrator and Workers (2026)

The orchestrator-workers pattern (Anthropic, December 2024)

Anthropic’s engineering essay frames the orchestrator-workers pattern as one of two top-tier multi-agent shapes (the other being evaluator-optimiser). The orchestrator is the agent with the goal and the routing logic. The workers are specialised by tool, role, or domain. The orchestrator decomposes the goal, calls the right worker for each sub-task, and synthesises the workers’ outputs into a coherent response.

The shape generalises a familiar pattern from human team structure: a project lead who dispatches work to specialists and integrates their outputs. The corresponding org chart has the supervisor at the top with reporting lines down to each worker.

Anthropic’s essay treats the orchestrator-workers topology as a deliberate complexity choice, not a default. The bar for moving from a single agent to an orchestrator-workers topology is a measurable failure mode in the simpler shape: context-window pressure, role conflict in the system prompt, or a cost-versus-latency profile that benefits from worker parallelism.

LangGraph supervisor implementation

LangGraph ships a supervisor primitive in which the supervisor node emits a structured handoff message naming the next worker, and the worker subgraph executes and hands back. State is shared across the graph via a typed schema. The supervisor primitive supports static, LLM-judged, and tool-based routing variants (see below). The reference is the LangGraph supervisor tutorial at langchain-ai.github.io/langgraph/tutorials/multi_agent/agent_supervisor. Access date: 30 April 2026.

LangGraph’s implementation is the most-cited concrete realisation of the Anthropic-defined pattern. The supervisor topology in LangGraph is also the foundation of the hierarchical-teams primitive (a supervisor whose workers are themselves supervisors).

Routing variants

Static routing

The supervisor uses a deterministic rule to select the worker. Examples: a router that dispatches based on the input’s detected language, or a router that always sends document-extraction tasks to a single specialist worker. Static routing is fast, predictable, and cheap; it is the right choice when the dispatch logic is genuinely deterministic.

LLM-judged routing

The supervisor’s LLM reads the input and picks the next worker based on its own reasoning. This is the canonical case in the LangGraph supervisor tutorial. The cost is two LLM calls per dispatch (one for the routing decision, one for the worker’s execution). The benefit is flexibility: the supervisor can route across cases that no static rule covers cleanly.

Tool-based routing

Each worker is exposed to the supervisor as a callable tool. The supervisor’s tool-call directly selects the worker, with the call arguments framing the sub-task. This compresses the routing into the standard tool-use loop that the underlying model already optimises for.

When the supervisor pattern is the right shape

When the work is genuinely separable into specialised roles. If three roles can be cleanly named (researcher, writer, reviewer) with non-overlapping system prompts and tool surfaces, the supervisor pattern earns its keep.

When you need a single accountable orchestrator for cost, latency, and audit. The supervisor is the chokepoint where logging, rate limiting, and policy enforcement happen. In an enterprise audit context, having one orchestrator that records every routing decision is structurally easier than auditing peer multi-agent state.

Common failure modes

Supervisor over-routes to one worker. When the routing prompt is ambiguous or one worker is the “safe” default in the prompt, the supervisor sends nearly everything to that worker. The remedy is to constrain the routing prompt and add evals that check the routing distribution.

Worker output mismatch. Workers that return inconsistent shapes (one returns prose, another returns JSON, a third returns markdown) make aggregation brittle. The remedy is a typed output schema enforced at the worker boundary.

Aggregation drift. The supervisor’s aggregator can hallucinate a synthesis that misrepresents what the workers said, especially when worker outputs are long. The remedy is to keep aggregation extractive (cite the worker output verbatim) where the use case allows.

Reference example

Related on this site

• Multi-agent peer topology: when there is no central supervisor.
• Hierarchical agents: when workers are themselves supervisors.
• Evaluator-optimiser pattern: the other Anthropic-named multi-agent shape.
• Human-in-the-loop: where a human approves before the supervisor’s aggregate is acted on.

For the engineering reference behind the supervisor pattern, see buildingeffectiveagents.com. For the process-flow view, see agenticswimlanes.com.