Most agent designs go wrong by imposing a structure the work does not have. Draw the dependencies and the pattern names itself.
Every agent system answers two questions before its first prompt is written, whether or not its designer asked them. Does this need more than one model call? And if it does, which pieces of the work depend on which? Answer them from the task and the structure follows. Start from a favourite architecture instead and you add coordination the task never needed, then pay for it.
Anthropic’s design guidance starts from “finding the simplest solution possible, and only increasing complexity when needed.” It also draws a line worth keeping. A workflow orchestrates models and tools “through predefined code paths”. An agent is a system where the model directs “its own processes and tool usage”. Four of the five patterns below are workflows; only one hands the plan itself to a model.
The reason to start small is cost, and the numbers are not subtle:
Agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.
Anthropic Engineering, How we built our multi-agent research system
The same write-up says where the extra agents earn that cost: “heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools.” And where they do not:
Most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.
Anthropic Engineering, How we built our multi-agent research system
Effort should scale with the question as well. The system’s own rule of thumb: simple fact-finding “requires just 1 agent with 3-10 tool calls”, direct comparisons “might need 2-4 subagents with 10-15 calls each”, and only complex research uses “more than 10 subagents with clearly divided responsibilities.”
Write down the pieces of work and draw an arrow wherever one piece needs another’s output. The drawing usually names the pattern. Each one below has a definition, the conditions it is meant for, and the sign in a real requirement that points to it.
Each call “processes the output of the previous one.”
Use when the task “can be easily and cleanly decomposed into fixed subtasks.”
The tellEvery arrow points forward, and step two cannot start until step one has finished.
“Classifies an input and directs it to a specialized followup task.”
Use for “complex tasks where there are distinct categories that are better handled separately.”
The tellEach input takes exactly one path, and the paths need different handling.
Either sectioning, independent subtasks run side by side, or voting, the same task run several times.
Use “when the divided subtasks can be parallelized for speed, or when multiple perspectives or attempts are needed.”
The tellNo arrows between the pieces, and you can list the pieces before you start.
A central model “dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.”
Its difference from parallelization is “its flexibility—subtasks aren’t pre-defined, but determined by the orchestrator.”
The tellYou cannot list the pieces in advance; what to do next depends on what the first pieces find.
“One LLM call generates a response while another provides evaluation and feedback in a loop.”
Use when there are “clear evaluation criteria” and “iterative refinement provides measurable value.”
The tellYou could write down what “good enough” means, and the first draft is rarely it.
Dashed workers are decided at run time. In the other four shapes the structure is fixed before the first call.
Parallelization and orchestrator-workers look alike on a whiteboard. Both fan out to workers and gather the results. One question tells them apart:
The list is fixed, so code can fan it out. A coordinator deciding it at run time is overhead.
The list depends on what the work uncovers, so only a model reading the results can write it.
Few pipelines are one pattern end to end. Take 200 documents that must be classified, have clauses extracted from the ones that are contracts, and then feed a single risk summary.
The common mistake is to add a second wait after classification, so the pipeline classifies all 200 before extracting any. Nothing requires it, and it makes every fast document queue behind the slowest one.
Name the shape before opening each one.
The transcripts are independent and known in advance, so a fixed fan-out works. Only the themes report needs everything at once.
The subtasks cannot be listed up front, so a lead has to decide them as results arrive.
Clear criteria and a first draft that is rarely final: generate, evaluate against the rules, revise.
Fixed steps, each consuming the previous output. Nothing to parallelize and nothing to decide at run time.
Classify once, then send each ticket down the one path that handles its kind.
Coupled changes are not truly parallel, and real-time coordination between agents is the weak spot. Whether to agree the approach first is the question of part 3.
Sources: Anthropic Engineering, Building effective agents and How we built our multi-agent research system. Checked September 2026.
For the practice half, ExamGauge has 1523 original practice items across four Claude certification exams, scored on the real 100–1000 scale against the 720 cut. The diagnostic is free and needs no card.