Multi-agent systems and orchestration

What you’ll be able to do

• Decide when a multi-agent design is justified and when a single agent or workflow is better
• Select an orchestration strategy (coordinator-worker, pipeline, parallel fan-out, evaluator loop, hierarchy) from the task structure
• Design inter-agent contracts that carry status, provenance and partial results
• Scope tools and permissions per agent and bound the system with budgets and stop conditions
• Design for failure, error propagation and observability across agents

What you need to know

Justify the second agent

Multiple agents are a cost, not a feature. Every extra agent adds model calls, handoffs where context is lost, more failure modes and more traces to read. A multi-agent design is justified by one of a small number of reasons:

• Breadth that parallelizes: research across many independent sources or partitions, where running subtasks concurrently cuts wall-clock time and each subtask fits comfortably in its own context.
• Context isolation: a subtask would flood the main context with material the rest of the task does not need (reading a large codebase, scanning hundreds of documents). A subagent reads it and returns a compact result.
• Separate permission scopes: one part of the work needs access the rest must not have, such as a read-only analysis agent separated from an agent that can write to a ticketing system.
• Distinct specialization: different instructions, tools or even models genuinely perform better for a well-defined subtask, and you can show it with evaluation.

If none applies, a single agent with good tools, or a workflow, is easier to build, evaluate and run. Agents that are tightly interdependent, where each needs most of the others' context to act, usually perform worse when split.

Pick the orchestration strategy from the task’s shape

• Coordinator-worker (hub and spoke): one coordinator decomposes, delegates, aggregates and decides what comes next. Workers do not talk to each other. Default for open-ended research and investigation, because the hub is the one place with the full picture and the one place to log and handle errors.
• Sequential pipeline: fixed stages with handoffs (intake, analysis, drafting, review). Predictable; this is a workflow whose steps happen to be agents.
• Parallel fan-out / fan-in: the same kind of task across independent partitions, merged at the end. Watch the merge step: it is where duplicates, conflicts and gaps surface.
• Evaluator loop: a generator and an independent reviewer iterate against explicit criteria. Useful when quality can be checked more reliably than it can be produced in one shot, with a bounded number of rounds.
• Hierarchical: coordinators of coordinators for very large tasks. Each layer adds latency and summarization loss; use only when one coordinator cannot hold the plan.

Contracts between agents

Subagents do not share the coordinator's memory; they know only what they are given. So the handoff in both directions is an interface and deserves a schema. Downward, pass the goal, scope boundaries (what not to cover), relevant facts already established, and the output format. Upward, return structured results that carry:

• status: complete, partial, failed, or out of scope, with a reason;
• findings with provenance: claims linked to the source or tool result they came from, so synthesis can cite and resolve conflicts;
• coverage notes: what was searched and what was not, so the coordinator can find gaps;
• errors as data: a timeout or access failure reported explicitly, never disguised as "no results found".

Free-text summaries between agents feel simpler but destroy the information the coordinator needs to decide whether to retry, re-scope or tell the user the answer is incomplete.

Scope, budgets and stop conditions

Apply least privilege per agent: each gets only the tools its role requires, and write or irreversible tools live in as few agents as possible, ideally behind a human approval or a deterministic check. Bound the system as a whole: maximum parallel workers, per-task and per-run token or cost budgets, wall-clock limits, and a maximum number of refinement rounds. When a limit trips, the coordinator should return what it has with an honest coverage statement rather than fail silently or loop.

Failure, propagation and observability

In a multi-agent system, one agent's error becomes the next agent's input. A hallucinated fact from a worker, passed upward as confident text, becomes a cited claim in the final report. Defenses: structured status and provenance, validation at the hub before aggregation, retries only for transient failures and only for idempotent operations, and explicit partial-result handling. For observability, propagate a single trace or correlation ID through every delegation and tool call, log the inputs and outputs of each handoff, and record which agent made which decision. When a final answer is wrong, you need to find the hop where it went wrong without re-running the whole system.

Key concept

Add an agent only for parallel breadth, context isolation, a separate permission scope or proven specialization; then orchestrate through a hub with typed contracts, least-privilege tools, budgets and one trace across every hop.

Exam scenarios often present a multi-agent system with a symptom (missing coverage, runaway cost, an unexplained wrong answer, an over-privileged worker). The best answer fixes the structure: the decomposition, the contract, the tool scope or the budget, rather than tuning one agent's prompt or adding more agents.

Practice scenario

Build exercise — Design a multi-agent contract

Advanced · 50 min

What you’ll learn

• Testing whether multi-agent is justified
• Writing typed handoff contracts with status and provenance
• Scoping tools and budgets per agent

1. For a multi-agent design you own or plan, write next to each agent the single justification (breadth, isolation, permission scope, specialization) it serves.

   • Why: Agents with no justification add cost and failure modes.
   • You should see: At least one agent that could merge into another or become a plain function.

2. Write a JSON schema for the result each worker returns, including status, findings with source references, coverage and error fields.

   • Why: Typed results let the coordinator detect failures and gaps instead of trusting prose.
   • You should see: A schema where a timeout cannot be represented as an empty success.

3. Build a table of agent, tools, write access, budget and stop condition, then remove every tool not needed by that role.

   • Why: Least privilege per agent shrinks the blast radius of any one agent’s mistake.
   • You should see: Write-capable tools concentrated in one or two agents, each behind a check or approval.

Exam traps

Splitting into many agents because it mirrors the org chart, not the task

Agent boundaries should follow parallelism, context and permission needs. Interdependent work usually suffers when split.

Giving every subagent the full tool set “for flexibility”

It enlarges the attack surface and invites misuse. Give each agent only the tools its role requires.

Letting subagents talk to each other directly so no single component sees the whole flow

Peer-to-peer handoffs scatter error handling and logging. Route through a coordinator that owns the picture.

Passing free-text summaries between agents with no status, sources or error information

The coordinator cannot tell success from failure or check claims. Use structured contracts with provenance.

Treating a subagent failure as an empty result and continuing silently

A failed check reported as “nothing found” becomes a false negative downstream. Report errors as data and handle them explicitly.

Ignoring the token and latency multiplication that parallel agents create

Each agent consumes its own context and calls. Set budgets and limits, and confirm the benefit justifies the cost.

Sources

• Claude Developer Platform Docs
• Anthropic
• Anthropic, Claude Certified Architect – Professional Exam Guide v1.0 (July 2026)