What you will be able to do
- Choose between orchestrator-workers and simple parallelization based on whether the subtasks can be predicted
- Decide when specialist agents with scoped tools beat one agent that has every tool
- Configure a Managed Agents coordinator roster within its limits: one level of delegation, 20 unique agents, pinned versions and one advisor
- Plan the order of hand-offs and how the coordinator combines worker results into the final output
1.Decomposing work at runtime
In the orchestrator-workers pattern, a central LLM analyses each task and decides which subtasks to hand to worker LLMs. What separates it from simple parallelization is flexibility. The subtasks are not defined in advance; the orchestrator derives them from the specific input. The Anthropic cookbook runs the pattern in two phases. In the first, the orchestrator plans the work and writes structured subtask descriptions. In the second, each worker receives the original task, its own subtask and any extra context.
No. When subtasks are predictable and can be defined in advance, the cookbook says to use simpler parallelization. Orchestrator-workers earns its extra LLM calls only when the right subtasks depend on the input. It is also a poor choice for simple single-output tasks and for latency-critical paths.
Research fits this pattern because the steps cannot be predicted up front, and the post says a linear, one-shot pipeline cannot handle it. Anthropic's LeadResearcher starts by planning its approach and saving the plan to Memory. Context beyond 200,000 tokens is truncated, and the plan has to survive that. The lead then creates subagents with specific research tasks. When their results come back, it decides whether more research is needed, and it can spawn more subagents or change its strategy. The same freedom causes problems. Early versions spawned 50 subagents for simple queries, and prompt engineering was the main tool for correcting that. In Managed Agents, this runtime decomposition corresponds to new threads that the coordinator spawns whenever it delegates.
2.Specialisation and tool scoping
The third reason to split is specialisation. The Managed Agents docs describe routing work to agents with domain-focused system prompts and tools, instead of giving one agent every capability. The blog lists three signs that tool specialisation would help. The agent has too many tools (often 20 or more) and struggles to pick the right one. Its tools span unrelated domains and it confuses which one applies. Or adding new tools makes it worse at tasks it already handled.
The Northstar sales-proposal cookbook shows this in practice. A researcher agent gets web search. A librarian can only read the local case-study library. A pricing modeler sees only the pricing rules file and the seat count. Scoping each role this way stops the pricer from pulling a competitor's price off the web. It also keeps the case-study library, which could run to hundreds of files in production, out of the coordinator's context. Each roster entry is a full agent with its own model, so you can use different model tiers for different roles. The docs call the related pattern escalation: sending a subset of complex subtasks to a more capable agent or model.
3.Configuring the coordinator's roster
In Managed Agents, you set multiagent on the coordinator to declare which agents it can delegate to. The example below uses a capable model for the lead and Haiku for the reviewer and test-writer roles.
---
name: Engineering Lead
model: claude-opus-5-5
tools:
- type: agent_toolset_20260401
multiagent:
type: coordinator
agents: # paths: ant apply substitutes {type: agent, id, version}
- ./reviewer.md
- ./test-writer.md
---
You coordinate engineering work. Delegate code review to the reviewer agent and test writing to the test agent.| Entry | Effect |
|---|---|
| {"type": "agent", "id": agent.id} | References an existing agent, pinned to its latest version when the coordinator is created |
| {"type": "agent", "id": agent.id, "version": agent.version} | Pins a specific version of the agent |
| {"type": "self"} | Lets the coordinator spawn copies of itself |
| {"type": "advisor", "model": "<model id>"} | Gives the primary thread a model to consult mid-turn; at most one per roster |
The roster has hard limits. Delegation goes only one level deep. Referencing an agent that has its own roster fails validation. You can list at most 20 unique agents, but the coordinator can call multiple copies of each. The coordinator's configuration is snapshotted when it is created or updated. To use a newer version of a delegate, you have to update the coordinator. The advisor has no tools and cannot be spawned or messaged. The agent's own model must not be more capable than its advisor's.
You are configuring a doc-reviewer subagent that should be able to analyze documentation for accuracy and clarity but must never modify files or execute commands, even accidentally. How should you define its tool access?
Correct answer: A — Set tools to only Read and Grep so it can examine content without any write or execution capability
- A. Correct. Restricting the tools field to Read and Grep gives the subagent everything it needs to analyze documentation while structurally removing any ability to write files or execute commands.
- B. Omitting the tools field makes the subagent inherit all tools from the parent, which would include Edit, Write, and Bash, directly contradicting the requirement that it never modify files or run commands.
- C. Granting Edit and relying on a hook to deny every attempt still leaves an unnecessary attack surface and depends on the hook firing correctly every time, instead of removing the capability at the source.
- D. Bash access would let the subagent execute arbitrary commands, which violates the requirement that it must never execute commands even for seemingly safe purposes like linting.
Sources1
4.Sequencing hand-offs and synthesizing results
Decomposing the work is half the job. The coordinator also decides the order of hand-offs and combines the results. Order follows dependencies. In the Northstar run, the case-study picker needs the researcher's findings to judge relevance. So the coordinator starts the researcher and the pricing modeler in parallel, and runs the picker after the research comes back. It consults its advisor before writing, then writes the proposal itself. It controls the order and the hand-offs but does none of the specialist work.
Synthesis can be its own stage. In Anthropic's Research system, once the lead has gathered enough information, it passes everything to a CitationAgent. That agent locates where each claim is supported, so every claim is attributed to a source. Managed Agents threads are also persistent. The coordinator can send a follow-up to an agent it called earlier, and that agent still has its earlier context. It does not need to be briefed from scratch. Whatever the pattern, workers should return compact results. The value of isolation comes from what a subagent leaves out of what it hands back.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.If subtasks can run in parallel, orchestrator-workers is the right pattern.Why is that wrong?
Orchestrator-workers is for inputs where the right subtasks cannot be known in advance. When the subtasks are predictable, simple parallelization is cheaper and adds less latency.
Covered in Decomposing work at runtime
2.A specialist subagent can have its own roster and delegate to a further layer of agents.Why is that wrong?
A Managed Agents coordinator delegates only one level deep. Referencing an agent that has its own multiagent.agents roster fails the request with a validation error.
Covered in Configuring the coordinator's roster
3.Updating a subagent's definition automatically changes what the coordinator delegates to.Why is that wrong?
Roster references are pinned to the versions resolved when the coordinator was created or last updated. You must update the coordinator for it to use a newer version.
Covered in Configuring the coordinator's roster
Practise it for real
Define a coordinator with two specialist delegates using ant apply, and check the roster rules the platform enforces.
1.Write engineering-lead.md with the coordinator front matter from this page (multiagent type coordinator, agents ./reviewer.md and ./test-writer.md). Write reviewer.md and test-writer.md, each with a name, the claude-haiku-4-5 model and a one-line system prompt.
Why: Each delegate needs its own configuration. Tools, MCP servers and context are not shared with the coordinator.
You should see: Three agent files, with the coordinator's roster pointing at the other two by path.
2.Run
ant apply engineering-lead.md reviewer.md test-writer.md.Why: Apply creates each referenced agent first, then replaces its path with a pinned agent reference.
You should see: The coordinator's roster contains {"type": "agent", "id": ..., "version": ...} entries instead of file paths.
3.Edit reviewer.md so it has its own multiagent roster, then apply again.
Why: This tests the one-level delegation limit.
You should see: The create or update request is rejected with a validation error.
4.Remove that roster, change reviewer.md's system prompt, and apply only reviewer.md.
Why: This shows that the coordinator's roster is a snapshot.
You should see: The coordinator keeps delegating to the previously pinned reviewer version until you update the coordinator itself.
Stuck? Get a nudge
If step 3 is accepted, check that the nested roster is on the delegate, not on the coordinator.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“additional threads are spawned at runtime when the coordinator delegates work”
↩︎ Decomposing work at runtime“Route to agents with domain-focused system prompts and tools, such as a security agent or a documentation agent”
↩︎ Specialisation and tool scoping“Consult a more capable agent or model for a subset of complex subtasks.”
↩︎ Specialisation and tool scoping“A maximum of 20 unique agents can be listed in multiagent.agents, but the coordinator can call multiple copies of each agent.”
↩︎ Configuring the coordinator's roster“The coordinator can only delegate to one level of agents”
↩︎ Configuring the coordinator's roster“the agent's own model must not be more capable than its advisor”
↩︎ Configuring the coordinator's roster“Threads are persistent: the coordinator can send a follow-up to an agent it called earlier, and that agent retains everything from its previous turns.”
↩︎ Sequencing hand-offs and synthesizing results“The coordinator can only delegate to one level of agents”
↩︎ Exam trap 2“Referenced agents stay pinned to the versions resolved at that time and do not automatically pick up later updates to their definitions.”
↩︎ Exam trap 3 - 2.
“subtasks aren't pre-defined, but determined by the orchestrator based on the specific input”
↩︎ Decomposing work at runtime“Latency is critical (multiple LLM calls add overhead)”
↩︎ Decomposing work at runtime“Subtasks are predictable and can be pre-defined (use simpler parallelization)”
↩︎ Exam trap 1 - 3.
“saving its plan to Memory to persist the context, since if the context window exceeds 200,000 tokens it will be truncated”
↩︎ Decomposing work at runtime“spawning 50 subagents for simple queries, scouring the web endlessly for nonexistent sources”
↩︎ Decomposing work at runtime“A linear, one-shot pipeline cannot handle these tasks.”
↩︎ Decomposing work at runtime“passes all findings to a CitationAgent, which processes the documents and research report to identify specific locations for citations”
↩︎ Sequencing hand-offs and synthesizing results - 4.
“An agent with too many tools (often 20+) struggles to select the appropriate one.”
↩︎ Specialisation and tool scoping - 5.
“keeps the full case-study library out of the coordinator's context”
↩︎ Specialisation and tool scoping“It will start the researcher and the pricing modeler in parallel, then run the case-study picker once the researcher's findings come back”
↩︎ Sequencing hand-offs and synthesizing results“the coordinator gets to decide the order and the hand-offs without doing any of the specialist work itself”
↩︎ Sequencing hand-offs and synthesizing results