Start With One Agent and Ordinary Code
Before drawing a team of agents, it's worth agreeing on the bar for entry - because the rest of the book verifies, rather than declares, that a split is useful. A multi-agent system is needed only when it measurably solves a problem a simpler variant couldn't. One model call is good for a known input and format: classification, field extraction, a short transformation, a verifiable structured output. One agent - when the path is dynamic: choose a tool several times, check the result, and stop on a condition. Several agents are justified only when there's work you can genuinely split by context, tools, rights, or time.
Anthropic explicitly recommends starting with the simplest solution and increasing complexity only when needed. In their classification a workflow follows predefined code, while an agent dynamically chooses its own process and tools. The boundary is useful: two sequential model calls don't have to become two agents.
Hence a ladder of complexity to climb one rung at a time.
- A deterministic function.
- One model call with a result schema.
- A workflow of several verifiable steps.
- One agent with a bounded set of tools.
- One supervisor and one narrow worker.
- A parallel team with separate state and budget.
The book's rule. Implement the single-agent baseline first. A multi-agent candidate appears only after a recorded failure mode: an overflowing context, independent search directions, incompatible rights, too much sequential latency, or the need for independent verification. This order doesn't forbid experiments - it stops an experiment from quietly becoming a production architecture.
The bar is set. The first engineering step is to separate the concepts so you can see where control lives.
When is a multi-agent system justified?