Advanced · Lesson 2 of 6 · 22 min
Multi-agent orchestration
When splitting work across subagents pays off, the orchestration patterns that recur in practice, how to estimate the token and latency bill, and the coordination failures to design against.
Why split work across agents
The main benefit of subagents is context isolation. A subagent runs in its own context window with its own instructions and tools, does a focused piece of work, and returns only a summary to the caller. The lead agent never sees the forty web pages the subagent read, so its own context stays clean for planning and synthesis. Claude Code's subagents work exactly this way.
The second benefit is breadth. Anthropic's research system uses a lead agent that plans and delegates to subagents running in parallel. On its internal research eval, a lead agent on a larger model with smaller-model subagents outperformed a single agent by 90.2%. Anthropic also found that token usage alone explained 80% of the performance variance on a browsing benchmark: multi-agent designs work partly because they let you spend more tokens on a problem than one context window allows.
That is also the catch. In the same data, agents used about 4 times the tokens of a chat, and multi-agent systems about 15 times. Multi-agent only makes sense when the task is valuable enough to pay for that, and when the work actually splits into independent parts.
Orchestration patterns you will reuse
Anthropic's catalogue of patterns covers most real systems. Prompt chaining runs fixed steps in sequence with checks between them. Routing classifies an input and sends it to a specialised handler, often a cheaper model for easy cases. Parallelization either splits a task into independent sections or runs the same task several times and votes. Orchestrator-workers has a central model break a task down dynamically, delegate the parts and synthesise the results. Evaluator-optimizer has one model draft and another critique in a loop.
Mapped to business work: routing suits support triage, where billing, technical and sales tickets get different prompts and tools. Sectioning suits reviewing a long contract clause by clause. Orchestrator-workers suits researching a list of 40 target accounts before a campaign. Evaluator-optimizer suits outbound email drafts checked against a written brand and compliance rubric.
Only orchestrator-workers is truly multi-agent in the dynamic sense. The others can run as plain workflows in n8n or Make with several model calls, which is cheaper to operate and easier to debug. Reach for a dynamic orchestrator only when you cannot know the subtasks until you see the input.
Estimating cost and latency before you build
Do the arithmetic first. Suppose one agent researching an account uses about 40,000 tokens. An orchestrator that plans, spawns five workers at 30,000 tokens each and then synthesises with 20,000 tokens spends roughly 170,000 tokens: four times the bill for one result. If the five workers find materially better information, that can be worth it; for a simple lookup it is waste.
Parallel workers cut wall-clock time, but the lead usually waits for the whole batch, so a run is as slow as its slowest worker. Anthropic notes that executing subagents synchronously simplifies coordination but creates a bottleneck. Put a timeout on every worker and let the lead proceed with partial results rather than stalling.
Mix models deliberately. Workers doing narrow extraction or search can run on a fast, low-cost model; the lead that plans and synthesises benefits from your provider's balanced or flagship model. Give each worker a turn cap and a token budget, and write effort rules into the lead's prompt. Anthropic's rule of thumb: simple fact-finding needs one agent with 3 to 10 tool calls, not a fleet.
type WorkerResult = { account: string; summary?: string; error?: string };
// runWorker is the agent loop from the previous lesson, with model and turn cap as options.
export async function researchAccounts(accounts: string[]): Promise<WorkerResult[]> {
const results: WorkerResult[] = [];
// Batches of 5 cap concurrency, so rate limits and spend grow predictably.
for (let start = 0; start < accounts.length; start += 5) {
const batch = accounts.slice(start, start + 5);
const settled = await Promise.allSettled(
batch.map((account) =>
runWorker({
model: "claude-haiku-5-5",
maxTurns: 6,
timeoutMs: 90_000,
// Objective, output format, sources and boundaries: vague briefs cause duplicate work.
task:
"Research the company " + account + ". Return JSON with industry, headcount_range, " +
"latest_funding_event and one source URL per fact. Use only public web sources. " +
"Do not contact anyone. If a fact is not found, return null for it.",
}),
),
);
settled.forEach((outcome, index) => {
results.push(
outcome.status === "fulfilled"
? { account: batch[index], summary: outcome.value }
: { account: batch[index], error: String(outcome.reason) },
);
});
}
// The lead synthesises from summaries only, and sees failures explicitly instead of silently.
return results;
}What breaks in multi-agent systems
Vague delegation is the most common failure. Anthropic found that without detailed task descriptions, subagents duplicate work, leave gaps or fail to find what is needed. Its early agents spawned 50 subagents for simple queries and distracted each other with excessive updates. Every worker brief needs an objective, an output format, guidance on tools and sources, and clear boundaries.
Shared writes are the next. If two workers can both update the same CRM record, you will eventually get conflicting tags or a double-sent message. Keep workers read-only and let a single component, ideally deterministic code rather than a model, perform writes after the lead has reconciled the results.
Finally, multi-agent runs are long and stateful, which makes deploys risky. Anthropic uses rainbow deployments, shifting traffic gradually from old to new versions while both run, so an update does not break agents mid-task. At smaller scale, the equivalent is versioning your prompts and tools and letting in-flight runs finish on the version they started with.
Key points
- ◆Subagents buy context isolation and parallel breadth; they cost many times the tokens of a single agent.
- ◆Most business tasks fit chaining, routing or parallelization as plain workflows; use dynamic orchestrator-workers only when subtasks are unknown upfront.
- ◆Estimate tokens and wall-clock time before building, and cap turns, tokens and time per worker.
- ◆Brief every worker with objective, output format, sources and boundaries, and keep writes in one place.
Terms in this lesson
Try it · exercise
Measure the real trade-off between one agent and an orchestrator with parallel workers on the same research task.
- Pick a task with independent parts, such as summarising three competitors' public pricing pages.
- Run it once as a single agent and record total input and output tokens from the API usage fields, plus wall-clock seconds.
- Run it again with one worker per competitor in parallel, each with a written brief (objective, output format, sources, boundaries), plus a synthesis call.
- Compare the two outputs for accuracy and completeness and write a one-line decision on which design you would ship.
You're done when: You have a small table with tokens and seconds for both designs, a note on which output was more complete, and a decision that cites those numbers rather than intuition.