Orchestration: many agents at once

In module 14 you used one subagent at a time: a self-contained task, a separate context, a summary back. In module 16 you saw that an agent is a model, some tools and a loop, and that simple almost always wins. In module 17 you learned to write a task an agent can finish and you can verify. This module brings the three together and answers the question that shows up when the work grows: what if it were several agents at once?

The short answer: you can, it is sometimes well worth it, and it almost always costs more than it looks. We will cover what orchestration is, when it pays off, how to do it with Claude Code, and why the orchestrator’s job is not handing out work but verifying it. Everything is checked against Anthropic’s engineering guides and the Claude Code documentation as of October 2026.

What is agent orchestration, and which patterns exist?

Orchestration is coordinating several agents on a task that one alone would not do well. Someone (a coordinating agent or a plain script) splits the work, delegates it to workers that each have their own context window and tools, and combines what they return. The important word is "combines": the value is not in launching agents but in what happens when they come back.

Anthropic’s guide "Building effective agents", which you met in module 16, describes three ways to do it, from the most rigid to the most flexible:

1. 1Parallelization. Several model calls work at the same time and a program combines the results. It has two variants: sectioning (independent subtasks defined in advance, for example one call handles the query while another screens it) and voting (the same task run several times to compare, for example several reviewers hunting for vulnerabilities in the same code). You define the subtasks.
2. 2Orchestrator-workers. A central model breaks the task down, delegates it to worker models and synthesizes the results. The key difference from the previous pattern, according to the guide, is that the subtasks are not predefined: the orchestrator decides them based on the input. It is the pattern for code changes that touch many files or for research across many sources.
3. 3Evaluator-optimizer. One call produces and another evaluates and gives feedback, in a loop. It works when there are clear evaluation criteria, such as a translation where an evaluator points out nuances the translator missed.

When we say "many agents at once" we almost always mean the second pattern, with a bit of the third at the end. Anthropic uses it in its Research feature; in the June 2025 article explaining how it was built, a lead agent analyzes the question, works out a strategy and spins up three to five subagents in parallel; each one searches on its own and returns findings already filtered, and at the end another agent attaches citations to every claim. It is the division of labor from module 14, one level up: the lead is an agent too.

When is orchestration worth it, and when is it not?

The same guide is blunt: find the simplest solution possible and add complexity only when it demonstrably improves outcomes. Orchestration is the most complex layer in this course, so the question is not "can I?" but "what do I gain?". It is worth it when at least one of these conditions holds:

• The work splits into independent pieces. Three competitors to research, five sections to write, twenty files to migrate. Each piece can be finished without knowing how the others are going.
• There is more breadth than depth. The research-system article says breadth-first questions (many directions at once) gain the most, along with tasks whose information does not fit in a single context window.
• You need to isolate context. Each worker reads a lot and returns little: the orchestrator receives three paragraphs instead of fifty files and keeps its context for deciding and integrating. It is the context engineering from module 12 applied across several agents.

And when not. Tightly coupled tasks: the research article says the pattern is a poor fit for domains where all agents need the same context or where there are many dependencies between them, and gives coding as the example, with fewer truly parallelizable tasks than research. Anthropic’s February 2026 experiment, in which sixteen agents wrote a C compiler in parallel, confirmed it: while the task was a single one (compiling the Linux kernel), every agent hit the same bug, fixed it and overwrote the others; the work had to be split before parallelism helped. Small jobs: orchestrating ten minutes of work costs more than doing it. When coordination costs more than it saves: if writing briefs and untangling collisions takes longer than a single session would have, it was a single session.

Tokens multiply. Anthropic estimated that an agent uses about four times the tokens of a chat, and a multi-agent system about fifteen times; its conclusion is that this only pays off for tasks valuable enough to cover that cost. The Claude Code documentation confirms it: each subagent spends tokens of its own against the same limit on your plan. The figure that offsets it, from the same article: in Anthropic’s internal evaluation, the multi-agent system (Claude Opus 4 as lead, Sonnet 4 as workers) outperformed a single agent by 90.2%, and token usage alone explained 80% of the difference. In other words, you win because you spend more, not in spite of it.

How do I orchestrate in practice with Claude Code?

Claude Code brings the parts; you bring the method. Five things, in order:

