Multi-Agent Orchestration

Official Exam Guide Objectives

Task 1.2: Orchestrate multi-agent systems with coordinator-subagent patterns.

Knowledge of

• Hub-and-spoke architecture where a coordinator agent manages all inter-subagent communication, error handling, and information routing
• How subagents operate with isolated context—they do not inherit the coordinator's conversation history automatically
• The role of the coordinator in task decomposition, delegation, result aggregation, and deciding which subagents to invoke based on query complexity
• Risks of overly narrow task decomposition by the coordinator, leading to incomplete coverage of broad research topics

Skills in

• Designing coordinator agents that analyze query requirements and dynamically select which subagents to invoke rather than always routing through the full pipeline
• Partitioning research scope across subagents to minimize duplication (e.g., assigning distinct subtopics or source types to each agent)
• Implementing iterative refinement loops where the coordinator evaluates synthesis output for gaps, re-delegates to search and analysis subagents with targeted queries, and re-invokes synthesis until coverage is sufficient
• Routing all subagent communication through the coordinator for observability, consistent error handling, and controlled information flow

What You Need to Know

Multi-agent orchestration is how several Claude agents work on one task that a single loop cannot carry. The exam is not open-minded about the shape this takes: it tests one topology — hub-and-spoke, coordinator at the centre — and treats departures from it as wrong answers.

Hub-and-Spoke Architecture

Two roles, and the asymmetry between them is the design:

• Coordinator agent: sits at the centre. Receives the initial task, decomposes it, decides which subagents to invoke, passes context to them, aggregates their results, handles errors, and routes information between them.
• Subagents: the spokes. Each one handles a specialised task (web search, document analysis, synthesis, report generation). They receive instructions from the coordinator and return results to it.

The cardinal rule: ALL communication flows through the coordinator. Subagents never communicate directly with each other. Not to save a round trip, not because two of them plainly want the same data, not under load. The instant one spoke addresses another, the topology is a mesh, and the guarantees below stop holding.

Routing everything through one component is what purchases the three properties the exam keeps returning to:

1. Observability — one component sees every exchange, so a single log reconstructs the whole run. Across a mesh you would be stitching the story together from fragments each participant happened to keep.
2. Consistent error handling — recovery policy lives in one place, so a failing subagent is retried, replaced or escalated identically no matter which one failed.
3. Controlled information flow — the coordinator chooses what reaches each subagent, which is what stops one of them accumulating context it has no business holding.

The Critical Isolation Principle

This is the idea candidates most consistently misread, and the exam builds questions on the misreading.

Subagents do NOT automatically inherit the coordinator's conversation history. A freshly spawned subagent begins with the contents of its own prompt and nothing besides. It cannot reach:

• The coordinator's system prompt (unless explicitly included)
• Previous messages in the coordinator's conversation
• Results from other subagents (unless the coordinator passes them)
• Any "shared memory" or global state

The last item deserves stating flatly: there is no shared store. Not an empty one — none at all. A subagent cannot look something up, because no location exists to look in.

Subagents do NOT share memory between invocations. Invoke the search subagent twice and the second call carries no trace of the first. Every invocation begins cold, so anything the first call discovered survives only if the coordinator retained it and writes it back in.

What follows is that passing context is a deliberate act, performed afresh each time. Where synthesis needs the search results, the coordinator puts them into the synthesis prompt. No configuration exists under which synthesis retrieves them for itself.

Coordinator Responsibilities

The coordinator has four key responsibilities that the exam tests:

1. Dynamic subagent selection. The coordinator reads the incoming request and decides which subagents it genuinely requires. It does NOT push everything down the full pipeline. A plain factual question may want the web search subagent alone; routing it through research, analysis and synthesis as well arrives at the same answer more slowly and for more tokens.

2. Research scope partitioning. With several subagents pointed at one topic, the coordinator hands each a distinct slice so their work does not collide. One takes academic papers, another takes news coverage — give both the same sources and you receive the same findings twice while the unassigned sources stay unread.

3. Iterative refinement loops. The coordinator reads the synthesis, works out what is thin or absent, and issues targeted follow-up work to the search and analysis subagents before running synthesis again. That repeats until coverage holds up. It is a cycle with an inspection step in it, not a conveyor that runs once and reports whatever emerges.

