2.3 Multi-Agent Orchestration and Session Management

When Multi-Agent Is Justified (and When It Is Not)

Multi-agent systems are powerful and over-used. The CCA-F, following Anthropic's guidance, treats a single agent as the default and a multi-agent design as a deliberate escalation. Add a second agent only when one or more of these is true:

• The task fans out into independent subtasks that can run in parallel (research five competitors, review ten files).
• Subtasks need different tools or permissions that you do not want to grant one over-privileged agent.
• A subtask would flood the main context window with detail the orchestrator does not need to keep.
• A subtask benefits from a fresh, unbiased context — for example, a reviewer that should not see the author's reasoning.

If none of these hold, a single agent is simpler, cheaper, and easier to debug. The exam penalizes a multi-agent answer for a task a single bounded agent handles. Multi-agent designs add real costs: coordination overhead, more tokens, higher latency, and harder failure analysis when something goes wrong across agents.

The Orchestrator (Hub-and-Spoke) Pattern

The dominant multi-agent shape on the exam is hub-and-spoke, also called orchestrator-workers. A lead (orchestrator) agent decomposes the task and delegates to subagents (workers), then synthesizes their results.

            +-------------------+
            |   Orchestrator    |
            |  (lead agent)     |
            +---------+---------+
           delegates  |  synthesizes
        +-------------+-------------+
        v             v             v
   +---------+   +---------+   +---------+
   |Subagent |   |Subagent |   |Subagent |
   | research|   |  code   |   | review  |
   +---------+   +---------+   +---------+
  isolated ctx  isolated ctx  isolated ctx

Key properties the exam tests:

• Each subagent has its own isolated context window, system prompt, and tool allowlist. A research subagent cannot accidentally push code, and a review subagent starts clean.
• The orchestrator delegates a clearly scoped task to each subagent and receives a condensed result, not the subagent's full transcript.
• Delegation is usually one level deep. A subagent spawning its own subagents quickly becomes hard to bound; most exam-correct designs keep a single orchestration layer.

This is the same orchestrator-workers pattern from Chapter 2.1, now realized with multiple agent instances rather than plain LLM calls.

Subagents Protect the Context Budget

A subagent's most underappreciated job is context economy. Suppose the orchestrator must reason over the findings of five document reviews, each requiring 8,000 tokens of source material. Feeding all five into the orchestrator costs 40,000 tokens of context and dilutes its attention. Instead, spawn five review subagents; each reads its 8,000 tokens in its own window and returns a 300-token summary. The orchestrator now holds 1,500 tokens of distilled findings instead of 40,000 tokens of raw text.

This is why the exam frames subagents as a context-management tool, not just a parallelism tool. The pattern: push heavy reading down into a subagent, pull back a summary. The same idea underlies Claude Code subagents (Chapter 3) — a test-runner subagent runs noisy test output in its own context and reports a clean pass/fail to the main session.

Guardrails carry over from single agents: each subagent is bounded (max turns), least-privileged (only the tools it needs), and verified (its output is checked before the orchestrator trusts it).

Session Management and Resumption

Long or interrupted tasks need session management — persisting conversation state so an agent can resume rather than restart. The Messages API itself is stateless: you resend the full history each turn. Higher layers add persistence:

• Claude Agent SDK sessions. The SDK can persist a session and resume it by ID, restoring the message history and agent state so a multi-day task or a crashed run continues where it stopped.
• Managed Agents (server-side). Anthropic runs the loop and the tool sandbox; you create a session that streams events (agent.message, agent.tool_use, session.status_idle, session.status_terminated). State lives server-side, and you reconnect to the event stream. Because Server-Sent Events have no replay, the robust pattern on reconnect is to fetch the event history first, then tail the live stream, deduplicating by event ID.
• Memory across sessions. For state that must outlive a single conversation (user preferences, learned facts), agents read and write a memory store — a persistent file-like surface — rather than relying on the in-context history.

The exam contrast to know: the Agent SDK runs the loop in your process (client-side tools, your infrastructure), while Managed Agents run the loop and host the sandbox on Anthropic's side. Choose Managed Agents when you want Anthropic to host the workspace and stream events; choose the SDK when you must run tools on your own compute.

Error Propagation Across Agents

In a single agent, a tool error returns a structured result the model can reason about. In a multi-agent system, errors must propagate up to the orchestrator deliberately, or subtasks fail silently. The exam's Domain 5 explicitly lists error propagation in multi-agent setups.

Good propagation design:

• A subagent that fails returns a structured failure (an error code plus detail), not a hallucinated success or a swallowed exception.
• The orchestrator inspects each subagent result and decides the recovery: retry the subtask, reassign it to a different subagent or model, degrade gracefully with a partial result, or escalate to a human.
• A subagent must never be able to mark the whole task complete on the orchestrator's behalf — the lead owns the stop condition.

Failure-mode table for multi-agent designs:

When a scenario describes a multi-agent system misbehaving, name the specific failure first, then choose the matching control — the same symptom-to-control discipline used everywhere in this guide.