One agent or many?

Ask an AI system which of three laptops to buy for your office and it can answer from memory. Ask it to find out, and everything changes: it has to search, read pages, keep notes and decide what to do next. A model that works this way is called an agent, and most of the confusion about “multi-agent systems” starts right here.

This post follows one small job through five figures: compare three laptops for a five-person office and recommend one. You will watch one agent do it and run out of room, split the job across a team in three ways, see two workers contradict each other, and do the sums on why more agents can mean more mistakes. We lean on the published accounts of the people who built these systems; they disagree in useful ways. The laptops, the pages and every token count in the figures are invented, and each figure says so: they show the shape of a run, not a measurement. Anything from outside is named, dated and linked.

By the end of this post you will know:

• what an agent is, and why a long job makes it slow, costly and forgetful;
• what a lead with workers, a relay of specialists and a writer with a reviewer each gain and give up;
• when a second agent is worth adding, when it is not, and what the evidence says on both sides.

A chat answer is one step: a question goes in, text comes out. An agent runs a model in a loop with tools. On each turn the model reads everything so far, decides what to do next, and either answers or calls a tool such as a web search or a database query. The tool’s result is added to the same text, and the loop goes round again. Anthropic’s guide Building effective agents (December 2024) draws the line the same way: in an agent, the model directs its own process and its use of tools.

The tool can be anything: a document search like the one in How RAG finds answers, or a query against a database like those in Ask your database in Turkish. For our job it is a web search that hands back long pages.

So an agent is a chatbot with a search button? Nearly. What makes it an agent is the loop: the model, not your code, decides whether to search again, ask something else or answer. That choice repeats until the model decides it is done.

The job is to compare the Kestrel 14, the Heron 15 and the Plover 13 for a five-person office. The agent breaks it into six questions: price, battery and weight, warranty, owner reports of faults, stock and delivery, and whether the office’s accounting software runs. Each question costs one search and brings back one page. Press “Next turn”. On every turn the model first reads the whole transcript (watch a sweep run down it), then writes a short note and a search, and a page comes back. The top bar is the transcript; the bar under it is everything the model has read so far, on the same scale. Whatever the model writes and every page that returns is added to the same transcript, which started as just the task and the agent’s standing instructions (300 tokens).

This figure needs JavaScript. It shows one agent working through six questions about three invented laptops. The transcript starts at 300 tokens (the task) and grows to 12,990 tokens after seven turns. On each turn the model reads the whole transcript again, so over seven turns it reads 46,160 tokens in all, about 3.6 times the length of the finished transcript. The counts are invented.

Look at the two bars rather than the words. By the last turn the transcript is 12,990 tokens long, but the model has read 46,160 tokens in all, about 3.6 times as many, because every turn started from the whole story again. (A token is a short piece of a word, the unit a model reads and is charged for.) Nothing has gone wrong here. That is simply how a loop works, and it is why long jobs get slower and dearer than they look.

Why does it read everything again? Doesn’t it remember the earlier turns? Not by itself. A model only knows the text it is given on that turn. What looks like memory is the transcript being sent again. Some providers let you store the repeated start more cheaply, but the model still has to take all of it in, and all of it has to fit.

“Fit” is the problem. A model can only read so much at once; that limit is its context window. Ours is a toy, 8,000 tokens, so the effect fits on screen. Real windows are far larger, and so are real jobs: the team behind Anthropic’s multi-agent research system says (How we built our multi-agent research system, June 2025) that its lead agent saves its plan to memory because a context beyond 200,000 tokens gets cut off.

What happens when the window is full depends on the system. The simplest policy, the one drawn here, drops the oldest material to make room. Start with “One agent”: it plays once as the figure comes into view, and a dashed line marks the window. Then switch to “Lead plus workers”, where a lead hands each question to its own worker. A worker starts with a nearly empty context, does its one search and sends back a summary of about a hundred tokens, so the lead never sees the long pages. Both pictures use the same scale.