4. Centralised communication routing. Every exchange between subagents is relayed by the coordinator, which is what keeps the run observable, the error policy uniform, and the information each subagent sees under control.

The Narrow Decomposition Failure

This is a specific exam pattern worth recognising on sight. The sample set carries a question (referenced as Q7) in which a coordinator splits "impact of AI on creative industries" into visual-arts subtopics alone, so music, writing and film never appear in the finished report.

Every downstream agent did its job. Search covered its brief thoroughly; synthesis used everything delivered to it. Three whole categories are missing because nobody was ever asked to cover them — and diligence downstream cannot recover a topic that was never in scope.

The generalisation is what to carry into the exam: output that is incomplete in scope rather than in depth points at the decomposition almost every time. Thin treatment of the right subjects is a downstream signal. Absent subjects are a coordinator signal.

Practical Example: Research System Coverage Gap

A multi-agent research system is tasked with "renewable energy technologies." The coordinator decomposes this into "solar panel efficiency" and "wind turbine design." Each subagent produces thorough, well-sourced research on its assigned topic.

The finished report handles solar and wind well and is silent on geothermal, tidal, biomass and nuclear fusion. No component underperformed: each search was thorough inside its brief, and synthesis used everything handed to it.

Which disposes of the three fixes the exam will offer you. Sharper search queries cannot surface a subject nobody searched for. A stronger synthesis agent cannot synthesise material that was never retrieved. Additional subagents produce additional copies of the same two assignments. What is left is the decomposition, which has to span the breadth of the question that was asked.

Deep Dive

Orchestrator-workers: flexibility is the defining trait

Anthropic's own workflow taxonomy gives hub-and-spoke a formal name: orchestrator-workers. "A central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results," and it is "well-suited for complex tasks where you can't predict the subtasks needed." The distinction that matters for the exam is what separates it from the simpler parallelization pattern (sectioning/voting): "the key difference from parallelization is its flexibility—subtasks aren't pre-defined, but determined by the orchestrator." If subtasks are fixed in advance, you have parallelization, not orchestrator-workers. If the coordinator decides subtasks dynamically based on the query, that is orchestrator-workers — exactly what hub-and-spoke coordinator-subagent systems do.

Anthropic's own Research feature is built this way: "our Research system uses a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents that operate in parallel."

Sourcesanthropic.com › building-effective-agentsanthropic.com › multi-agent-research-systemfetched 2026-07-30

The token economics behind "why bother with multi-agent"

Multi-agent systems are not free. "Agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats." That spend has to be justified: "for economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance." The payoff can be large — internally, "a multi-agent system with Claude Opus 4 as the lead agent and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%" on their evaluation, and in a separate analysis "token usage by itself explains 80% of the variance" in performance, with tool-call count and model choice explaining most of the rest.

Sourceanthropic.com › multi-agent-research-systemfetched 2026-07-30

Dynamic subagent selection: scale effort to query complexity

The coordinator's decision on "which subagents to invoke based on query complexity" is not a vague guideline — Anthropic's production prompts embed explicit effort-scaling rules: "simple fact-finding requires just 1 agent with 3-10 tool calls, direct comparisons might need 2-4 subagents with 10-15 calls each, and complex research might use more than 10 subagents." Always routing a simple factual query through a full multi-subagent pipeline wastes the 4x/15x token premium for no accuracy gain.

Sourceanthropic.com › multi-agent-research-systemfetched 2026-07-30

Two levels of parallelization

Sequential subagent work was an identified bottleneck: "early agents executed sequential searches, which was painfully slow." The fix operates at two levels simultaneously: "lead agent spins up 3-5 subagents in parallel" (spoke-level) and, within each subagent, "subagents use 3+ tools in parallel" (tool-level). Combined with parallel tool calling inside each subagent, "these changes cut research time by up to 90% for complex queries."

Sourceanthropic.com › multi-agent-research-systemfetched 2026-07-30

The delegation failure mode: duplicated work from vague task descriptions

