A pharma company builds a multi-agent system to investigate deviations. Five specialized agents — fact extraction, document retrieval, root cause analysis, compliance review, report generation — orchestrated by a coordinator running on Claude Opus.

It works beautifully in the demo. In production, it costs $4 per investigation, takes 90 seconds, and fails silently when the document retrieval agent hallucinates a batch record number. The single-agent version with a well-structured prompt and deterministic retrieval pipeline costs $0.30, finishes in 20 seconds, and fails loudly when the batch record does not exist.

The multi-agent system was not wrong in principle. It was wrong for that problem. Knowing the difference is what separates an architect from someone who has read too many framework READMEs.

The Real Question

The question is never “how do I build a multi-agent system.” The question is whether you should build one.

Anthropic’s own guidance is blunt: the most successful implementations use simple, composable patterns rather than complex frameworks. Most production use cases do not need fully autonomous multi-agent systems. They need well-structured orchestration with clear boundaries.

Multi-agent systems introduce overhead. Every additional agent is another failure point, another prompt to maintain, and in testing, multi-agent implementations typically use 3 to 10x more tokens than single-agent for equivalent tasks. That cost comes from duplicating context, coordination messages, and summarizing for handoffs.

Use multi-agent only when you have one of three proven constraints:

Context pollution. A subtask generates more than 1000 tokens that are irrelevant to the main task. Example: pulling a customer’s full order history (2000+ tokens) while trying to diagnose a technical issue. Solution: spawn an isolated agent that returns a 50-token summary.

Parallelization. You need breadth, not speed. The lead decomposes a question into facets, spawns subagents concurrently, then synthesizes. The benefit is thoroughness — covering more ground than a single agent could in the same time.

Tool overload. You have crossed 15 to 20+ tools, or your tools span unrelated domains. The model struggles to select correctly. Before you split into specialized agents, try a Tool Search tool that lets the model discover tools on demand. That alone can reduce token usage by up to 85%.

If none of these constraints apply, a single agent with better prompting, context compaction, or retrieval will outperform your multi-agent system at a fraction of the cost.

The Hub-and-Spoke Pattern

When you do build multi-agent, the dominant architecture is hub-and-spoke. A coordinator agent sits at the center. Specialized subagents sit around it as spokes. All communication flows through the hub.

             ┌──────────────┐
             │  Coordinator │
             └──────┬───────┘
           ┌────────┼────────┐
           ▼        ▼        ▼
     [Research]  [Analysis] [Synthesis]
      subagent    subagent   subagent

Three rules govern this pattern:

Rule 1: All communication flows through the coordinator. Subagents never talk to each other directly. This is the single most commonly misunderstood concept in multi-agent design. The exam exploits it deliberately — expect distractor answers that suggest letting subagent A pass its output straight to subagent B. The reason is observability (you can log every message in one place), consistent error handling, and controlled information flow.

Rule 2: Subagents have isolated context. When the coordinator spawns a subagent, that subagent starts with only what the coordinator explicitly includes in its prompt. No system prompt, no prior messages, nothing unless you deliberately pass it. This isolation is what gives you clean parallelism — subagents can run concurrently precisely because they are not sharing or mutating a common context.

Rule 3: The coordinator owns decomposition and synthesis. It decides what to delegate, to whom, and how to combine the results. If the final output is incomplete, the failure is in the coordinator’s decomposition, not in the workers.

How Anthropic Built Theirs

Anthropic’s Research feature is the canonical production example. When a user submits a query, a lead agent analyzes it, develops a strategy, and spawns subagents to explore different aspects simultaneously. Each subagent independently performs web searches, evaluates results using interleaved thinking, and returns findings to the lead. The lead synthesizes these results, decides whether more research is needed, and either spawns additional subagents or passes the compiled findings to a citation agent that attributes every claim to its source.

The numbers are striking. A multi-agent system with Claude Opus 4 as the lead and Claude Sonnet 4 workers outperformed single-agent Opus 4 by 90.2% on internal research benchmarks. Three factors explained 95% of the performance variance: token usage (80% alone), tool call count, and model choice.

But the cost is equally striking. Multi-agent systems use approximately 15x more tokens than chat interactions. Single agents use about 4x. The economics only work when the value of the task justifies the spend.

What They Learned

Teach the orchestrator to delegate precisely. Early versions allowed the lead agent to give vague instructions like “research the semiconductor shortage.” Subagents duplicated work — one explored the 2021 automotive chip crisis while two others independently investigated 2025 supply chains with no effective division of labor. The fix: detailed task descriptions with clear objectives, expected output formats, tool guidance, and explicit task boundaries.