This figure needs JavaScript. It compares one agent with a lead and six workers on the same laptop job, in an illustrative window of 8,000 tokens. The one agent needs 12,660 tokens in its biggest turn, so its three oldest steps (prices, specs, warranty) fall out of the window before it writes the recommendation, and it reads 33,860 tokens in all (46,160 if nothing were dropped). The team never needs more than 2,960 tokens in one turn, forgets nothing, and reads 17,120 tokens in all, about 37 percent of what one agent with room for everything reads. The counts are illustrative.

Three things fell out of the one agent’s window: the prices, the specs and the warranty terms. It wrote its recommendation without them, and nothing in the transcript says that anything is missing. In the team, no model ever needs more than 2,960 tokens at once and nothing is lost, because a worker writes its summary while its page is still in front of it. That summary is exactly the note the single agent lost.

In the figure the one agent forgot its first three answers. What would have helped it most?

1. Reading every page twice, to be sure it picked up all the facts correctly.
2. Saving each note outside the transcript, so dropped pages cost nothing.
3. A model that remembers earlier turns without being shown them.

Show answer

The notes were the valuable part, and they fell out with the pages. A note kept somewhere that is not dropped (a file, a memory store, a worker’s summary handed to a lead) keeps the fact after the page is gone.

Not A: a second reading puts more tokens into the transcript, so the window fills sooner and more falls out.

Not C: a model only knows what is in the text of the turn. What looks like memory is the transcript, sent again.

Now the second number, and a fair comparison. Under the window the one agent read 33,860 tokens, not the 46,160 of the first figure, because the steps it dropped are no longer reread: that saving is paid for in forgetting. The like-for-like figure is what one agent with room for everything reads, 46,160. The team read 17,120, about 37 percent of that, because the one agent keeps rereading a growing transcript. So splitting a fixed job does not, by itself, make a team expensive. Something else does. Anthropic reports that agents use about four times the tokens of a chat and its multi-agent research system about fifteen times, and that token use alone explained about 80 percent of the differences in performance on one benchmark. Its summary: these systems work mainly because they help spend enough tokens on the problem. My reading, not theirs: a team lets you spend far more tokens in parallel without any one context overflowing, which is both why it can work better and why it costs more.

So a team is cheaper? That is not what I keep reading. Only in this tiny script, and only because it never takes on extra work. Real teams search wider, brief each worker, merge the results and sometimes repeat each other; Anthropic’s early versions even started dozens of workers for simple questions. It depends on how much more the team does.

Once you split a job you have to choose a shape. Three are common. In lead and workers, one model plans, hands pieces out and merges the results; Anthropic’s guide calls this the orchestrator-workers pattern. In a relay of specialists, each agent does one stage and passes its notes on, so the order is fixed in advance. In a writer and reviewer, one model does the work and another checks it in a loop, which the same guide calls an evaluator-optimizer. In that guide the first and the last are workflows, paths set up in code; it keeps “agent” for a model that picks its own steps. Workflows suit well-defined jobs that need predictability, agents suit open-ended ones, and agents cost more.

Choose a pattern, then press “Next round” until it is done, and do it for all three. Watch two counters: the turns in a row (how many steps have to wait for each other) and the messages sent.

This figure needs JavaScript. It is a scripted example of the same laptop job run three ways. A lead with six workers takes 3 turns in a row and sends 12 messages. A relay of a researcher, an analyst and a writer takes 8 turns in a row and sends 2 messages. A writer and a reviewer take 9 turns in a row and send 2 messages.

The three patterns do about the same amount of work: eight agent turns for the lead and the relay, nine for the writer and reviewer. What differs is the shape. The lead and workers finish after three turns in a row, because six workers search at once, but they send twelve messages, and every message is a chance to be vague or lost. The relay sends only two messages, yet its first stage is six turns in a row. The writer and reviewer take nine turns in a row for two messages, which buys a second look at the draft.

That second look has some support. In a paper first posted in May 2023 and presented at ICML in 2024, Du and colleagues had several copies of one model each propose an answer, read the others’ and revise, and report better reasoning and fewer false facts than a single model in their tests. That is debate between copies of one model, not a team of tool-using agents, so it shows that a second look can help, not that teams always win.

Then why not put a reviewer on everything? A reviewer is another model, with its own slips and its own bill. The last figure in this post shows what a checker buys and what it costs.

