Academy AI Systems Engineering · Lesson 11 of 14

Multi-agent orchestration

A multi-agent system is a distributed system. Contracts, one source of truth, checkpoints and idempotency all apply.

Module
3 · Agentic systems
Slide
12 of 15
Reading
About 2 minutes
Published
Slide 12: Multi-agent orchestration
Slide 12 of 15 Module 3 · Multi-agent orchestration

The diagram is orchestrator-workers: one state store with a single writer, an orchestrator that delegates to three workers, a synthesis step, and a human approval gate before anything leaves. Every box is a place a distributed system can fail.

Why split at all

Three reasons hold up: focused contexts, so each worker sees only what its task needs; parallel work; and specialised roles with their own tools and prompts. Most other reasons turn out to be a single agent with a better prompt.

The pattern

The orchestrator decomposes the task, delegates each piece with a contract, reads structured results, and decides what to delegate next. Part 8’s workflows, prompt chaining, orchestrator-workers and evaluator-optimizer, each become multi-agent when their steps run their own agent loops. Two other shapes: handoff to a specialist, and a pipeline of fixed stages.

A delegation contract has six parts: objective, inputs, output schema, allowed tools, budget, and done criteria. A worker that receives fewer than six is guessing at the rest.

State

Keep state outside the agents, in a typed state object or a task table with an append-only event log. The orchestrator is the only writer. Workers return results; they do not update records. Checkpoint after each step so a crashed run resumes instead of restarting, and make steps idempotent so a resume does not apply anything twice.

The numbers

In June 2025 Anthropic reported that in its data, agents used about 4 times the tokens of a chat interaction and multi-agent systems about 15 times. A Claude Opus 4 lead with Claude Sonnet 4 subagents beat a single Opus 4 agent by 90.2 percent on Anthropic’s internal research eval, but token usage alone explained 80 percent of the performance variance on BrowseComp. Budget before you split. The same post found the pattern a poor fit when agents must share context or depend on each other’s work, which describes most coding tasks.

Where it goes wrong

Two workers update the same record from stale reads, and the last write wins. The fix is structural, not a prompt: workers return, only the orchestrator writes.

What to do

  • Start with one agent. Split only when work parallelises or one context overflows.
  • Write the six-part contract before the prompt.
  • Put a human approval gate after synthesis and before any action, as the diagram does.
The rule

Start with one agent. Split only when work parallelizes or one context overflows.

Reading