The Orchestrator Agent
One goal, several workers, and an agent in the middle whose only job is deciding who does what. This is the pattern behind almost every multi-agent system that survives contact with real work, and the whole of it fits on one screen.
In one line
An orchestrator is the agent that does none of the work. It reads the goal, cuts it into tasks, gives each task to the worker whose tools fit, decides what runs in what order, watches the budget, and puts the answers back together. The moment it starts answering something itself, it has stopped being an orchestrator and become a single agent with extra cost.
Its five jobs, in order
- Split. Turn one goal into tasks small enough that a single worker can finish one.
- Assign. Match each task to a worker by the tools that task needs, not by how the task is worded.
- Schedule. Independent tasks run together. Tasks that need an earlier answer run in order.
- Watch the budget. Tasks, time, and money are all capped, and it stops rather than quietly overrunning.
- Merge. Collect what came back, say which part came from where, and name anything nobody could do.
Three shapes people confuse
| Shape | Who decides the next step | Use it when |
|---|---|---|
| Single agent | The model, one step at a time, holding every tool itself. | The goal is one skill applied a few times. Most first agents should be this. |
| Supervisor | One agent, after reading each worker's reply, one worker at a time. | The next task genuinely depends on the last answer. |
| Orchestrator | A plan made up front, then dispatch, with re-planning only if something fails. | The goal splits into parts that do not need each other, so they can run at once. |
Optional: load a real model
Live: run the orchestrator
Give it a goal with two or three parts in one sentence. The split, the assignment and the tools are all real: each worker below really calls its own tool and really returns the answer. Watch the cards light up.
| The plan appears here: one row per task, with the worker it went to. |
Three things to try, in this order
1. Switch a worker off
Untick the calendar worker, then run a goal that asks for a date. The orchestrator will not improvise: the task comes back unowned and goes to a person. An orchestrator that guesses when no worker fits is the most expensive bug in this whole pattern.
2. Switch all at once to one after another
Same goal, same tools, same answer, and the clock at the end roughly triples. Independent tasks running in sequence is the most common reason an agent system feels slow.
3. Set the task budget to 1
The plan still lists everything. Only one task runs, and the rest are reported as not attempted rather than silently dropped. Half an answer that admits it is half an answer is safe. Half an answer that looks whole is not.
How it fails
The orchestrator answers
It has the model, so it is tempting. Then the workers are decoration and you pay twice for one agent.
Tasks that are not independent
Two tasks run at once, and the second needed the first one's answer. Split on data, not on grammar.
Merge without attribution
Four results arrive, one is wrong, and the merged paragraph gives no way to tell which. Keep the task labels in the output.
No unowned path
Every task must be able to end in "no worker owns this". Without that, the orchestrator hands the task to whoever is closest and gets a confident wrong answer.
What it costs
| Tokens | One planning call, one merge call, plus each worker's own run. Cheaper than it looks, because most workers need a small model or no model at all. |
|---|---|
| Latency | Best case, the slowest single task. Worst case, the sum of all of them. The scheduling decision is the whole difference. |
| Complexity | Real. You now have a plan, a dispatcher, a budget and a merge step to debug. Do not reach for it until one agent has actually failed at the job. |
Related: Supervisor and workers · Multiple agents · Planning · Routing · Monitoring agents · all patterns
Free from AI School - no signup, everything runs in your browser.