The strongest argument against the lead-and-workers shape came from Cognition, the company behind the coding agent Devin. In Don’t Build Multi-Agents (12 June 2025), Walden Yan argues that every action a model takes carries decisions nobody wrote down, and that workers who cannot see each other’s decisions end up making conflicting ones. His example: a Flappy Bird clone split between two workers, one of which built a Super Mario style background while the other built a bird that looked and moved nothing like Flappy Bird’s, leaving a final agent to reconcile the pair.

Here is the same trouble in our laptop story, scripted and invented. Both workers get the same brief. Read their sections with “They work apart”, then switch to “They share a notes page”.

This figure needs JavaScript. It is a scripted example. Two workers write the cost section and the support section of one report. Working apart, the cost worker takes “best” to mean cheapest to buy and recommends the Plover 13, while the support worker takes it to mean the strongest support and recommends the Heron 15, so the report disagrees with itself. Sharing a notes page, both rank by cost over three years with repairs included (Kestrel 1,300, Heron 1,320, Plover 1,380) and both recommend the Kestrel 14. The laptops, prices and repair costs are invented.

Neither worker did anything wrong. Each answered its brief and was right on its own terms. What differed was a choice neither wrote down: what “best” means. One shared line was enough to fix it here, but real jobs are full of such choices (names, style, units, what to assume), and most are never written down.

Couldn’t the lead just tell both of them what “best” means? Often, yes, and good briefs matter: Anthropic says vague instructions to its workers led to duplicated work. But the lead can only write down the choices it already knows will matter, and the ones that bite are the ones nobody saw coming.

What caused the clash in the figure?

1. The cost worker made a calculation error that the support worker did not make.
2. The lead asked the two workers for different recommendations.
3. Each worker quietly chose its own meaning of “best”.

Show answer

Both sections are right for the rule they used. The conflict sits in a choice nobody wrote down; with one shared note about the rule, the same two workers agree.

Not A: the arithmetic in both sections checks out. Run it again with the other worker’s rule and you get the other worker’s answer.

Not B: the brief was the same for both, word for word. The difference came afterwards, in what each worker assumed.

Cognition’s advice in 2025 was to default to a single, linear agent, and for jobs too long for one context to add a step that compresses the history into key details, which Cognition says is hard to get right. That was not the end of the story. In April 2026 Yan published a follow-up, Multi-Agents: What’s Actually Working. It keeps the warning for several agents writing at once, and describes narrower patterns that work: several agents add intelligence while one agent does the writing, for example a reviewer that starts with a clean context and checks a coding agent’s output. It also describes a manager that splits a large task and hands the pieces to child agents, which it presents as work in progress.

The next cost is plain arithmetic. Suppose each handoff keeps the work right 90 percent of the time. For the final answer to be right, every handoff has to be right, and chances multiply: six handoffs give 0.9 six times over, which is 53 percent. Anthropic’s guide lists compounding errors among the costs of agents, and its research team says that agents are stateful and errors compound, so they built the system to resume from where an agent was instead of starting over.

Slide “Handoffs” and “Right per handoff”. The dashed line is a made-up baseline: one agent alone gets the job right 70 percent of the time. Find where the first bar drops below it. Then look at the second bar, where a checker catches 70 percent of the slips and sends them back.

This figure needs JavaScript. It is a model: with six handoffs that are each right 90 percent of the time, the final answer is right 53 percent of the time without a checker. A checker that catches 70 percent of slips raises that to 82 percent, for about 13 agent turns instead of 6. One agent alone is assumed to be right 70 percent of the time.

At 90 percent per handoff, a chain beats the baseline up to three handoffs (0.9 cubed is 0.729) and falls below it at four (0.656). A checker rescues a lot: at six handoffs it lifts 53 percent to 82 percent, but it more than doubles the work, 13 turns instead of 6, because every attempt is also checked and every caught slip is redone. And look at what the figure assumes. The errors are independent, the checker never flags good work, and “70 percent” is a number I chose, standing for one agent’s whole run, its own slips included. In real life those are the things you have to measure.

