Home › Study guides › CCAR-F › Domain 1 › Lesson 1.2

CCAR-F · Domain 1 · 27% of the exam · Lesson 1.2 · 19 min read

Multi-agent orchestration: the coordinator and its subagents

How a coordinator splits a research question, routes all messages through itself, briefs subagents that start blank, and loops until coverage is complete.

Written against task statement 1.2 of the official CCAR-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

1.2.1 Why one agent cannot research a big question alone

Imagine a client asks your team for a report on how electric vehicles (EVs) are changing the economy. You would not hand the whole thing to one person. One colleague gathers sources, another reads the long industry reports, a third pulls the findings together, and someone writes it up. And one person, an editor, owns the question: hands out the pieces, reads what comes back, and sends people back out when something is missing.

A single agent can try to do all of that in one conversation, and for a small question it will manage. For a broad one it hits a wall. Everything an agent works with sits in its context window, the text the model can take into account at once: its working memory. Every search result, every page read and every draft paragraph lands in that one window. As it fills, the model's accuracy and recall degrade, so quality falls exactly when the task gets interesting.

The answer is to give the agent colleagues. A coordinator is an agent whose tools include starting other agents. The agents it starts are subagents: separate agents, each with its own instructions, its own tools and a fresh context window. Anthropic's engineering writing calls this the orchestrator-workers pattern; the exam calls the orchestrator the coordinator. This lesson follows one research system for that client, with four subagents: search, analysis, synthesis and report.

1.2.2 Hub and spoke: every message passes through the coordinator

The coordinator has four jobs on every run, and each rule in this lesson protects one of them.

1. DECOMPOSE. Break the request into subtasks: which areas to research, which documents to read.
2. DELEGATE. Start the right subagent for each subtask, with a written brief.
3. AGGREGATE. Collect each result, check it, and pass on what the next subagent needs.
4. DECIDE. Judge whether the work so far answers the question, and what happens next.

Now the first design question, and the exam likes it: when the search subagent finds something the analysis subagent needs, do they talk to each other? The tempting answer is yes; it looks efficient. The right answer is no. The search subagent returns its sources to the coordinator, which decides what the analysis subagent gets. This is the hub-and-spoke architecture: the coordinator is the hub, the subagents are the spokes, and spokes never talk to each other.

Why insist on this when a direct link would save a hop? Three reasons. Observability: when every message passes through one place, one log shows the whole run, who was briefed with what and what each returned. Consistent error handling: if the search subagent fails or returns nonsense, the coordinator sees it and applies the same rule every time (retry, rebrief or carry on without it). Controlled information flow: the coordinator decides what each subagent sees, so synthesis gets checked findings rather than every raw page the search turned up.

Think of an air traffic controller. Pilots do not negotiate with each other about who lands first; each talks to the tower, and the tower holds the whole picture. Hub and spoke is a design choice, not a technical limit: some agent tools do let agents message each other directly. You keep the spokes apart because any side channel gives up all three benefits at once.

1.2.3 Subagents know only what the brief says: isolated context

Now the question behind the most surprising bugs. The coordinator has spent twenty turns on the client's request and has noted that the client cares most about jobs and the power grid. It starts a search subagent with the brief "search for the angles we discussed". The subagent comes back with generic results, because it has no idea what was discussed.

Subagents run with isolated context. Each one starts in a fresh context window holding its own system prompt (its standing instructions) and its own list of tools. It does not inherit the coordinator's conversation history, the pages the coordinator has read, or the coordinator's system prompt. The only thing that passes from coordinator to subagent is the brief: the prompt the coordinator writes when it starts the subagent. The Claude Agent SDK (software development kit) documentation is blunt about it: anything the subagent needs, from decisions to file paths, goes directly into that prompt.

Picture briefing a freelancer by email. They sat in none of your meetings; whatever the email does not say, they do not know. The precise statement: nothing from the coordinator's conversation reaches a subagent unless the coordinator writes it into the brief.

