Agent orchestration: who decides what each agent does
Agent orchestration defines who plans, who executes, and how work is split, handed over and reviewed across several AI agents. A guide for designers.
What does it mean to orchestrate agents?
An AI agent is a model that can use tools and act over several steps. When a task is large and has parts that can be separated, a single conversation fills up fast: the context grows, the model loses details, and every change gets mixed with the previous ones.
Orchestration adds a coordination layer on top. Someone (a person or a lead agent) decides:
- which subtasks exist,
- which agent or tool solves each one,
- what information each agent receives,
- how the results are combined,
- and who confirms the result is good enough.
The idea is old in software. What is new is that the workers are models that read natural-language instructions, so designing orchestration looks more like writing a good brief than programming a rigid flow.
Why does it matter to a designer?
Because orchestration defines the experience of the person supervising it. If the orchestrator returns a confusing summary, the person does not know what to review. If each agent works silently for twenty minutes, the person loses track of progress. If two agents touch the same screen, conflicts appear that nobody anticipated.
Three design decisions change the experience:
- Visibility: what the person sees about what each agent is doing (status, plan, proposed changes).
- Control points: when the system stops and asks a human for a decision.
- Delivery format: how each worker returns its result, so the orchestrator can combine it without guessing.
What patterns exist?
In practice three setups show up:
| Pattern | Who holds control | When it works |
|---|---|---|
| Orchestrator and workers | A lead agent splits and combines | Separable tasks, such as researching several sources in parallel |
| Chain or pipeline | Each agent passes its output to the next | Fixed-order steps: draft, review, translate |
| Pair or review desk | Two agents check each other | Tasks where an error is costly and a second reading helps |
Anthropic describes its Claude research feature (Research) as a lead agent that plans and launches subagents in parallel, each with its own context window. Subagents return findings and the lead decides whether another round is needed. A citation agent checks at the end where each claim comes from. In Anthropic’s internal evaluation, a system with Claude Opus 4 as lead and Claude Sonnet 4 subagents beat a single Claude Opus 4 by 90.2%; the price was the token use mentioned below.
The OpenAI Agents SDK distinguishes two ways of delegating. With a handoff, control passes to the specialist, which takes over the conversation and answers the user. With agent as tool, the lead agent keeps control, calls the specialist like a function and keeps the final answer. The choice changes who talks to the user at the end, and therefore which tone and rules apply.
How do you brief each worker?
A worker only knows what the orchestrator writes for it. Anthropic reports that when instructions to subagents were vague, some of them repeated the same search or left gaps uncovered. A good assignment includes four things:
- A concrete objective: the question to answer, not a general topic.
- A delivery format: short list, table or JSON, with the fields the lead will need.
- Tools and sources: where to look and what not to touch.
- Limits: how much effort to spend and when to stop, so it does not research forever.
Think of it as a designer: it is a brief with scope and acceptance criteria. A vague assignment produces results that do not fit together.
When should you NOT orchestrate?
- When the task is sequential and each step depends on the previous one. Anthropic notes that most coding tasks have few truly parallel parts, and that agents which must share the same context work poorly when separated.
- When the value of the task does not justify the cost. More agents means more tokens, more time and more review.
- When you cannot review the result. An orchestrator that delivers ten pieces nobody reads is worse than one agent that delivers one.
Practical rule: start with one agent, measure where it gets stuck, and split only that part. If the bottleneck is that you cannot follow what the agent did, another agent will not fix it: you need better visibility and more control points.
Example
Illustrative example: you want to redesign a product’s pricing page. A lead agent reads the brief, and three workers review the competition, the current copy and the conversion data in parallel. Each returns a short list with sources. The lead combines them, removes duplicates and gives you one document with three decisions to approve. You approve before any agent touches the page.
A real case on this site that shows orchestration with tickets and two agents is the blog article on a two-agent workflow where Claude Opus 4.8 manages OpenCode. Its description presents a ticket-based flow in which Claude orchestrates OpenCode, cutting token waste while preserving review, visibility and human control.
To organize parallel work, read git worktrees for agents and subagents. For what passes between one agent and another, see agent handoffs. For the patterns in more detail, there are orchestrator-worker and multi-agent patterns.
Common mistakes
- Orchestrating before the task is clear. If the brief is vague, the orchestrator splits it badly.
- Giving every worker the full context. It burns tokens and mixes decisions.
- Not defining a delivery format. Each worker answers differently and the lead wastes time interpreting.
- Letting the orchestrator approve its own work. Review needs a different pair of eyes, human or another agent with written criteria.
- Measuring quality by how many agents are active. What matters is the reviewed result.