Multi Agent System Claude: Production Architecture Guide

Building a multi agent system Claude can actually run in production is harder than the demos suggest. The orchestration loop is straightforward; the failure modes are not. This guide works through the architecture decisions that separate a proof-of-concept from something you can ship: topology selection, permission design, context engineering, error propagation, and the blast-radius controls that keep a misbehaving subagent from taking down the whole pipeline. These are also the patterns that Domain 1 (Agentic Architecture & Orchestration, 27% of the CCAR-F exam) tests most heavily.

What topology should a multi agent system use?

The right topology depends on whether your tasks are homogeneous or heterogeneous, and whether subtasks are independent or sequentially dependent.

The two dominant patterns in Claude deployments are:

For most production use cases, hub-and-spoke architecture is the right starting point. The coordinator holds the goal, decomposes it into subtasks, dispatches subagents, and synthesises results. Subagents receive only the context they need for their slice of work, which limits both token cost and blast radius.

Fixed sequential pipelines (prompt chaining) suit document-processing workflows where each stage transforms a well-defined input into a well-defined output. They are cheaper to operate and easier to debug, but they cannot adapt when a stage produces unexpected output.

Dynamic adaptive decomposition is powerful but expensive. Reserve it for tasks where the coordinator genuinely cannot know the subtask shape until it has inspected the data.

How do you contain blast radius in a multi agent system?

Blast radius is the maximum damage a single misbehaving subagent can cause before a human or a programmatic check intervenes. Containing it is the central safety engineering question for production agents.

Three levers control blast radius:

1. Permission scoping. Each subagent receives only the tools it needs for its task. A research subagent gets read-only web search; it does not get a database write tool. This is the principle of least privilege applied to tool distribution. See tool distribution strategy design for the decision framework.

2. Irreversibility gates. Before any subagent executes an irreversible action (sending an email, writing to a production database, calling a billing API), the coordinator checks whether human approval is required. The CCAR-F exam consistently rewards deterministic, programmatic enforcement for high-stakes actions over prompt-based reminders alone. See high-stakes enforcement decision rule for the exact decision logic.

3. Subagent context isolation. Each subagent runs in its own context window. It cannot read the coordinator's full conversation history or another subagent's working memory. This prevents a poisoned or confused subagent from corrupting the coordinator's state. The concept is covered in detail at subagent context isolation.

A deny-first permission policy is the safest default: subagents cannot take any action not explicitly listed in their tool set. Auto-approve only the actions whose failure cost is low and reversible.

How does the coordinator manage subagent selection and routing?

A well-designed coordinator does not hard-code which subagent handles which task. It selects subagents dynamically based on the task's characteristics at runtime. This is coordinator dynamic subagent selection: the coordinator inspects the decomposed subtask, matches it against available agent capabilities, and dispatches accordingly.

The practical implementation uses a capability registry. Each subagent is described by a short capability string (analogous to a tool description). The coordinator's system prompt includes this registry and instructs it to match tasks to agents by capability, not by name.

{
  "agents": [
    {
      "id": "research_agent",
      "capability": "Web search and document retrieval. Read-only. No write tools.",
      "tools": ["web_search", "fetch_url"]
    },
    {
      "id": "analyst_agent",
      "capability": "Quantitative analysis and chart generation from structured data.",
      "tools": ["python_exec", "chart_render"]
    },
    {
      "id": "writer_agent",
      "capability": "Long-form prose drafting from structured outlines.",
      "tools": ["draft_section"]
    }
  ]
}

When the coordinator receives a multi-concern request, it decomposes it into subtasks (see multi-concern request decomposition), matches each subtask to an agent, and dispatches them. Independent subtasks can be dispatched in parallel; dependent subtasks must be sequenced.

Parallel subagent spawning is one of the clearest performance wins in multi-agent design. If three research subtasks are independent, running them concurrently cuts wall-clock time by roughly two-thirds compared to sequential dispatch.

What should the coordinator pass to each subagent?

Context passing is where many multi-agent systems quietly fail. The two failure modes are opposite: passing too little context leaves the subagent unable to complete its task; passing too much dilutes attention and inflates cost.

Structured context passing is the solution. The coordinator constructs a minimal, structured payload for each subagent containing exactly what that subagent needs:

def build_subagent_context(task: dict, shared_facts: dict) -> str:
    """
    Construct a minimal context payload for a subagent.
    task: the specific subtask this agent must complete
    shared_facts: only the facts from the coordinator's context
                  that are relevant to this subtask
    """
    return f"""## Your task
{task['description']}

## Relevant background
{shared_facts['relevant_subset']}

## Output format
{task['output_schema']}

## Constraints
{task['constraints']}
"""