The middle column is where the bugs come from. The right-hand column matters as much, because isolation is not only a limitation; it is the point. A search subagent may run thirty searches and read forty pages, and all of that stays in its own window; the coordinator receives one final message. That is how a multi-agent system researches far more than one context window could hold.

So the brief has to be complete. Anthropic's research team found that vague briefs made subagents duplicate work, leave gaps or miss what they were sent to find. Their conclusion: each subagent needs an objective, an output format, guidance on which tools and sources to use, and clear task boundaries. For our search subagent that means one brief with the exact question, the area it owns, what to return, and what NOT to cover because another subagent has it.

1.2.4 The coordinator chooses who works: dynamic selection

Here is a failure that looks like diligence. A team wires the four subagents into a fixed chain: every request runs search, then analysis, then synthesis, then report. Someone asks "how many electric cars were sold in Norway last year?" The system launches four agents, reads a dozen documents and writes a two-page report to deliver one number. Cost and waiting time go up, and the answer is no better.

The coordinator's first job on every request is to analyse what the query needs and dynamically select which subagents to invoke. That is what separates this pattern from a fixed pipeline: the subtasks are not set in advance; the coordinator decides them from the specific input.

Anthropic's own research system gives its lead agent explicit scaling rules: one agent and a handful of tool calls for simple fact-finding, a few subagents for a comparison, more than ten for complex research. The numbers are not exam material; the principle is. Effort scales with query complexity, so the Norway question gets one search, while the client's question gets the full set with several searches in parallel. Selection cuts both ways: early versions of that lead agent spawned 50 subagents for simple queries.

How does the coordinator know which subagent fits? Each subagent carries a description that says when to use it, and Claude matches the work to those descriptions. The coordinator asks for a subagent by calling a tool, and the SDK starts that subagent. In the Agent SDK that tool is called Agent; older versions, and the exam, call it Task. A vague description gets picked badly or not at all. If the report subagent's description reads "writes the final cited report from a completed synthesis", the coordinator can see that a one-number question does not need it.

1.2.5 Partition the scope, and cover all of it

Suppose the coordinator has rightly decided the client's question needs several search subagents. It starts three of them with the same brief: "research how EVs are changing the economy". All three run much the same searches and return much the same sources, and the coordinator pays three times for one result. The fix is to partition the research scope: give each subagent a distinct slice, so their work adds up instead of overlapping.

Subtopic and source type are the two splits to know by name; time and region are the same idea along another axis. Pick the split that fits the question. What never works is several subagents with the same brief, or briefs so vague that they drift into the same corner.

Now the failure this task statement singles out: decomposition that is too narrow. The coordinator reads "electric vehicles", thinks of car companies, and splits the work into three subtasks: EV sales by brand, car makers' factory investment, and EV prices against petrol cars. Each subagent does a fine job. The synthesis is coherent, well cited and confident. It is also incomplete, because it says nothing about power grids, mining or fuel stations.

Notice where the fault sits. Every subagent covered its brief completely; the briefs were the problem. So when every subagent reports success and the report still misses whole areas, read the coordinator's list of subtasks before you blame search, analysis or synthesis. A narrow decomposition is more dangerous than a sloppy one, because it produces a polished answer to a smaller question than the one asked. It is like sending every surveyor to the same district: you get a beautiful, detailed map, and it is not a map of the city.

The defence is to decompose against the FULL breadth of the question before delegating. First list the areas a complete answer must cover, then partition those areas among subagents. Partitioning decides who covers what; breadth decides whether everything is covered at all.

1.2.6 The refinement loop: evaluate, re-delegate, re-synthesise

So far the coordinator has been a good dispatcher. What makes it a good editor is what it does when the synthesis comes back. The weak design sends the first synthesis straight to the report subagent. The strong design treats it as a draft and asks one question of it: does this cover the whole question?

That is the iterative refinement loop. The coordinator delegates search and analysis, invokes synthesis, then evaluates the synthesis for gaps: areas with no findings, claims with no source, conflicts left unresolved. If it finds a gap, it does not rerun the whole pipeline. It re-delegates to the search and analysis subagents with targeted briefs that name the missing area, then re-invokes synthesis so the new findings merge with the old. The loop repeats until coverage is sufficient, and only then does the report subagent run.

