Everyone wants an autonomous agent. Often the right answer is a boring workflow.

1. Why now: the architecture question

Every AI system has a shape. At one extreme the steps are fixed in code and the model is called at set points. At the other the model runs the show, deciding each move as it goes. Choosing between those, and everything between them, is the architecture question, and it decides more about cost and reliability than the model does.

The reason to get precise now is that the vocabulary finally exists. Anthropic's "Building Effective Agents", published at the end of 2024, gave the field clean names, workflows and agents, and five patterns, and those names have become the way serious teams talk about design. This dossier uses that vocabulary to walk through the real trade-off of 2026: the pull toward autonomous, multi-agent systems that are powerful, impressive, and quietly very expensive. Get the shape right and a modest model does the job cheaply; get it wrong and an expensive team of agents burns budget doing what a simple recipe would have done for a fraction of the cost.

2. Workflow or agent

Start with the fork in the road.

A workflow is a system where the steps are fixed in advance, in code. The runtime executes a script you wrote, calling the model at defined points. It is predictable, cheaper, and easy to debug, and it is the right choice whenever you know the steps ahead of time. An agent is a system where the model decides what to do next, turn by turn, choosing its own tools and its own path. It is flexible and powerful and harder to predict, and it is the right choice when the steps genuinely cannot be known in advance. Take one task and build it both ways to feel the difference:

The mistake almost everyone makes is reaching for the agent when a workflow would have been simpler, cheaper and more reliable. "Autonomous" sounds advanced; "a script with five steps" sounds boring. In production the boring one often wins.

3. The five patterns, with real tasks

Between those two poles, Anthropic named five patterns that, in practice, cover almost everything you will build. They are easiest to learn attached to a real task each.

Read the right-hand column and each pattern stops being abstract. Prompt chaining reduces errors by giving each call less to do. Routing puts the right specialist on each job. Parallelization buys speed and breadth. Orchestrator-workers is the pattern behind most impressive multi-agent systems, a lead directing a team. And evaluator-optimizer is the loop from part one made explicit, a generator and a critic passing work back and forth. Five shapes, and you rarely need anything more exotic than a combination of these.

4. The patterns compose

The reason five patterns go so far is that they compose. They are not five separate architectures to choose between; they are building blocks that nest inside one another. A routing step often feeds a prompt chain. An orchestrator delegating to workers frequently wraps an evaluator-optimizer loop at each worker, so every worker checks its own output before reporting back. A parallelization step can sit inside any of the others. Real systems are usually two or three of these patterns layered together.

Take a content pipeline as a small composed example. Routing decides whether an incoming request is a blog post, a product description or an ad. If it is an ad, an orchestrator splits it into a headline, body and call-to-action, hands each to a worker, and each worker runs an evaluator-optimizer loop, draft, critique, redraft, until its piece passes. That single pipeline is three patterns nested together, and none of them is exotic. This is why the vocabulary matters more than any single diagram: once you can name the pieces, you can describe any AI system as a combination of them, and you can look at one that is not working and ask which piece is the problem. Almost every over-engineered agent is a case of using a heavier pattern where a lighter one, or a plain workflow, would have done the job.

5. Multi-agent: the power and the price

The most talked-about pattern is orchestrator-workers taken to its limit: a lead agent directing a whole team of subagents, each working in parallel. It is genuinely powerful, and it is worth being precise about both the power and the price.

Anthropic reported that a multi-agent setup, a lead model directing subagents, beat a single agent on its internal research task by about ninety percent. That is a large gain. It also came at a cost, and the cost is best seen as plain arithmetic:

That last line is the whole decision. Multi-agent burns roughly fifteen times the tokens of a simple chat, and token spend alone explained around eighty percent of the performance difference, which is another way of saying that most of what you buy with multi-agent is simply more thinking, in parallel, at a price. For a high-value research question, fifteen times the cost for a ninety-percent-better answer is a bargain. For a routine lookup, it is a waste. The pattern pays off when the value of the task clears the cost of the tokens, and not before.

6. When to fan out

So when is a team of agents actually the right call? The honest answer is narrower than the hype suggests.

Fanning out works when the task genuinely splits into independent parts, when breadth matters more than a single deep line of reasoning, and when the task is valuable enough to justify the token bill: research, wide search, gathering from many sources at once. It works badly when every agent needs the same shared context, when steps depend tightly on one another, or when the task is low-value or latency-sensitive. Anthropic's own note is telling: most coding is a poor fit for multi-agent, because coding steps are tightly coupled, each change depends on the last, so splitting the work across agents that cannot see each other's changes creates chaos. Research fits well because it naturally splits: three subagents can each investigate a different competitor without stepping on each other. Before fanning out, ask two questions: does this actually parallelise, and is it worth the cost? Many tasks are neither, and a single agent or a plain workflow is the right answer.