The coordinator does not pass its full conversation history. It passes a structured summary of the facts the subagent needs. This is the same principle behind summary injection for fresh sessions: a well-constructed summary outperforms a raw context dump.

The attention dilution problem is real: when a context window contains large amounts of irrelevant material, the model's effective attention on the relevant parts degrades. Keeping subagent contexts lean is not just a cost optimisation; it is a reliability measure.

How should a multi agent system handle errors?

Error handling in multi-agent systems is more complex than in single-agent loops because errors can originate at any layer and must be routed correctly.

The four error categories that matter for routing decisions are:

The coordinator is responsible for classifying errors and choosing the response. Multi-agent error handling and routing covers the decision tree in full. The key exam principle: the coordinator should not silently suppress errors or retry indefinitely. Both are anti-patterns that produce unreliable systems.

Error propagation in multi-agent systems at the tool layer uses the MCP isError flag to signal failures without crashing the calling agent's loop. The coordinator inspects this flag before deciding whether to retry, reroute, or escalate.

def handle_tool_result(result: dict) -> str:
    if result.get("isError"):
        error_category = classify_error(result["content"])
        if error_category == "transient":
            return "RETRY"
        elif error_category == "unrecoverable":
            return "ESCALATE"
        else:
            return "RETRY_WITH_FEEDBACK"
    return "SUCCESS"

How do you design safe permission flows without killing agent usefulness?

The tension in permission design is real: every approval checkpoint adds latency and friction; every skipped checkpoint adds risk. The resolution is to calibrate checkpoints to irreversibility and impact, not to apply them uniformly.

A practical three-tier model:

1. Auto-approve: Read-only actions, reversible writes with low blast radius (e.g., creating a draft document). No human in the loop.
2. Coordinator-approve: Actions that affect shared state or have moderate blast radius. The coordinator applies a programmatic rule (not a prompt reminder) before allowing execution.
3. Human-approve: Irreversible, high-impact actions (sending external communications, modifying production data, financial transactions). The system pauses and surfaces a structured handoff. See structured handoff to human agents for the handoff schema.

The CCAR-F exam rewards proportionate fixes. If the scenario describes a low-stakes reversible action, requiring human approval is the wrong answer; it is disproportionate. If the scenario describes an irreversible high-stakes action, prompt-based reminders alone are the wrong answer; programmatic enforcement is required.

How do you manage context across a long-running multi agent system?

Long-running multi-agent systems face a compounding problem: each subagent call consumes tokens, and the coordinator's own context grows with every round of synthesis. Without active management, the coordinator eventually hits its context limit or degrades in quality as its window fills with stale intermediate results.

Three strategies address this:

1. Session forking for divergent exploration. When the coordinator needs to explore two incompatible hypotheses, fork_session for divergent exploration creates independent branches rather than polluting the main session with contradictory reasoning.

2. Summary injection between phases. At the end of each major phase, the coordinator compresses its working memory into a structured summary and starts the next phase with that summary rather than the full history. This is the same technique used in per-file and cross-file pass patterns for large codebase tasks.

3. Prerequisite gates. Before dispatching a subagent that depends on a prior subagent's output, the coordinator verifies the prerequisite is complete and valid. Prerequisite gate design prevents cascading failures where a downstream subagent operates on bad input without knowing it.

The stale context problem is particularly acute in multi-agent systems because the coordinator may hold references to subagent outputs that were produced many steps ago. Explicit context refresh at phase boundaries is cheaper than debugging attribution errors after the fact.

How does this map to the CCAR-F exam?

Domain 1 (Agentic Architecture & Orchestration) carries 27% of the CCAR-F exam weight, making it the single largest domain. The exam draws four scenarios at random from a bank of six per sitting, so every scenario type has a meaningful probability of appearing.

The domain's 30 task statements cluster around the concepts covered in this post:

The exam consistently rewards three principles: deterministic solutions over probabilistic ones when stakes are high, proportionate responses (neither over-engineering nor under-engineering), and root-cause tracing rather than symptomatic fixes.

Our concept library at /concepts covers 174 atomic concepts mapped to all five CCAR-F domains and 30 task statements. The Agentic Architecture and Orchestration section maps directly to the patterns in this post. AI Skill Certs is an independent prep platform; we are not affiliated with or endorsed by Anthropic.