Scale effort to query complexity. Agents struggle to judge appropriate effort. Without explicit scaling rules, early versions spawned 10 subagents for simple fact-finding questions. The fix: embed rules in the prompt. Simple fact-finding gets 1 agent with 3 to 10 tool calls. Direct comparisons get 2 to 4 subagents with 10 to 15 calls each. Complex research gets 10 or more subagents with clearly divided responsibilities.

Start broad, narrow iteratively. Agents default to overly specific queries that return few results. The fix mirrors how experts actually research: start with short, broad queries, evaluate what is available, then progressively narrow focus.

Subagents should output to a filesystem, not just to the coordinator. For structured outputs like reports or data, have subagents write artifacts to persistent storage and pass lightweight references back. This prevents information loss during multi-stage processing and reduces the token overhead of copying large outputs through conversation history.

Context Isolation Is Not Optional

This deserves its own section because it is where most designs fail in practice.

When the coordinator spawns a synthesis subagent to combine findings from three research agents, the synthesis agent does not automatically know what the research agents found. The coordinator must explicitly pass the findings — and it must pass them in a structured format, not as a concatenated text blob.

Structured:

{
  "findings": [
    {
      "content": "Market grew 23% in 2025",
      "source_url": "https://...",
      "source_title": "Industry Report 2025",
      "retrieved_at": "2026-07-12"
    }
  ]
}

Not structured:

Agent 1 found: Market grew 23% in 2025 (source: Industry Report).
Agent 2 found: Competitor X launched product Y.
Agent 3 found: Regulatory changes expected Q4.

The structured version preserves attribution, enables the synthesis agent to cite sources correctly, and prevents the “game of telephone” where information degrades with each handoff.

Context-Centric Decomposition

Most teams decompose by problem type: one agent writes features, another writes tests, a third reviews. This creates constant coordination overhead and a telephone game where each handoff loses fidelity.

Anthropic’s rule: decompose by context boundaries, not by problem phases. Effective boundaries include independent research paths (“market trends in Asia” versus “Europe”), separate components with clean API contracts, and blackbox verification tasks. Problematic boundaries include sequential phases of the same work, tightly coupled components, and work requiring shared state.

The Claude Agent SDK: How It Works in Practice

If you are building with Claude, the Agent SDK provides the primitives.

The Task Tool

The Task tool spawns subagents. The coordinator’s allowedTools must include "Task" — without it, the coordinator cannot invoke subagents at all.

options = ClaudeAgentOptions(
    allowed_tools=["Read", "Grep", "Glob", "Task"],
    system_prompt="You are a research coordinator...",
)

Each subagent gets its own AgentDefinition with a name, description, system prompt, restricted tool list, and model selection. Use Haiku for fast classification tasks, Sonnet for balanced execution, and Opus for complex reasoning or synthesis.

The Agentic Loop

The loop is simple:

  1. Send request to Claude with tool definitions and conversation history
  2. Receive response
  3. Check stop_reason: "tool_use" means execute tools and loop; "end_turn" means done
  4. Append results to history
  5. Go to step 1

The critical detail: stop_reason is the only reliable signal for loop termination. Never parse the assistant’s text content to decide whether to continue. Never check for phrases like “task complete.” The structured API field is deterministic; natural language parsing is not.

Hooks: Where Determinism Lives

Hooks are functions the SDK calls at specific points in the agent lifecycle — before a tool executes (PreToolUse), after a tool returns (PostToolUse), when a subagent starts or stops, and at several other lifecycle events.

Use hooks for anything that requires guaranteed compliance:

  • PreToolUse: Block policy-violating actions. A hook that prevents refunds over $500 is code that runs 100% of the time. A prompt instruction asking the model to “never refund more than $500” is a probabilistic suggestion that fails approximately 1% of the time. In regulated industries, 1% is unacceptable.

  • PostToolUse: Normalize data before the model sees it. If three different MCP tools return timestamps in Unix epoch, ISO 8601, and numeric status codes, a PostToolUse hook converts them all to a consistent format. The model does not waste tokens parsing heterogeneous formats.

  • SubagentStart / SubagentStop: Track parallel task spawning and aggregate results from completed workers.

The principle: the orchestration layer provides determinism, the LLM provides reasoning. Never blur that boundary.

Orchestration Patterns Beyond Hub-and-Spoke

Hub-and-spoke is the default, but it is not always the right choice.

Sequential Pipeline

Agents execute in a fixed sequence. Each transforms the output of the previous one.

Extract → Classify → Analyze → Format → Output

Use when steps are predictable and each depends on the prior. The risk: if step 2 fails, the entire pipeline halts unless you design explicit error-handling branches. Context loss at handoff points is the primary failure mode.

Router

A lightweight classifier agent examines the incoming request and routes it to the right specialist. The router does zero substantive work — only classification.

Customer Request → Router → [Billing | Technical | Sales]

