AI Agent Architectures: Workflows, Subagents, and Multi-Agent Systems

01Who decides the next step

Anthropic published the clearest version of this in December 2024 and it has held up.

A workflow is a set of steps you wrote out ahead of time. The model does the thinking inside each step, but you decided what the steps are and what order they run in.

An agent gets a goal and works out its own steps as it goes. Which tool to use, what to do next, when it's finished.

A recipe versus a cook. With a recipe you made every decision and the cook carries them out. With a cook you say "make dinner" and hand the decisions over.

Both get called agentic systems. The only real difference is who decides what happens next: you, in code you wrote, or the model, while it's running.

The trade runs both ways. Workflows are predictable and easy to fix when they break, and they fall over on anything you didn't think of. Agents handle what you didn't think of, and you give up knowing in advance what they'll do. Every extra turn a model takes on its own makes the job slower, costs more, and gives an early mistake another chance to spread into everything after it.

Anthropic's own advice is to use the simplest thing that passes your tests, which is often a workflow or even one well-equipped model call, and to save agents for jobs where you can't write the steps out in advance but you can still check whether it's getting somewhere.

Most reliable systems running in production today are workflows, not agents deciding everything for themselves. Worth knowing before you buy something sold on autonomy.

02The building block everything is made from

Before any of the patterns there's what Anthropic calls the augmented LLM. That's a model with three things attached: it can look things up, it can use tools, and it can remember.

That isn't an agent yet. It's the unit the rest of this is built out of.

03The five workflow shapes

All five count as workflows, because in each one you wrote the order.

Prompt chaining. Break the job into steps that run one after another, with a check in code between each one. Step one drafts, step two checks it, step three formats it. Simple, and mistakes get caught early because you can stop it at any step.

Routing. Sort the request first, then send it to a prompt built for that kind of request. Support questions go one way, refund requests go another. Works when the categories are genuinely distinct.

Parallelization. Running things at the same time, in one of two ways that constantly get mixed up. Sectioning splits a job into separate pieces that run side by side, which buys speed. Voting runs the same job several times and compares the answers, which buys confidence.

Orchestrator-workers. One model reads the job, breaks it into pieces on the spot, hands each piece to a helper model, then puts the answers back together. This is the one people mean when they say subagents.

Evaluator-optimizer. One model writes, a second marks it, and it loops until the work is good enough. Works when you can say clearly what good means.

Real systems mix these. A router at the front feeding into orchestrator-worker setups, each one checking its own output. The shape comes out of the job.

04What subagents are actually for

Subagents live inside the orchestrator-worker pattern, and the reason they exist is room, not horsepower.

A model can only hold so much text in mind at once. That limit is called the context window. Point one model at a research question with a hundred sources and it has to squeeze everything down to fit, and squeezing too hard loses the details that mattered.

Subagents get around that. Each one has its own window, works on a different piece at the same time, and sends back a short summary. The model in charge never has to hold all hundred sources at once.

There's a second benefit that gets less attention. One agent that takes a wrong turn early tends to stay on that road, because everything it does afterward is built on the first bad step. Five agents looking independently don't share that wrong turn.

05Subagents and multi-agent systems are not the same thing

People use the two interchangeably. They're different.

In orchestrator-workers, the helpers get created on the spot. The model in charge decides what this particular job needs, spins them up, and they're gone when it's done. No names, no history.

In a multi-agent system the agents are permanent, and each one has a job. A research agent always does research. A critic agent always evaluates. They exist whether or not there's work to do.

Grok Bot's named bots are the second kind. Anthropic's research system is closer to the first. It matters because permanent specialists build up their own memory and their own bad habits over time, and temporary helpers aren't around long enough to.

06The argument nobody settled

In June 2025, Cognition, the team behind Devin, published a post called Don't Build Multi-Agents. Their case: splitting a job across several agents is fragile, because each one only sees part of the picture and they end up making decisions that contradict each other. Their fix is what people call context engineering, which just means being deliberate about what information the model has in front of it at each moment.

The next day Anthropic published How we built our multi-agent research system, describing close to the setup Cognition said not to build and arguing it was necessary for hard research questions. On their own research evaluation, a lead Opus 4 agent with Sonnet 4 helpers beat a single Opus 4 by 90.2%.

It got read as a fight, and it partly is. They also agree more than the coverage suggested.

Anthropic's post says multi-agent is a poor fit when every agent needs the same information, or when the pieces of the job depend on each other. It names coding as the example.

Cognition builds a coding agent.

So the disagreement is narrower than it looked. Both think coding wants one agent with everything in front of it. Both think open-ended research, where you can go down several roads at once, is a different shape. They disagreed about which jobs, published a day apart, and got read as a holy war.

