CertSafari
    Anthropic Claude Certified Architect – Professional (CCAR-P)· Lessons

    Domain 1 · Lesson 4/38

    Multi-Agent System Design: When to Split and How to Decompose

    Design multi-agent systems and orchestration strategies

    10 min read
    2.83% of exam
    7 sources
    Published 4 Oct 2026
    Docs as of 30 Sep 2026

    What you will be able to do

    • Decide whether a requirement justifies several agents or is better served by one well-equipped agent
    • Describe the coordinator–subagent shape and what isolated context does and does not share
    • Decompose a complex task into well-briefed, right-sized subtasks
    • Explain how multi-agent design choices affect cost, latency, quality and maintenance

    Key concept

    Context-isolated subagents under a coordinator — A multi-agent system gives each agent its own conversation history. A coordinator hands out work and combines the results. Most of the benefits and most of the costs come from this isolation.

    1.Start with one agent and split only when you have a reason

    Anthropic separates two kinds of agentic system. In a workflow, LLMs and tools follow code paths that someone wrote in advance. In an agent, the LLM directs its own process and decides which tools to use. A multi-agent system is a set of agents of the second kind: several LLM instances, each with its own conversation context, coordinated through code. That gives you the option to split the work across agents. It does not mean you should. Anthropic reports that teams spent months building elaborate multi-agent architectures, then found that better prompting on a single agent got the same results. Their advice is that a well-designed single agent with the right tools can do far more than many developers expect.

    Because of that overhead, multi-agent designs should be kept for problems a single agent cannot handle. Anthropic names three situations where several agents consistently beat one: context pollution is degrading performance, the tasks can run in parallel, or specialization improves tool selection or focus. The Managed Agents documentation makes the same point in platform terms. Multiagent coordination is best suited for complex tasks that either span a variety of surfaces or break into multiple well-scoped tasks that contribute to an overall goal. The blog gives a context-pollution example. A support agent has to look up order history while it diagnoses a technical fault. Each lookup adds thousands of tokens the diagnosis doesn't need, which dilutes the agent's attention. Moving the lookups into a subagent keeps the diagnosing context clean.

    Checkpoint 1 of 6· Check yourself

    A team plans to split its single support agent into separate planning, execution, review and iteration agents 'for cleanliness'. No subtask runs in parallel, the context stays small, and every agent would use the same tools. What does the guidance recommend?

    Sources123

    2.The coordinator pattern and isolated context

    Agents can be coordinated in several ways. The simplest to reason about is the orchestrator–subagent pattern, a hierarchy in which a lead agent spawns and manages specialised subagents for specific subtasks. Claude Managed Agents calls the lead the *coordinator*. All agents in a session share the same sandbox, filesystem and vault credentials. Each one still runs in its own session thread with its own conversation history, and each has its own model, system prompt, tools, MCP servers and skills. Threads are persistent, so the coordinator can send a follow-up to an agent it called earlier and that agent still has all of its previous turns.

    The Agent SDK describes the same isolation from the parent's side. A subagent can read dozens of files, but its intermediate tool calls and results stay inside the subagent, and only its final message comes back. The parent gets a short summary instead of everything the subagent read. That is what keeps the coordinator's context clean, and it is also why a subagent can't rely on anything the coordinator knows unless the coordinator puts it in the brief.

    Coordination patterns that the Managed Agents documentation says work well
    PatternWhat the coordinator doesWhy
    ParallelizationFans out independent subtasks (searching multiple sources, analysing separate files) and synthesises the resultsIndependent work runs at the same time
    SpecializationRoutes to agents with domain-focused system prompts and tools, such as a security agent or a documentation agentAvoids loading a single agent with every capability
    EscalationConsults a more capable agent or model for a subset of complex subtasksUses stronger reasoning only where it is needed

    A fan-out can take two shapes. Sectioning splits a task into independent subtasks that run in parallel. Voting runs the same task several times to get a range of outputs, which helps when you need more confidence in the result. In both cases the coordinator collects the outputs and combines them.

    Checkpoint 2 of 6· Check yourself

    A research subagent reads 40 files while answering a question for its parent agent. What ends up in the parent's context?

    Checkpoint 3 of 6· Exam question

    A code-review agent needs to investigate dozens of files to find the root cause of a bug, but you want to keep that investigation's file contents and intermediate reasoning out of the main conversation's context window, receiving only a concise final finding. Which capability best fits this need?

    Sources2341

    3.Decomposing the task and briefing each subagent

    A subagent doesn't see the coordinator's context, so the quality of its work depends on its brief. In Anthropic's multi-agent research system, the lead agent breaks each query into subtasks and describes them to subagents. They found that every subagent needs four things: an objective, an output format, guidance on which tools and sources to use, and clear task boundaries. Early on, the lead agent gave short, vague instructions. The result was two subagents investigating the same supply-chain question while a third covered a different period, with no real division of labour.

    Size matters as well. Claude Code's agent-teams guidance describes three cases. Tasks that are too small cost more in coordination overhead than they gain. Tasks that are too large keep an agent working too long without check-ins, which raises the risk of wasted effort. Tasks that are just right are self-contained units with a clear deliverable, such as a function, a test file or a review. A good decomposition produces pieces that are well-scoped by the Managed Agents definition: each can be finished independently and each contributes to the overall goal, so the coordinator can combine the results.

    Checkpoint 4 of 6· Check yourself

    A lead agent sends three subagents the instruction 'research the semiconductor shortage'. Two of them return nearly identical findings. What is the most direct fix?

    Checkpoint 5 of 6· Exam question

    During a PR review you want a style-checker, a security-scanner, and a test-coverage subagent to each analyze the same pull request, with all three finishing in roughly the time of the slowest one rather than the sum of all three. What should you do?

    Sources56

    4.Mapping the design to cost, latency, quality and maintenance

    Each benefit of a multi-agent design comes with a cost, and a solution design should name both. Quality: working in parallel with isolated context helps improve output quality. Latency: when subagents run concurrently, independent subtasks finish in the time of the slowest one, not the sum of all of them. Managed Agents says the same: this setup can also improve time to completion. Cost: token use scales linearly, because each agent has its own context window and consumes tokens independently. You can lower cost by routing simple subtasks to faster, cheaper models such as Haiku, and keeping the most capable model for the parts of the work that need it, which is the escalation pattern.

    Scaling up has limits. As you add agents, coordination overhead grows: more communication, more task coordination, and more chances of conflict. Past a certain point, extra agents don't make the work proportionally faster. Maintenance and time to market matter too. Each additional agent is another possible point of failure, another set of prompts to maintain, and another source of unexpected behaviour.

    Checkpoint 6 of 6· Check yourself

    A coordinator running on a top-tier model sends many read-only codebase searches to subagents. The business wants lower cost without hurting the final answer. Which change fits the guidance?

    Sources3462

    Exam traps

    Each one states something that sounds right. Open it to see what is actually true.

    1. 1.A subagent automatically inherits the coordinator's tools, MCP servers and conversation context.Why is that wrong?

      In Managed Agents, each agent has its own configuration and conversation history, and tools, MCP servers and context are not shared. The shared parts are the sandbox, the filesystem and the vault credentials.

      Covered in The coordinator pattern and isolated context

    2. 2.Doubling the number of agents roughly halves the time to completion.Why is that wrong?

      Coordination overhead grows with each agent and returns diminish, while token cost keeps rising linearly.

      Covered in Mapping the design to cost, latency, quality and maintenance

    Sources

    Every claim above is drawn from one of these pages, quoted as it was written on the date shown.

    1. 1.
      “Workflows are systems where LLMs and tools are orchestrated through predefined code paths.”
      ↩︎ Start with one agent and split only when you have a reason
      “systems where LLMs dynamically direct their own processes and tool usage”
      ↩︎ Start with one agent and split only when you have a reason
      “Sectioning: Breaking a task into independent subtasks run in parallel.”
      ↩︎ The coordinator pattern and isolated context
      “Voting: Running the same task multiple times to get diverse outputs.”
      ↩︎ The coordinator pattern and isolated context
    2. 2.
      “multiple LLM instances run with separate conversation contexts, coordinated through code”
      ↩︎ Start with one agent and split only when you have a reason
      “teams invest months building elaborate multi-agent architectures only to discover that improved prompting on a single agent achieved equivalent results”
      ↩︎ Start with one agent and split only when you have a reason
      “a hierarchical model where a lead agent spawns and manages specialized subagents for specific subtasks”
      ↩︎ The coordinator pattern and isolated context
      “Every additional agent represents another potential point of failure, another set of prompts to maintain, and another source of unexpected behavior.”
      ↩︎ Mapping the design to cost, latency, quality and maintenance
      “In our testing, multi-agent implementations typically use 3-10x more tokens than single-agent approaches for equivalent tasks.”
      ↩︎ Prediction
      “when context pollution degrades performance, when tasks can run in parallel, and when specialization improves tool selection or task focus”
      ↩︎ Checkpoint
    3. 3.
      “where multiple well-scoped tasks contribute to an overall goal”
      ↩︎ Start with one agent and split only when you have a reason
      “All agents share the same sandbox, filesystem, and vault credentials”
      ↩︎ The coordinator pattern and isolated context
      “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.”
      ↩︎ The coordinator pattern and isolated context
      “Agents can act in parallel with their own isolated context, which helps improve output quality and can also improve time to completion.”
      ↩︎ Mapping the design to cost, latency, quality and maintenance
      “each agent runs in its own session thread, a context-isolated event stream with its own conversation history”
      ↩︎ Key concept
      “Tools, MCP servers, and context are not shared.”
      ↩︎ Exam trap 1
    4. 4.
      “The parent receives a concise summary, not every file the subagent read.”
      ↩︎ The coordinator pattern and isolated context
      “so independent subtasks finish in the time of the slowest one rather than the sum of all of them”
      ↩︎ Mapping the design to cost, latency, quality and maintenance
      “intermediate tool calls and results stay inside the subagent; only its final message returns to the parent.”
      ↩︎ Checkpoint
    5. 5.
      “the lead agent decomposes queries into subtasks and describes them to subagents”
      ↩︎ Decomposing the task and briefing each subagent
      “Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries.”
      ↩︎ Decomposing the task and briefing each subagent
      “Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information.”
      ↩︎ Checkpoint
    6. 6.
      “Just right: self-contained units that produce a clear deliverable, such as a function, a test file, or a review”
      ↩︎ Decomposing the task and briefing each subagent
      “Too large: teammates work too long without check-ins, increasing risk of wasted effort”
      ↩︎ Decomposing the task and briefing each subagent
      “Token costs scale linearly: each teammate has its own context window and consumes tokens independently.”
      ↩︎ Mapping the design to cost, latency, quality and maintenance
      “Coordination overhead increases: more teammates means more communication, task coordination, and potential for conflicts”
      ↩︎ Exam trap 2

    Also cited

    Continue to page 2 of 2

    Multi-Agent Orchestration in Managed Agents, the Agent SDK and Claude Code

    Spotted a mistake, or was something unclear? Tell us.