From one LLM call to many agents: the patterns, the trade-offs, and how to pick.
Who decides what happens next: your code, or the model?
Every pattern today is a different answer to that one question.
Your code writes the arrows.
The model picks the next step from tools you defined.
Models pick the next step, and which agent takes it.
More autonomy buys flexibility, and costs calls, latency and predictability.
The parts every agent is built from
Call the model with tools. If it asks for a tool, run it in your code and hand the result back. Stop when it answers without asking. Everything else today is built on top of these lines.
Read more → What is an agent loop, really?A reasoning model is a better brain. An agent is a brain with hands and a loop. They compose.
This is the whole contract. The model never sees your function, only this. Write the description as if for a new colleague: what it does, when to use it, what it returns.
MCP gives the agent new abilities. A skill tells it how to use the ones it has. You often want both.
The frontmatter is all the agent carries around. When a task matches the description, it reads the body, and only then the files the body points at. That is how a skill protects the context window.
Retrieval-augmented generation: index your documents ahead of time, then at question time fetch the few chunks that look relevant and put them in the prompt. New knowledge without retraining.
The answer lives in documents the model has never seen: policies, catalogues, your codebase.
When RAG is wrong it is usually retrieval, not generation. Measure whether the right chunk came back.
The long-term split comes from the CoALA paper (Sumers et al., 2023). It gives you a vocabulary for where a fact should live.
Planning decides what to do. Reflection decides whether it worked, and often triggers a new plan.
Your code owns the control flow
Split the task into fixed steps. Each call does one step and its output becomes the next call’s input. Between steps, plain code can check the output and stop or retry.
The task splits cleanly into the same steps every time: outline, draft, translate, format.
Latency adds up step by step, and an early mistake poisons everything after it. Check at the gates.
One cheap call classifies the input, then code sends it down the path built for that class: a specialised prompt, a cheaper model, or no LLM at all.
Inputs fall into distinct kinds that deserve different handling, or easy ones can go to a small model.
A wrong route fails quietly. Log every decision and give the router an “unsure” path.
Run several calls at once and combine the results. Sectioning splits the work into independent parts. Voting runs the same task several times and takes the consensus.
The parts don’t depend on each other, or you want more confidence: guardrails, reviews, classifications.
You pay for every branch. The aggregator is a design problem of its own: what if the branches disagree?
No framework needed. Chaining is calling one function after another, routing is a switch statement, parallelization is Promise.all. You can unit-test every line.
If you can draw the flowchart before the request arrives, you don’t need an agent.
Workflows are cheaper, faster and easier to test. Reach for autonomy only when the path really is unknown.
The model picks the next step
Reason, then act, then observe, then reason again. The model writes down a thought, makes a tool call, reads the result, and decides the next move until it can answer.
Open-ended tasks where the next step depends on what you just found: research, debugging, support.
Without a step limit and a clear definition of done, it wanders. Cap steps, log every thought.
Nothing here was planned in advance. Each action came from the last observation. That adaptability is the point, and it is also why you can’t predict the cost.
A planner writes the whole plan up front, then an executor works through it step by step. When a step fails, go back to the planner instead of improvising.
Long tasks with a predictable shape, where a strong planner and a cheaper executor save money.
Plans go stale when reality surprises you. If the steps never change, you may just want a workflow.
Generate, critique, revise. In self-refine the model critiques its own draft. In Reflexion a real failure, like a failing test, produces a written lesson that the next attempt carries.
Quality is checkable: tests pass, a schema validates, a rubric is clear.
A model grading itself with no outside signal tends to approve its own work. Cap the rounds.
Instead of one JSON tool call per step, the agent writes a small program as its action. Loops, variables and composition happen in one move, in a language the model has seen a lot of.
Many small operations over data: filtering, joining, calculating, batch edits.
You are running code a model wrote. That belongs in a sandbox with no secrets and no open network.
With JSON tools this is a glob, then a read per file, then a count, each a round trip through the model. As code it is one action and one observation.
Read more → Sandboxing agent code executionStart with one agent.
Most “we need multi-agent” problems are one agent that needs better tools or a cleaner context.
Models pick the step, and who takes it
A pipeline like prompt chaining, except every stage is a full agent with its own prompt, tools and maybe model. Each stage can plan, retry and check its own work before handing off.
Clear stages that need different tools or expertise: research, then write, then review.
Errors compound down the line and latency stacks. Define the handoff format and validate it.
Fan the request out to several agents at once, each with its own clean context, then merge. Sectioning splits the work; voting has several agents attempt the same thing.
Broad questions with independent threads: research across sources, reviewing many files.
Fast in wall-clock time, expensive in tokens. Merging conflicting findings is the hard part.
One agent keeps the big picture. It breaks the task down as it goes, briefs subagents, reads what they return and decides what next. Subagents never need to know about each other.
You can’t list the subtasks in advance, and each one benefits from a narrow, clean context.
The supervisor is the bottleneck and the biggest bill. A vague brief to a subagent wastes a whole run.
The multi-agent version of routing. A triage step reads the request and hands it to exactly one specialist agent. Only one path runs: it is a fork, not a decomposition.
Requests fall into distinct domains with different tools: billing, technical support, sales.
A wrong handoff is hard to recover from. Let specialists hand back, and escalate when unsure.
One agent does the work, a second agent judges it and sends back a critique, and the loop repeats until the evaluator passes it or a limit is hit.
There is a clear bar to clear (tests, a rubric, a spec) and quality matters more than cost.
Context grows every round. Always set a max-iteration cap and a timeout.
No coordinator. Agents message each other directly and pass work around until a stop condition fires. Every agent has to know about every other agent.
Rarely. Debates, simulations, problems with no natural hierarchy.
The connections grow faster than the agent count. Hardest to debug: a last resort, not a default.
| Pattern | Who decides the next agent | Typical cost | Breaks when |
|---|---|---|---|
| Sequential | Fixed order, in code | Low · slow | An early stage is wrong |
| Parallel | Fixed fan-out, in code | High · fast | Results conflict at merge |
| Supervisor | The supervisor, as it goes | High | Briefs are vague |
| Dispatcher | The triage step, once | Lowest | The route is wrong |
| Evaluator-optimizer | The evaluator’s verdict | Grows per round | There is no stop condition |
| Peer-to-peer | Every agent | Highest | Coordination drifts |
Proving any of it works
Same agent, same 70%. One number says ship it, the other says not yet. pass^k comes from τ-bench (Yao et al., 2024).
“Fails” means fails your evals, not that it feels too simple.
Build all of this yourself, from the agent loop up, in the 12-week AI Engineering course.