Narrow decomposition (missing entire categories) is one coordinator failure mode; vague task descriptions are a distinct second one. "Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information." Anthropic's own postmortem example: "one subagent explored 2021 automotive chip crisis while 2 others duplicated work investigating 2025 supply chains" — three subagents, one topic covered twice, another covered thin. The fix at the prompting layer: "each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries." Scope partitioning (Skills in, above) is how the coordinator prevents this at design time; detailed per-subagent task descriptions are how it prevents this at delegation time.

Sourceanthropic.com › multi-agent-research-systemfetched 2026-07-30

When multi-agent orchestration is the wrong call

Hub-and-spoke coordination is not universally correct. It is a poor fit for "domains that require all agents to share the same context or involve many dependencies." Most coding tasks fall into this trap: "most coding tasks involve fewer truly parallelizable tasks than research." And the pattern assumes coordination skill the model may not reliably have yet: "LLM agents are not yet great at coordinating and delegating to other agents in real time." The pattern earns its token cost specifically for "tasks that involve heavy parallelization, information exceeding single context windows, complex tools" — breadth-first research being the canonical case.

Sourceanthropic.com › multi-agent-research-systemfetched 2026-07-30

Quick Reference

Exam Traps

Practice Scenario

Build Exercise

Build a Hub-and-Spoke Research Coordinator

Difficulty: Intermediate (2/4)

60 minutes

1. Create a coordinator agent that accepts a broad research topic as input

Why: The coordinator is the central hub in hub-and-spoke architecture. The exam tests whether you understand that the coordinator owns task decomposition, subagent selection, and result aggregation — not the subagents.

You should see: A coordinator function that accepts a topic string and returns a structured research report. It should have a system prompt defining its role as the orchestrating hub.

2. Implement task decomposition logic that breaks the topic into at least 5 distinct subtopics covering the full breadth of the subject

Why: Narrow decomposition is a specific exam failure pattern. The coordinator that only assigns solar and wind for renewable energy misses entire categories. The exam expects you to recognise that incomplete output traces back to the coordinator decomposition.

You should see: A decomposition function that produces 5 or more subtopics for any broad topic. For renewable energy, it should cover solar, wind, geothermal, tidal, biomass, and fusion at minimum.

3. Spawn two subagents (web search and document analysis) with explicit context passing — include all relevant information in each subagent prompt

Why: Subagent isolation means no shared memory and no inherited context. The exam heavily tests this: if a subagent produces poor results, check whether the coordinator gave it sufficient context, not whether the subagent itself is flawed.

You should see: Two subagent invocations where each receives the full assigned subtopic, the research goal, and any relevant context from prior agents — all explicitly included in the prompt.

4. Aggregate results from both subagents and evaluate coverage completeness

Why: The coordinator must evaluate whether the combined results cover the full breadth of the original topic. This is where iterative refinement starts — gaps detected here trigger re-delegation.

You should see: An aggregation function that combines results from both subagents and produces a coverage assessment listing which subtopics are well-covered, partially covered, or missing.

5. Implement an iterative refinement loop: if the coordinator identifies coverage gaps, re-delegate to subagents with targeted queries and re-invoke until coverage is sufficient

Why: Iterative refinement is a core coordinator responsibility the exam tests. A single-shot delegation is not enough — the coordinator must evaluate output and re-delegate for gaps. This distinguishes a coordinator from a simple dispatcher.

You should see: A loop that checks coverage, identifies gaps, sends targeted follow-up queries to subagents for the missing subtopics, and re-evaluates until a coverage threshold is met or a maximum iteration count is reached.

6. Test with the topic renewable energy technologies and verify that the final output covers solar, wind, geothermal, tidal, biomass, and fusion

Why: This specific test case maps to the exam narrow decomposition failure pattern. If your output only covers solar and wind, the root cause is the coordinator decomposition — the exact diagnostic the exam expects you to make.

You should see: A final research report with substantive sections on all six energy types: solar, wind, geothermal, tidal, biomass, and fusion. The coverage evaluation should show 100% completeness.

Sources

• Claude Agent SDK Overview — Anthropic
• Multi-Agent Research System Scenario (Skilljar) — Anthropic
• Building with Claude API (Skilljar) — Anthropic
• Building Effective Agents — Anthropic
• How we built our multi-agent research system — Anthropic

Appendix A — Build Exercise Step Hints

Progressive hints revealed by the "Stuck? Get a nudge" control on each step.

