Designing Multi-Agent Systems at Scale

Multi-agent systems are the part of the syllabus where enthusiasm most often outruns engineering. A second agent adds a second context window, a second set of failure modes and a multiplier on your token bill. The professional architect knows the handful of situations where that is worth it and designs the boundaries so the system stays legible.

When more than one agent is justified

Three conditions make multi-agent designs pay off:

1. Breadth that must run in parallel. Researching twenty suppliers, reviewing fifty files, or testing several hypotheses at once. One agent would do these serially and slowly.
2. Context that would otherwise overflow. A worker can read a thousand pages and return a one-page answer; the orchestrator never sees the thousand pages. This is context isolation, and it is the single strongest argument for subagents.
3. Specialisation with different tools or permissions. A read-only research agent and a write-capable deployment agent should not share a context or a permission set.

If none of these apply, a single agent with a good plan is cheaper and easier to debug. Anthropic's own reporting on multi-agent research systems notes that they consume many times the tokens of a single-agent chat, so the task value has to carry that.

Topologies

Topology	Flow	Strengths	Weaknesses
Orchestrator-workers	Orchestrator plans, dispatches, synthesises	Clear ownership, parallelism, context isolation	Orchestrator is a bottleneck and single point of planning error
Pipeline of specialists	Each agent transforms and hands on	Simple, testable stage by stage	Errors propagate; no global view
Peer handoff	Agents pass control based on state	Natural for conversational routing	Loops and ping-pong without a supervisor
Evaluator pair	Generator and critic iterate	Quality gains on criteria-driven tasks	Needs iteration caps and a definition of done

Orchestrator-workers is the default for the exam and in practice. Keep the orchestrator responsible for the plan, the decomposition and the final synthesis; keep workers responsible for one bounded task each.

Communication: results, not transcripts

The most common scaling mistake is passing whole conversation transcripts between agents. It bloats context, leaks irrelevant detail and makes caching impossible. Instead, define an output contract for every worker: a schema or a fixed document shape that the orchestrator can rely on.

{
  "task_id": "supplier-17",
  "status": "complete",
  "findings": ["..."],
  "evidence": [{"source": "contracts/17.pdf", "page": 4}],
  "confidence": 0.82,
  "open_questions": []
}

Structured outputs give you this for free. The orchestrator then reasons over compact, typed results, and a human can audit any worker's output in isolation.

Shared state that several agents must see (a plan, a task board, a set of files) belongs in an external store: the filesystem in Agent SDK designs, a database, or a memory store. Agents read and write the store through tools rather than narrating it to each other.

Task boundaries and the orchestrator's brief

Workers underperform when their brief is vague. A good delegation includes the objective, the expected output format, the tools they may use, what is out of scope, and what the orchestrator already knows so they do not repeat it. Anthropic's guidance for subagents is to scale effort to complexity: a quick fact-check needs one worker and few tool calls; a comparative analysis may need several workers with a larger budget each.

Give the orchestrator explicit rules about when to stop delegating. Without them, agents will spawn further agents for marginal gains.

Cost and model mix

Workers are the obvious place to use a cheaper model tier: their tasks are bounded, their outputs are checked by the orchestrator, and they run in volume. Keep the orchestrator on a stronger model because planning and synthesis errors are expensive. Set a budget per worker and per run, and record token usage per agent so that cost attribution survives into production dashboards.

Failure modes to design against

• Duplicated work. Two workers investigate the same thing. Fix with a shared task list and unique task IDs.
• Conflicting writes. Two coding agents edit the same file. Fix with ownership rules per file or directory, or isolated worktrees merged by a deterministic step.
• Compounding error. A wrong fact from one worker becomes a premise for others. Fix by attaching evidence to findings and having the orchestrator verify high-impact claims.
• Lost context. The orchestrator forgets why a task was dispatched. Fix by keeping the plan in an external document that is re-read, not only in context.
• Runaway recursion. Workers spawning workers. Fix with depth limits and a rule that only the orchestrator may delegate.

Observability

Every agent run needs a trace ID that follows every worker and every tool call. Log the delegation brief, the worker's output contract and token usage. When a run produces a wrong answer, you must be able to replay the exact path. Without this, multi-agent systems are undebuggable in production.

Exam focus

• Multi-agent is justified by parallel breadth, context isolation or differing tools and permissions; otherwise prefer a single agent.
• Orchestrator-workers is the default topology; the orchestrator owns plan and synthesis, workers own bounded tasks.
• Pass structured results between agents, not transcripts; shared state lives in an external store accessed through tools.
• Delegation briefs must specify objective, output format, allowed tools, scope and known context.
• Use cheaper models for workers and stronger models for the orchestrator; budget and attribute tokens per agent.
• Expect questions on failure modes (duplication, conflicting writes, compounding error) and their structural fixes.