Orchestrator agents split tasks into subtasks and coordinate specialized agents to execute them.
One agent steers other agents. Specialization beats generalism the moment coordination becomes automatable.
What It Is
An orchestrator agent receives a task, breaks it into subtasks, and routes them to specialized task-agents - each with its own tool, domain, and responsibility. The task-agents work in parallel or sequence, their outputs flow back to the orchestrator, which assembles the result.
The puppeteer metaphor is close, but technically reductive: task-agents aren't will-less puppets, they're autonomous actors with local judgment. The orchestrator gives direction, not detail execution.
Why orchestrate at all:
- Specialization beats generalism: An agent that only does code review is usually better at it than a generalist
- Parallelism: Independent task-agents run in parallel instead of serially
- Context isolation: Each task-agent has its own focused context, no overflow
The pattern is standard today in multi-agent frameworks: Anthropic's Claude Code with subagents, Google's Agent2Agent protocol for cross-vendor coordination, Bain's enterprise pattern with central orchestrator plus specialized workers.
How To Spot It
- From the user's perspective it looks like one "intelligent single-agent", even though multiple agents work underneath
- Tasks run faster because sub-skills happen in parallel instead of sequence
- When something breaks, it's usually not a single agent that's broken, it's the task decomposition
- The architecture cleanly separates orchestrator logic from worker logic
What To Do (FL2 - Coordination)
- Architecture before tooling: First clarify which sub-skills the task needs, then pick agents for them, not the other way round
- Start small: Anthropic recommends starting with the simplest setup, only orchestrating when complexity justifies it
- Distinguish from Agent Boss: Orchestrator is technical, one agent steers others. Agent Boss is human, you yourself direct your agents. Both can coexist
- Build in governance: When every department builds its own orchestrator stack, Agent Sprawl grows at the architecture layer
The Trap
Orchestrating without need. A well-configured single agent often beats a badly assembled multi-agent system. The complexity has to actually be required, otherwise you've built architectural overhead that costs more than it saves. And turning the orchestrator into a single point of failure breaks the whole system when it goes down.