E1 · Orchestrator and subagents
Family: Multi-agent
A central agent splits the task, hands it to specialised subagents, often in parallel, then synthesises the results.
Principle
A central agent breaks the task down as it goes, delegates to specialised subagents and synthesises their results. It keeps control and stays in touch with the user; subagents are called like tools and report back. Unlike parallelisation (B3), the subtasks are not planned in advance: the orchestrator decides them.
The problem it solves
A task too broad for a single context, or whose parts can move in parallel, slows down and degrades a single agent.
When to use it
- The task splits into loosely coupled subtasks, preferably read-only, and its value justifies multiplied tokens: broad document research.
- The information exceeds one context window, or a single agent drowns in too many tools: each subagent keeps a narrow context and returns a summary.
When to avoid it
- Agents must share the same context or depend heavily on each other, as in code: stay with a single agent (C1). Writes stay on a single thread, “one hand that writes”.
- The split follows roles (plan, code, test): each handoff loses context. Split by isolable context, or stay with a chain (B1).
- Everything has to flow through the orchestrator: it becomes an information bottleneck.
Common pitfalls
The anti-patterns that misuse this pattern, best established first. Each sheet describes the symptoms, the public incidents and the remedies.
Framing and choice of level
- AP02 · Multi-agent by default — Several agents split by role, where a single agent already handled the task.
Tools and agent-computer interface
- AP12 · Tool overload — Every tool definition is loaded on every turn, overlapping ones included.
Loop, stopping and orchestration
- AP39 · Unchecked propagation — One agent’s output becomes the next one’s input unchecked, and a local error ends up in the deliverable.
- AP40 · Parallel writers — Several agents edit the same deliverable at once, each with its own implicit decisions.
Security and permissions
- AP59 · Unsupervised lethal trifecta — One agent reads untrusted content, touches private data and can send things out, with no one approving.
- AP61 · Third-party content acting with the principal’s rights — The agent acts with the rights of whoever launched it, on text written by a less privileged third party.
Oversight, operations and governance
- AP75 · Flying blind — In production with no step-level traces: no way to replay a session or tell where it failed.
Synonyms by vendor
- Orchestrator-workers (Anthropic (2024))
- Orchestrator-subagent (Anthropic (2026))
- Manager pattern, agents as tools (OpenAI, AWS Strands)
- Supervisor (LangGraph)
- Subagents (LangChain v1)
- Coordinator (Google Cloud, Google ADK)
- Hierarchical pattern (Google (Agents Companion))
- Workflow for orchestration (AWS)
- Hierarchical process (CrewAI)
- Vertical multi-agent (IBM)
- Centralized topology (Kim et al.)
Neighbouring patterns
Sources
- Multi-agent coordination patterns: five approaches and when to use them — Anthropic (C. Phillips), 2026-04-10
- How we built our multi-agent research system — Anthropic (J. Hadfield et al.), 2025-06-13
- Building multi-agent systems: when and how to use them — Anthropic (C. Phillips), 2026-01-23
- Towards a Science of Scaling Agent Systems — Y. Kim et al. (Google, MIT), arXiv, 2025-12-09
- Multi-Agents: What’s Actually Working — Cognition (W. Yan), 2026-04-22
Content reviewed on 2026-10-02