1. 1A written, shared brief. Every subagent starts with an empty context: it does not see your conversation or the files Claude already read; it receives the project’s CLAUDE.md (except for the Explore and Plan subagents) and a delegation message, and works from there. A rule you only said in conversation has to be restated there. The lesson from the research system: vague delegation produced duplicated work, and what fixed it was giving each subagent an objective, an output format, guidance on tools and clear boundaries. That is the specification from module 17, written once and shared.
2. 2Subagents in parallel. Ask for it explicitly: "research A, B and C in parallel using separate subagents". It works best when the paths do not depend on each other; by default a session accepts up to twenty subagents at once. Each returns a summary, and many detailed summaries also fill your context: ask for short, formatted outputs.
3. 3In the background. Ctrl+B sends a running task to the background and you keep working; /tasks lists what is running and opens a transcript. If a background subagent needs a permission, the prompt appears in your session with the name of the one asking. Its results arrive as a notification in a later turn.
4. 4Each worker owns its files. The simplest rule against collisions: every worker owns different files and nobody touches anyone else’s. For sessions you run yourself, Git worktrees (claude --worktree name) give each one its own copy of the repository; /batch splits one large change across 5 to 30 subagents, each in its own worktree; and agent view (claude agents, a research preview as of October 2026) shows background sessions on one screen.
5. 5A review pass in a fresh context. The best-practices documentation says it directly: a fresh context improves review because Claude is not biased toward code it just wrote. Two ways: one session writes and another reviews a named file against named criteria, or a reviewer subagent that sees only the diff and the plan. The official example: confirm every requirement is implemented and the edge cases have tests, check that nothing outside the scope changed, and report gaps, not style preferences. A warning from the same page: a reviewer asked for gaps will usually find some even when the work is sound; tell it to flag only what affects correctness or the stated requirements.

Why is the orchestrator’s job verification?

Because workers make mistakes and report them confidently. The Claude Code documentation explains it: Claude stops when the work looks done, and without a check it can run, "looks done" is the only signal it has. A subagent comes back with "done, tested and working", and that summary is text, not evidence. That is why the same page recommends asking for evidence, not assertions: the test output, the command it ran and what it returned.

So the orchestrator’s job, when deliveries arrive, is the verification from module 9 applied to agent output: facts are checked against the source (you open the link), code against the automated tests and the build (you run them; you do not trust the summary), scope against the brief (did it touch only its files?) and claims about the project against the project itself (if a worker says "the repository has X", you open the repository). Only after that does the piece get integrated. The author of the C compiler put it this way: it is easy to see tests pass and assume the job is done, when that is rarely the case.

In the 4D framework, this is discernment and diligence concentrated at one point. The orchestrator does not forward deliveries: it answers for the whole. If you delegate the verification too, you did not orchestrate anything; you only multiplied the places where it can fail.

I want to do this work with several agents in parallel: [DESCRIBE THE WORK IN 3 TO 5 SENTENCES: what has to be produced, from which sources or files, and how we know it came out right].

Before proposing anything, tell me honestly whether this work deserves several agents or whether a single session would do it better, and why (independent or coupled pieces, size, coordination cost).

If it is worth it, give me the plan in this format:
1. The independent pieces, one per worker, each with a name. At most [NUMBER] workers. If two pieces depend on each other, they go to the same worker or run in sequence.
2. For each piece: which files it owns (nobody else touches them), what it receives as input, what it returns and in what exact format.
3. The shared brief every worker receives (minimum context, rules, what they must never do).
4. The integration plan: in what order I merge the pieces and which command or test I run after each one.
5. The review plan: what a reviewer in a fresh context checks, and what I verify myself against sources or code before integrating.

Do not launch any subagent yet: show me the plan and wait for my approval.

I am going to launch [NUMBER] subagents in parallel for [WORK]. Each one will produce [WHAT: for example, one section, one report per competitor, one file]. Write the shared brief they will all receive. Remember that a subagent does not see this conversation: everything it needs has to be in the brief.

Include, in this order:
1. The goal of the whole job in two sentences, and who it is for.
2. Minimum context: [PASTE OR SUMMARIZE WHAT EVERYONE MUST KNOW: the business, the audience, the tone, the allowed sources].
3. Quality and facts rules: what gets verified, what gets cited, what is left out if it cannot be confirmed, what is never invented.
4. The exact output format, with a short example.
5. File ownership: each worker writes only to the file assigned to it and edits no other.
6. An effort rule: how many sources or files to check at most, and when to stop.
7. What to return when done: the result, the list of sources or files consulted, and an explicit list of what it could not verify.

After the brief, write the individual delegation message for worker 1 as an example: the brief plus its piece, its file and its limits.

Act as a reviewer in a fresh context. You did not take part in the work and you must not improve it: your job is to find what does not hold up.

You will receive three things: the BRIEF the worker received, its DELIVERY, and the SOURCES or files it says it used.

1. Split the delivery into verifiable claims (facts, figures, names, descriptions of how something works, statements that something was tested).
2. For each claim, look for support in the SOURCES or files. Classify it as SUPPORTED (exact quote or file), NOT SUPPORTED (the source says something else) or NO SOURCE (it appears in nothing that was handed over).
3. Compare the delivery with the BRIEF: format, scope, files touched, rules it had to follow. Report every deviation.
4. If the delivery says "tested", "verified" or "works", mark it NO SOURCE unless it includes the output of the command or the test.

Return a table with claim, classification and evidence, and at the end the list of what I must verify personally before integrating. Report gaps, not style preferences.

BRIEF:
[PASTE THE BRIEF]

DELIVERY:
[PASTE THE DELIVERY]

SOURCES:
[PASTE THE SOURCES, THE LINKS OR THE FILE PATHS]

So far you have used agents other people built. The next module switches sides: Building with the API and the Agent SDK, where the model, the tools and the loop from module 16 become code of your own, with a first agent for your business.