7. A real system: how a bank wired it

It helps to see the patterns assembled in the wild. JP Morgan's investment-research team described their internal system, "Ask David", and it is a textbook composition of the ideas in this series.

Read from the top: a supervisor agent orchestrates the work; specialised subagents each handle one job, retrieval, structured data, analytics; before any answer ships, a reflection step, an LLM acting as a judge, checks it; and a human stays in the loop for the last stretch of accuracy the machine cannot guarantee alone. That is orchestrator-workers, plus evaluator-optimizer, plus a human gate, four of the ideas in this series composed into one system. It is also the shape that keeps appearing across serious deployments: a lead that plans, specialists that execute, a judge that checks, and a person who owns the final call. When you know the vocabulary, you can see the same skeleton under most production agents, and you can copy it.

8. Start simple

All of which points at the single most important discipline in this area, and it is the one most teams ignore: start simple.

The instinct is to begin with the most autonomous, most impressive option, a free-roaming agent with many tools, because it demos well. In production that is where unpredictability and cost live. Anthropic's own guidance runs the other way: begin with a single call or a fixed workflow, and add autonomy only where it demonstrably improves the outcome. In practice that looks like a ladder. Try a single prompt first. If the task needs a few reliable steps, use a workflow. If it needs to react to what it finds, give it an agent. If the work genuinely splits and is worth the cost, only then reach for a team. Each rung up buys flexibility and costs money and predictability, so you climb only as far as the task actually requires. Complexity is a cost you pay on every run, not a badge you earn for building something sophisticated.

9. Who chooses, you or the model

There is a twist worth naming, because it changes how this plays out in practice. Increasingly, the model chooses the pattern itself. Given a task and the right tools, a capable model will decide whether to answer directly, spin up subagents, or run a verification loop, and it often combines them mid-task without being told to. Ethan Mollick made this point about the newest agent-team features: much of the decision about which approach to use is now made by the AI rather than the human.

That does not make the vocabulary obsolete; it makes it more useful. If the model is choosing among these patterns, then understanding them is how you supervise its choices. You can look at a transcript and see that it spun up five subagents for a question a single lookup would have answered, and rein it in. You can set the guardrails, budget caps, scope limits, a rule that says "do not fan out unless the task clears this bar", that keep its autonomy economic. You are moving from writing the orchestration by hand to governing an orchestration the model runs, and you cannot govern what you cannot name.

10. The honest counter-case

Three qualifications keep this honest. First, the workflow-versus-agent line is blurring: as models get better at planning, the reliable, predictable behaviour you once needed a hand-coded workflow for can increasingly be trusted to an agent, so the balance keeps shifting toward autonomy over time. What is over-engineering today may be sensible next year. Second, the token-cost numbers are directional, not laws: they come from specific tasks, and the economics change every time models get cheaper, which they keep doing, so a multi-agent design that is uneconomic today can become worth it as prices fall.

Third, simple is a guideline, not a dogma. Some genuinely complex, valuable, parallelizable problems do need a team of agents, and refusing to use one out of minimalism is its own mistake; the research question that beats a single agent by ninety percent is real. The through-line survives all three: the right architecture is the simplest one that reliably does the job, and the cost of complexity is real and worth counting. Reach for autonomy and multi-agent when the task earns them, and not because they are the impressive thing to build.

11. What a business does with this

For a leader, this is a lens for reading any AI proposal that lands on your desk. When someone pitches an ambitious multi-agent system, the questions are now concrete, and you do not need to be technical to ask them. Could this be a simple workflow instead? Does the task actually parallelise, or is it being fanned out because that sounds advanced? Is there a judge step and a human gate, as in the bank's system? And has anyone counted the token cost against the value of the task? Those questions separate a system that will work and pay off from one that will impress in a demo and bleed money in production.

This is See, Understand, Adopt applied to how AI work is arranged. See whether a given system is a workflow or an agent, and which of the five patterns it is made of. Understand that autonomy and multi-agent are powerful and expensive, and that the discipline is to start simple and climb the ladder only as far as the task requires. Then adopt by matching the architecture to the task, buying complexity only where the value is clearly there. The teams that win run the fewest agents that do the job, not the most.

12. Verification and sources

This dossier draws on live web research and a personal archive of more than 15,000 sources. Load-bearing numbers were cross-checked where possible. The pattern examples, the token arithmetic and the Ask David diagram are illustrative, built to explain the mechanics. The notes below flag confidence and the main caveats, in the spirit of showing our work.

Charts labelled "BFF" are our own, drawn from the sources named beneath them. The pattern-task table, the token example and the Ask David diagram are illustrative, written to teach the idea.