Use for multi-domain support surfaces where loading every tool and system prompt into one context would degrade performance. The cost optimization angle: route easy questions to Haiku, hard questions to Sonnet or Opus.

Evaluator-Optimizer Loop

One agent generates, another evaluates against clear criteria, and they iterate until the output passes.

Generator → Evaluator → Pass? → Output
    ↑                   │
    └── Feedback ───────┘

Use when you have well-defined quality criteria and iterative refinement measurably improves output. The trap: infinite loops. Always set a maximum iteration count. The subtler trap: the “early victory” problem where the evaluator runs one check and marks PASS. Mitigation: require concrete criteria — “run the full test suite and report all failures” rather than “make sure it works.”

Verification Subagent

One pattern that consistently works well across domains. The main agent completes work, then spawns a verifier with the artifact, clear success criteria, and tools to verify. The verifier does not need the full build history — only blackbox validation. This sidesteps the telephone game because the verifier checks the output directly, not a summary of how the output was produced.

Production Constraints

Circuit Breakers

Multi-agent loops can recursively call subagents or trigger self-correction, leading to infinite execution. Implement hard boundaries: maximum turn counts, per-run token ceilings, and time-based timeouts. These are deterministic controls, not prompt instructions.

The Cost Reality

A single Claude call costs pennies. A multi-agent orchestration loop with five agents, each making three tool calls, synthesis, and verification, can easily cost $2 to $5 per execution. Multiply by thousands of daily requests and the economics change fast. Model tiering is essential: use the cheapest capable model for each role.

Human-in-the-Loop

For state-mutating actions — merging code, executing payments, approving CAPAs — insert human approval gates. But design them carefully. Production data shows that users approve approximately 93% of requests without reading them when every action requires approval. Gate the high-leverage decisions. Automate the rest with model-based guardrails.

Observability

Multi-agent systems are opaque by default. You need:

  • Trace IDs that propagate through every agent invocation
  • Per-agent logging of decisions and reasoning
  • Latency breakdown to identify bottlenecks
  • Cost attribution per agent per request
  • Decision audit trails for regulatory compliance

In regulated industries, this is not optional. If you cannot explain which agent made which decision and why, you cannot validate the system.

When Multi-Agent Maps to Regulated Industries

Multi-agent architectures align naturally with how regulated organizations already operate. QA, Manufacturing, Validation, and Regulatory Affairs each have defined responsibilities and documented handoffs. An AI system becomes more governable when each agent has a single, auditable role.

Consider a deviation investigation system:

Agent Role Tools Model
Fact Extractor Extract structured facts from deviation report Document parser Haiku
Document Retriever Find relevant SOPs, batch records, prior deviations Vector DB, SQL Sonnet
Root Cause Analyzer Identify probable causes from evidence None (reasoning only) Opus
Compliance Checker Validate against 21 CFR Part 211, ICH Q10 Regulation database Sonnet
Report Generator Produce investigation report with citations Template engine Sonnet
Verification Agent Check report claims against source evidence Document comparison Sonnet

Each agent has a narrow scope, restricted tools, and a defined output contract. The coordinator passes structured context between agents. Hooks enforce that no report is finalized without verification. A human QA reviewer approves the final package.

That separation of responsibilities improves reasoning quality, reduces context pollution, and makes the system easier to validate, test, and explain to auditors.

The Decision Checklist

Before you build multi-agent, run this:

  1. Can a single agent with better prompting, retrieval, or tool search solve it? If yes, stop here.
  2. Is there context pollution, clear parallelization potential, or tool overload? If no, stop here.
  3. Define the coordinator’s job: decompose, delegate, synthesize. Workers never spawn workers.
  4. Restrict each subagent’s tools and model. Less is more.
  5. Add a verification subagent with explicit, comprehensive checks.
  6. Design for failure: budget for 3 to 10x token cost, plan for partial worker failure, add observability from day one.
  7. Add circuit breakers: max turns, cost ceiling, time limit.
  8. Make the orchestration layer deterministic. Let the LLM reason, but let code enforce.

The Bottom Line

Multi-agent systems are a powerful architectural tool. They are also the most over-prescribed solution in AI engineering. The teams that succeed with them are the teams that build them reluctantly — only after a single-agent approach demonstrably cannot handle the task.

When you do build one, keep the architecture simple: hub-and-spoke coordinator, isolated subagents with focused toolsets, structured context passing, deterministic enforcement through hooks, and a verification step before anything reaches production.

The intelligence is in the coordination, not in the individual agents. Design the system so that each agent does one thing well, the coordinator makes informed decisions about what to delegate, and the whole pipeline fails loudly and recoverably when something goes wrong.

That is what it means to architect multi-agent systems. Not to make five Claude instances talk to each other. To make them work together in a way that is cheaper, faster, and more reliable than a single agent doing everything alone.