ModelRefs / Supervisor / Worker — Agent Pattern
Supervisor / Worker — Agent Pattern
A supervisor agent dispatches tasks to specialized worker agents and aggregates their results. One supervisor LLM owns task decomposition and routing.
Overview
One supervisor LLM owns task decomposition and routing. Multiple workers — each with their own narrow toolset and prompt — execute sub-tasks. The supervisor merges outputs and decides whether to terminate.
When to use it: Your task has clearly separable sub-tasks that benefit from specialized prompts or toolsets.
Pattern details
| Pattern class | multi-agent |
|---|---|
| Difficulty | advanced |
| Autonomy | autonomous |
| Also known as | orchestrator-workers, manager agent |
| Last reviewed | 2026-06-07 |
Known failure modes
- Token blowup — Each worker re-reads full context. Mitigation: Pass only the minimum sub-task brief to each worker.
- Supervisor bottleneck — Serial supervisor loop limits parallelism. Mitigation: Make decomposition + merge concurrent where possible.
When not to use it
- Using supervisor/worker for tasks a single ReAct agent solves.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Supervisor / Worker — Agent Pattern.
Frequently asked questions
When should I use the Supervisor / Worker agent pattern?
Your task has clearly separable sub-tasks that benefit from specialized prompts or toolsets.
What are common failure modes of Supervisor / Worker?
Token blowup • Supervisor bottleneck
Is Supervisor / Worker production-ready?
Yes when paired with the safety controls and observability hooks documented on the pattern page.