Step 1. Create a coordinator agent that accepts a broad research topic as input

Why: The coordinator is the central hub in hub-and-spoke architecture. The exam tests whether you understand that the coordinator owns task decomposition, subagent selection, and result aggregation — not the subagents.

You should see: A coordinator function that accepts a topic string and returns a structured research report. It should have a system prompt defining its role as the orchestrating hub.

const coordinator = {
  systemPrompt: "You are a research coordinator. Decompose topics into comprehensive subtopics, delegate to specialist subagents, aggregate results, and identify coverage gaps.",
  subagents: [webSearchAgent, docAnalysisAgent],
  async research(topic: string) {
    const subtopics = await this.decompose(topic);
    // delegation and aggregation follow
  }
};

class Coordinator:
    system_prompt = (
        "You are a research coordinator. Decompose topics into comprehensive "
        "subtopics, delegate to specialist subagents, aggregate results, and "
        "identify coverage gaps."
    )

    def __init__(self):
        self.subagents = [WEB_SEARCH_AGENT, DOC_ANALYSIS_AGENT]

    def research(self, topic: str):
        subtopics = self.decompose(topic)
        # delegation and aggregation follow

Step 2. Implement task decomposition logic that breaks the topic into at least 5 distinct subtopics covering the full breadth of the subject

Why: Narrow decomposition is a specific exam failure pattern. The coordinator that only assigns solar and wind for renewable energy misses entire categories. The exam expects you to recognise that incomplete output traces back to the coordinator decomposition.

You should see: A decomposition function that produces 5 or more subtopics for any broad topic. For renewable energy, it should cover solar, wind, geothermal, tidal, biomass, and fusion at minimum.

// A method on the coordinator object from step 1.
const coordinator = {
  async decompose(topic: string): Promise<string[]> {
    const response = await client.messages.create({
      model: "claude-sonnet-5",
      max_tokens: 1024,
      messages: [{
        role: "user",
        content: `List ALL major subtopics for: ${topic}. Ensure comprehensive breadth — missing an entire category is a critical failure. Return as JSON array.`
      }]
    });
    // content is a union of block types — narrow before reading .text.
    const text = response.content.find(b => b.type === "text");
    return JSON.parse(text?.text ?? "[]");
  },
};

class Coordinator:  # continued from step 1
    def decompose(self, topic: str) -> list[str]:
        response = client.messages.create(
            model="claude-sonnet-5",
            max_tokens=1024,
            messages=[
                {
                    "role": "user",
                    "content": (
                        f"List ALL major subtopics for: {topic}. Ensure comprehensive "
                        "breadth — missing an entire category is a critical failure. "
                        "Return as JSON array."
                    ),
                }
            ],
        )
        # content is a list of block types — pick the text block before parsing.
        text = next((b.text for b in response.content if b.type == "text"), "[]")
        return json.loads(text)

Step 3. Spawn two subagents (web search and document analysis) with explicit context passing — include all relevant information in each subagent prompt

Why: Subagent isolation means no shared memory and no inherited context. The exam heavily tests this: if a subagent produces poor results, check whether the coordinator gave it sufficient context, not whether the subagent itself is flawed.

You should see: Two subagent invocations where each receives the full assigned subtopic, the research goal, and any relevant context from prior agents — all explicitly included in the prompt.

// A method on the coordinator object from step 1.
const coordinator = {
  async delegateToSubagent(agent: AgentDefinition, subtopic: string, context: string) {
    return await client.messages.create({
      model: "claude-sonnet-5",
      max_tokens: 2048,
      system: agent.systemPrompt,
      messages: [{
        role: "user",
        content: `Research subtopic: ${subtopic}\nBroader goal: ${context}\nReturn structured findings with source URLs and confidence levels.`
      }]
    });
  },
};

class Coordinator:  # continued from step 1
    def delegate_to_subagent(self, agent: dict, subtopic: str, context: str):
        return client.messages.create(
            model="claude-sonnet-5",
            max_tokens=2048,
            system=agent["system_prompt"],
            messages=[
                {
                    "role": "user",
                    "content": (
                        f"Research subtopic: {subtopic}\n"
                        f"Broader goal: {context}\n"
                        "Return structured findings with source URLs and confidence levels."
                    ),
                }
            ],
        )