Watch the loop rescue our narrow decomposition. The first synthesis is all about car makers. The coordinator checks it against the client's original question, not against its own first plan, and asks where the grid, mining and fuel effects are. They are nowhere. It starts three new search subagents, one per missing area, each told what to find and what is already covered. The analysis subagent reads the new sources, synthesis runs again over old and new findings, and the second synthesis covers the whole question.

Two details make the loop work. The re-delegation must be targeted: "find what is missing" is useless to a subagent that never saw the synthesis, so the coordinator names the gap ("EVs and power grids: charging demand, grid upgrades, peak load"). And the coordinator must evaluate rather than trust. Anthropic describes its lead agent synthesising results and then deciding whether more research is needed, creating additional subagents if so. The word "deciding" is the whole loop.

1.2.7 The exam traps

Every mistake in this lesson is the coordinator giving up one of its jobs: routing, briefing, selecting, partitioning or checking.

• ✗ Letting subagents pass results to each other directly. ✓ Route everything through the coordinator. A side channel loses the single log, the single error policy and control over what each subagent sees.
• ✗ Assuming a subagent knows what the coordinator has read or decided. ✓ Put everything the subagent needs into its brief. Subagents start in a fresh context and inherit nothing from the coordinator's history.
• ✗ Running the full search-analysis-synthesis-report pipeline on every request. ✓ Have the coordinator analyse the query and select the subagents it needs. A one-number question does not need a report subagent.
• ✗ Starting several subagents with the same or overlapping briefs. ✓ Partition the scope by subtopic or source type so each subagent owns a distinct slice.
• ✗ Decomposing narrowly, then blaming the subagents for the gaps. ✓ Map the full breadth of the question before delegating. Subagents that complete their briefs cannot cover areas nobody assigned; car makers alone are not the economy.
• ✗ Sending the first synthesis straight to the report subagent. ✓ Evaluate it for gaps, re-delegate with targeted briefs, and re-synthesise until coverage is sufficient.

1.2.8 Put it together: orchestrate a research run and break it

You now have the coordinator's whole job. It routes every message, writes complete briefs, selects subagents per query, partitions scope against the full question, and loops on the synthesis until the question is covered. The best way to feel why each job matters is to build a small version and then take one job away at a time.

The rest of Domain 1 builds on this coordinator. Configuring subagent invocation (1.3) is about the spawning tool call itself: how each subagent is defined, what goes into the brief, and how to start several at once. Workflow enforcement (1.4) is how you guarantee, rather than hope, that the report subagent never runs before a synthesis has passed the gap check. Task decomposition (1.6) turns "decompose against the full breadth" into a method, and sessions (1.7) let a long research run pause and resume.

Key takeaways

• ✓ A coordinator is an agent that starts other agents: it decomposes the request, delegates to subagents, aggregates their results and decides what happens next.
• ✓ In hub and spoke, all communication, error handling and information routing pass through the coordinator, giving one log, one error policy and one point of control.
• ✓ Subagents run in isolated context and inherit nothing from the coordinator's history, so the brief must carry everything they need, and only their final result comes back.
• ✓ The coordinator selects which subagents to invoke from the query's complexity instead of running the full pipeline every time.
• ✓ Partition scope across subagents by subtopic or source type so that no two do the same work.
• ✓ An overly narrow decomposition is the quiet failure: every subagent succeeds, yet the polished report answers a smaller question than the one asked.
• ✓ The refinement loop evaluates the synthesis for gaps, re-delegates to search and analysis with targeted briefs, and re-synthesises before anything is reported.

Check your understanding

4 questions written for this lesson, then one from the CCAR-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• How we built our multi-agent research system
• Subagents in the Agent SDK
• Claude Code subagents
• Building effective agents
• Context windows
• The CCAR-F exam guide, summarised