What I take from it is one question. Can the pieces of your job be done without knowing about each other? If piece B needs to know what piece A found, splitting them costs more than it buys.

07What the evidence says

The most careful work here is a study called MAST, from a Berkeley team led by Mert Cemri, with Matei Zaharia, Joseph Gonzalez and Ion Stoica among the co-authors. They recorded seven popular multi-agent systems doing coding, math and general tasks, on both GPT-4 and Claude models. Human experts went through 150 of those recordings and built a catalog of the ways things went wrong, agreeing with each other almost every time, then applied it to more than 1,600 runs.

Their opening line is blunt: despite the enthusiasm, the gains over single-agent systems on popular benchmarks are often minimal.

Across those seven systems, between 41% and 86.7% of runs failed.

They found 14 distinct ways to fail, in three groups. Roughly 42% came from the system being set up badly in the first place. About 37% came from agents talking past each other. About 21% came from nobody checking the work.

The biggest group is setup, not capability. The two most common individual failures are agents redoing work they had already done, and an agent reasoning its way to the right answer and then doing something else.

A 2026 paper by Dat Tran and Douwe Kiela ran one agent against several on questions that take a few steps to answer, and did the thing most comparisons skip. It gave both sides the same amount of thinking to spend. Across three families of models, the single agent matched or beat the multi-agent versions almost every time. Which suggests some multi-agent wins are really the multi-agent version being allowed to think for longer.

Google Research tested five different setups across three model families and followed what happens to one small mistake. Agents working in parallel with nobody checking them amplified errors 17.2 times over. Put one agent in the middle whose job is to check everything before it moves on, and that drops to 4.4 times. If you split work, something in the middle has to check.

Then the cost. Anthropic's own numbers: a multi-agent setup uses about 15 times the tokens of a single chat, and a plain agent about 4 times. That's a budget decision.

08The harness, and why it makes benchmarks slippery

The harness is everything wrapped around the model. Which tools it can reach, how its instructions get put together, how it actually runs things, and what it sees when something fails. Same model, different harness, different behavior.

Recent evaluation work found the harness explains more of the difference in results than the choice of model does, and that the same model scores differently depending on which one it's sitting in. The recommendation is to report a score as model-plus-harness rather than crediting the model on its own.

So when someone tells you a model is good at agent work, ask which harness. The claim doesn't mean much without it.

09The words, in one place

Agentic system. Umbrella term. Means almost nothing on its own.

Workflow. You wrote the steps. The model does the thinking inside them.

Agent. The model decides the next step while it's running.

Augmented LLM. A model that can look things up, use tools and remember. The building block.

Context window. How much text a model can hold in mind at once.

Subagent. A temporary helper created for one job, with its own context window, gone when the job is done.

Orchestrator-worker. The setup where that happens. One model in charge, several helpers.

Multi-agent system. Permanent agents with names and specialties.

Harness. Everything around the model. Tools, instructions, how it runs, what it sees when it fails.

Tool use. The model calling a function you gave it. Not autonomy on its own.

Context engineering. Being deliberate about what information the model has in front of it at each step.

ReAct. The loop most agents run on. Think, do, look at what happened, repeat.

10How I'd choose

Start with the simplest thing that passes your tests. That's Anthropic's advice, and the MAST numbers back it up, because most failures came from bad setup rather than a weak model.

Ask whether the pieces of your job are genuinely independent. If piece B needs what piece A found, you want one agent with its information well managed, not five agents and a coordination problem.

If the pieces are independent and the work is broad and open-ended, subagents earn their cost. Research is the clearest example. Coding mostly isn't, and both sides of the famous argument agree on that.

If you do split the work, put something in the middle to check it. The gap between errors growing 17 times over and errors growing 4 times over is a checking step.

And budget for roughly 15 times the tokens before deciding multi-agent is worth it.

The numbers say most of these systems fail because of how they were set up, not because the model wasn't smart enough. So the fix for a broken agent system is usually clearer instructions and better boundaries between tasks, and almost never a bigger model.

Sources

Anthropic, Building Effective Agents (December 19, 2024) for the workflow-versus-agent distinction, the augmented LLM and the five patterns. Anthropic, How we built our multi-agent research system (June 13, 2025) for the subagent rationale, the token multiples, the 90.2% eval result and the coding caveat.

Cognition, Don't Build Multi-Agents by Walden Yan (June 2025).

Cemri et al., Why Do Multi-Agent LLM Systems Fail? (arXiv 2503.13657, NeurIPS 2025) for MAST, the failure categories and the failure rates. Tran and Kiela, Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets (arXiv 2604.02460). Kim et al., Towards a Science of Scaling Agent Systems (Google Research, arXiv 2512.08296) for the error amplification figures. Harness findings from Harness-Bench (arXiv 2605.27922).

Anything wrong here is mine.