Orchestrator agent
Why it matters
A single agent asked to do a sprawling task has to hold everything in its context window at once. As the task grows, details are dropped. An orchestrator keeps only the goal and the progress in view, while each worker sees only the material for its own job. That keeps each step focused.
The cost is coordination. More agents mean more model usage, more places for an error to start and a harder job tracing a bad answer back to its cause. The pattern pays off only when a task really needs it.
How to apply it
- Start with one capable agent on the whole task. Add an orchestrator only when that clearly fails.
- Give each worker one narrow, well-defined job and a clear description of what to return.
- Have the orchestrator check each result before combining them, instead of assuming every piece is correct.
- Put a human in the loop for any step that spends money or sends something to a customer.
- Watch cost and run time as workers are added.
What it is
An orchestrator agent works like a project manager. It does not do every step itself. It reads the goal, decides which parts of the work are needed, passes each part to a specialist agent with its own narrow instructions, and then collects what comes back. The specialists are often called workers or subagents. Workers can run at the same time, which saves elapsed time.
This pattern is common in tools that write code, run research or produce reports from several sources.
Common mistakes
- Splitting a small task that one agent handles fine.
- Vague worker briefs, which produce vague results that the orchestrator then has to guess about.