A checker is a model too. What if it is wrong? Then it lets some slips through, and a real one also flags some good work, which costs more turns. The figure’s 70 percent is an assumption, and it is the whole game: measure it.

Six handoffs in a row, each right 95 percent of the time, and no checker. About how often is the final answer right?

1. About 74 percent.
2. About 95 percent, the same as one handoff.
3. About 30 percent, because six is a lot.

Show answer

Every handoff has to go right, so the chances multiply: 0.95 six times over is about 0.735, or 74 percent.

Not B: 95 percent is the chance for one handoff. Each further handoff multiplies in another chance to go wrong.

Not C: that would take handoffs much worse than 95 percent. At 82 percent each, six in a row do give about 30 percent.

Here is the case for, as its authors tell it. Anthropic’s multi-agent research system, with one Claude Opus 4 as lead and several Claude Sonnet 4 as workers, beat a single Claude Opus 4 by 90.2 percent on the team’s internal research evaluation (June 2025). The post says that running workers in parallel cut research time by up to 90 percent on complex queries. Note who measured it: the company that built it, on its own test.

The same post says the pattern fits high-value jobs with heavy parallel work, information that does not fit one context window and many complex tools, and does not fit jobs where agents need the same context or depend on each other a lot: most coding, it says, has fewer parts that can run in parallel than research does.

Now the case against. Cognition’s argument you have seen. There is also a study by Cemri and colleagues at Berkeley (first posted March 2025, latest version October 2025). They collected more than 1,600 annotated runs of seven popular multi-agent frameworks and sorted the failures into 14 kinds in three groups: problems with system design, misalignment between agents, and weak checking of the result. They note that the gains of multi-agent frameworks on popular benchmarks are often minimal, and they see opportunities for improvement through better design, though the failures need more sophisticated solutions.

So who is right, Anthropic or Cognition? They describe different jobs. Anthropic’s workers mostly read: they search and report, and the lead writes the answer. Cognition worried about workers that all change the same thing at once. My reading, not theirs: put together, what both sides now describe is closer to many readers and one writer, though Cognition’s 2026 post also leaves room for a manager handing work to child agents.

From these sources, here is a short decision list. A second agent starts to make sense when:

• the job splits into questions that can be answered separately, each needing a lot of reading;
• the information will not fit in one context, or fills it with pages of which you need only a summary;
• a second look can be checked against criteria you can write down;
• and the job is valuable enough to pay for the extra tokens: Anthropic says the cost only makes sense when the value of the task justifies it.

Stay with one agent when the parts depend on each other, when the work is mostly changing one thing (most coding), or when you cannot name the problem a second agent would solve. Anthropic’s guide says to find the simplest solution that works, which may mean no agent at all: a single model call with retrieval is often enough.

If you do build a team, log what you will need on the day two workers disagree: who sent what to whom, the brief each worker was given, what it returned, the tokens it used and any tool that failed. Anthropic’s team traces every run and suggests starting with about twenty test questions; for agents that change things, it recommends checking the end state.

A model in a loop can do a lot. Several can do more, cost more, and disagree in ways one cannot. Start with one agent. Add another only when you can name the problem it solves: a context that overflows, questions that can be answered side by side, a check that catches mistakes you can describe. Then measure whether it did.

Read on 14 October 2026. This field changes fast; check the dates.

• Anthropic Engineering, Building effective agents, 19 December 2024. Company engineering blog.
• Anthropic Engineering, How we built our multi-agent research system, 13 June 2025. Company engineering blog, results measured by its authors.
• Walden Yan (Cognition), Don’t Build Multi-Agents, 12 June 2025. Company blog.
• Walden Yan (Cognition), Multi-Agents: What’s Actually Working, 22 April 2026. Company blog.
• Yilun Du, Shuang Li, Antonio Torralba, Joshua Tenenbaum and Igor Mordatch, Improving Factuality and Reasoning in Language Models through Multiagent Debate, arXiv 2305.14325, 23 May 2023 (ICML 2024, peer reviewed).
• Mert Cemri and colleagues, Why Do Multi-Agent LLM Systems Fail?, arXiv 2503.13657, first posted 17 March 2025, latest version 26 October 2025. Preprint.