Step 4. Aggregate results from both subagents and evaluate coverage completeness

Why: The coordinator must evaluate whether the combined results cover the full breadth of the original topic. This is where iterative refinement starts — gaps detected here trigger re-delegation.

You should see: An aggregation function that combines results from both subagents and produces a coverage assessment listing which subtopics are well-covered, partially covered, or missing.

// A method on the coordinator object from step 1.
const coordinator = {
  async evaluateCoverage(subtopics: string[], results: Finding[]): Promise<CoverageReport> {
    const covered = subtopics.filter(st =>
      results.some(r => r.subtopic === st && r.findings.length > 0)
    );
    const gaps = subtopics.filter(st => !covered.includes(st));
    return { covered, gaps, completeness: covered.length / subtopics.length };
  },
};

class Coordinator:  # continued from step 1
    def evaluate_coverage(self, subtopics: list[str], results: list[dict]) -> dict:
        covered = [
            st
            for st in subtopics
            if any(r["subtopic"] == st and r["findings"] for r in results)
        ]
        gaps = [st for st in subtopics if st not in covered]
        return {
            "covered": covered,
            "gaps": gaps,
            "completeness": len(covered) / len(subtopics),
        }

Step 5. Implement an iterative refinement loop: if the coordinator identifies coverage gaps, re-delegate to subagents with targeted queries and re-invoke until coverage is sufficient

Why: Iterative refinement is a core coordinator responsibility the exam tests. A single-shot delegation is not enough — the coordinator must evaluate output and re-delegate for gaps. This distinguishes a coordinator from a simple dispatcher.

You should see: A loop that checks coverage, identifies gaps, sends targeted follow-up queries to subagents for the missing subtopics, and re-evaluates until a coverage threshold is met or a maximum iteration count is reached.

let coverage = await this.evaluateCoverage(subtopics, allResults);
let iterations = 0;
while (coverage.completeness < 0.9 && iterations < 3) {
  for (const gap of coverage.gaps) {
    const newResults = await this.delegateToSubagent(webSearchAgent, gap, topic);
    allResults.push(...newResults);
  }
  coverage = await this.evaluateCoverage(subtopics, allResults);
  iterations++;
}

coverage = self.evaluate_coverage(subtopics, all_results)
iterations = 0
while coverage["completeness"] < 0.9 and iterations < 3:
    for gap in coverage["gaps"]:
        new_results = self.delegate_to_subagent(WEB_SEARCH_AGENT, gap, topic)
        all_results.extend(new_results)
    coverage = self.evaluate_coverage(subtopics, all_results)
    iterations += 1

Step 6. Test with the topic renewable energy technologies and verify that the final output covers solar, wind, geothermal, tidal, biomass, and fusion

Why: This specific test case maps to the exam narrow decomposition failure pattern. If your output only covers solar and wind, the root cause is the coordinator decomposition — the exact diagnostic the exam expects you to make.

You should see: A final research report with substantive sections on all six energy types: solar, wind, geothermal, tidal, biomass, and fusion. The coverage evaluation should show 100% completeness.

const report = await coordinator.research("renewable energy technologies");
const required = ["solar", "wind", "geothermal", "tidal", "biomass", "fusion"];
const missing = required.filter(cat =>
  !report.sections.some(s => s.topic.toLowerCase().includes(cat))
);
console.log(missing.length === 0 ? "Full coverage" : `Missing: ${missing.join(", ")}`);

report = coordinator.research("renewable energy technologies")
required = ["solar", "wind", "geothermal", "tidal", "biomass", "fusion"]
missing = [
    cat
    for cat in required
    if not any(cat in s["topic"].lower() for s in report["sections"])
]
print("Full coverage" if not missing else f"Missing: {', '.join(missing)}")

Appendix B — Interactive Study Prompts

Two prompts to paste into Claude. B1 drills the judgement the exam actually measures; B3 reviews the code you wrote for the Build Exercise above. The exam simulator between them is the interactive quiz on this page.

B1. Concept Check — Discrimination Drill

B2. Exam Simulator

B3. Build Coach — Code Review

The Build Exercise and its hint ladder are already on this page. This prompt is for the one thing the page cannot do: review the code you actually wrote.