The question
My hunch is that for most connected work, one capable agent working through a task in order beats a team of agents on both accuracy and cost. The industry's enthusiasm for multi-agent setups deserves more questions than it gets.
Every agent framework now ships with orchestrators, planners, critics and sub-agents fanned out in parallel. The demos look great: ten agents, ten panes, all busy. But each of those agents reads its own copy of the context, writes its own reasoning, and bills its own tokens. When the company selling the framework also sells the tokens, it is fair to ask whether "use more agents" is advice or a sales pitch.
I'm not against multi-agent systems. I build CricCuts, an Android app that turns raw cricket footage into highlight reels, and I work with an AI coding agent every day. What I've noticed is that the jobs that go well are rarely the ones I split up. This post is me working out when splitting pays, and when it only makes the bill bigger.
What a team of agents costs
By the industry's own numbers, a multi-agent system burns about 15 times the tokens of a chat. A single agent burns about 4 times.
Those figures come from Anthropic's engineering post How we built our multi-agent research system (13 June 2025). The same post reports that a lead agent with sub-agents beat a single Claude Opus 4 agent by 90.2% on their internal research eval. It also found that token usage alone explained 80% of the variance in performance on the BrowseComp benchmark.
Read one way, that says more agents give better answers. Read another way, much of the gain is simply spending more tokens. Both readings are true, and that is the point: you are buying results with tokens, so you should know what each token buys.
The extra tokens come from four places:
| Where it goes | What happens | What it costs |
|---|---|---|
| Duplicated context | Every sub-agent re-reads the instructions, conventions and the files it needs. My project's guide file loads into every session and every sub-agent. | Tokens |
| Coordination | The lead writes briefs, reads reports and merges them. That is work about the work. | Tokens |
| Verification fan-out | "Each finding checked again" can double the number of agents. | Tokens |
| Lossy hand-offs | A sub-agent returns a summary, not its reasoning. What it noticed but didn't write down is gone. | Accuracy |
The first three show up on the bill. The fourth doesn't, and it's the one that worries me most.
A case study: one agent, one long run
I gave one agent a whole release-day checklist and turned down the multi-agent review it recommended. It finished everything unattended in about two hours and twenty minutes.
The agent was Claude Code, on the CricCuts repo. Before I stepped away, I asked it to:
- review the 31 commits since my last Play Store closed-test submission, and make sure they were consistent and bug free;
- put the app's new tagline in every logo, on the website and in the store listing;
- update the Play Store documents and plan the screenshots and phone recordings;
- back up the tablet's database, install a release build, and use the tablet for testing and recording.
Before it started, the agent asked how deep the review should go. It offered two options:
Multi-agent workflow (recommended)
- "About 6–8 reviewer agents split by area (export/FX, Trim, recorder, Academy, Home/nav, Play docs), each finding checked again. Most thorough; uses noticeably more tokens."
Inline
- "I read the diffs myself, area by area. Cheaper, slower, and more likely to miss things."
I picked inline. Note that the agent itself recommended the team. These are the run's numbers, taken from the session transcript:
| Measure | Value |
|---|---|
| Model calls | 315 |
| Tool calls by kind | 252 shell commands, 59 file reads, 19 edits and writes |
| Context compactions during the run | 0 |
| Output tokens | about 243,000 |
| Input served from the prompt cache | about 137 million tokens, over 99% of all input |
| Commits pushed | 6 |
What that one agent produced:
- The review. It confirmed a database migration and checked that a block moved during a merge matched both parents line for line. It found and fixed two real problems: a stale "What's new" edition that would have hidden the new release card from people updating, and a sign-in subtitle still carrying the old slogan.
- The branding. It redrew the tagline in about eight image assets (splash, logos, social cover, store feature graphic) and rebuilt the logo animation.
- The store. It wrote a 3,938-character description and 431-character release notes, and planned 8 phone screenshots and 14 phone recording takes.
- The device. It backed up the tablet, installed the release build, walked through a fresh install and three exports, and recorded a lesson for the app's Academy video.
- The tests. The unit suite passed: 3,985 tests, 0 failures.
It also got past the small snags any long run hits. One was a phone-maker install prompt that denies itself on a timer. Another was a broken Python imaging library, so it rendered the images in headless Chrome instead.
I can't prove that eight reviewers wouldn't have found a third bug. What I can say is that the two problems it found were real, the run cost one agent's tokens, and every decision sat in one history I could read when I came back.
Why related work wants one mind
When steps depend on each other, each step carries decisions the next one needs. A hand-off between agents throws most of them away.
Walden Yan of Cognition made this case in Don't Build Multi-Agents (12 June 2025), as two principles. First, share context, and share full agent traces, not just individual messages. Second, actions carry implicit decisions, and conflicting decisions carry bad results. His example splits "build a Flappy Bird clone" between two sub-agents. One builds a background closer to Super Mario Bros. The other builds a bird that matches neither. The last agent is left to glue two mismatched halves together.
My release run was full of these hidden links:
- One change, many surfaces. The tagline touched app code, about eight images, the website and the store listing. One agent kept the words and the lettering the same everywhere.
- The review fed the paperwork. What the review checked became the "where 1.2 stands" section of the Play Store document.
- The device pass tested what the review read. The two fixes were inside the build it installed and walked through.
- The rules applied to every step. Other sessions share my checkout, so commits must name exact file paths. No test may submit a real form to production. Every sub-agent would need these rules, and one that forgot them could do real damage.
There is a subtler problem too. My codebase has logic that must be kept in step by hand in several places. Its bugs live in the seams between areas. A review split by area gives each reviewer one side of each seam, so by design nobody looks at the seam itself.
Reading the diffs in order is also how a careful human reviewer works. With a fast model, sequential is not the same as slow.
What the brain already knows
The parallels are real, with one twist. Psychology has long found that people decide one thing at a time and pay for every switch. The twist is that we split work across teams because no single head can hold it all, and an agent's head now can.
| Finding | What the research says | The agent parallel |
|---|---|---|
| The central bottleneck (Pashler, 1994) | Dual-task studies point to "a stubborn bottleneck encompassing the process of choosing actions and probably memory retrieval". The hardest limit sits at choosing what to do next. | An agent can fire off searches and file reads at once, as long as the decisions stay in one mind. |
| Switching costs (Rubinstein, Meyer and Evans, 2001) | Switching tasks costs time, more for complex rules and less with clear cues. Their model has two stages: shift the goal, then activate the rules. | Every hand-off is a switch. A new sub-agent loads the project's rules from scratch, and a vague brief is a weak cue. |
| Attention residue (Leroy, 2009) | When you switch between work tasks, part of your attention stays behind on the one you left. | This one cuts against a single agent. A long context carries residue from earlier work, and the 2023 study Lost in the Middle found models use the start and end of a long context best. Compaction, and a fresh session for unrelated work, are the fix. |
| Practice unlocks parallel (Schumacher and others, 2001) | After modest practice, some people time-shared two simple choice tasks "virtually perfectly". | Simple, routine, independent tasks are exactly the ones that split well. |
| Brooks's law (Brooks, 1975) | "Adding manpower to a late software project makes it later." Some tasks can't be split up easily, and the lines of communication grow fast as people join. | Eight agents that all talk to each other make 28 pairs. A lead agent avoids that mesh, but then every report squeezes through one context. |
Earlier on this blog, in Why the future of AI might be many small models, I described the nervous system as a team of specialists: reflexes run locally, deliberation runs centrally. This post doesn't take that back. The specialists are the parallel part, and they take things in. The deliberation is the narrow part, and it decides. Many small models can sense; one mind should choose.
Where the analogy breaks. Working memory holds about four chunks, according to Cowan (2001). That tiny span is part of why we split big jobs across people: no single head can hold a whole release. My agent held about 624,000 tokens. The old reason to split, capacity, has mostly gone. The reasons to stay in one thread, decisions and switching, remain.
Models are not brains, so these are parallels, not proof. Still, both point the same way: take things in widely, decide in one place, and switch as little as you can.
Where multi-agent earns its keep
Splitting pays when the pieces truly don't need each other's context, or when keeping contexts apart is the point.
Anthropic's research post is honest about this. Its system shines on broad questions that break into independent directions, and the same post says most coding tasks have fewer truly parallel parts than research does. These are the cases where I'd reach for more than one agent:
| Situation | Why splitting helps | Example |
|---|---|---|
| Broad research | Each thread is independent, and the lead only needs the conclusions | Surveying twenty competing apps, one agent per app |
| Independent features | No shared files, so no shared decisions | I already run separate sessions on separate features, and I act as the orchestrator |
| A fresh-eyes check | A reviewer that never saw the author's reasoning can't inherit its blind spots | One sceptical agent reads the finished work cold |
| Keeping the main context clean | A search that reads fifty files can hand back one paragraph | A cheap search agent finds where something lives |
| A cheaper model for simple work | Routine sub-tasks don't need the biggest model | A small model sorts logs or files for the main agent |
| Wall-clock deadlines | When the hour matters more than the bill | A launch-day fix across unrelated modules |
The parallel sessions are the telling case. They work because I split by feature, not by layer, and the risky moment is always the merge. This week one session's camera effect landed in the middle of another session's shot-picking work, and the merge needed a careful line-by-line check. That is the hand-off cost, paid in my own time instead of tokens.
The fresh-eyes check is the other telling case. It is the one place where not sharing context is the whole idea.
How bigger contexts, faster models and better harnesses move the line
Three changes have moved the line toward one agent: context windows that hold a whole job, caching that makes a long context cheap to re-read, and harnesses that manage the context for you.
The window got big enough. My run peaked at about 624,000 tokens and never had to compact. With the 128,000 to 200,000-token windows of a couple of years ago, it would not have fit in one context. Splitting was once a necessity. For a job this size, it is now a choice.
Re-reading got cheap. A long session re-sends its whole history on every call, which sounds ruinous. Prompt caching changes that. On Claude Opus 5.5, a cache hit is billed at 0.05 times the base input price, according to Anthropic's prompt caching docs. So my run's 137 million cached tokens billed like about 7.5 million fresh ones, writes included. A new sub-agent starts cold: it builds its own context and pays the cache-write premium on it before it reads anything cheaply.
The harness carries the memory. When a context does fill up, the harness compacts it into a summary and carries on, which is close to what the Cognition post recommends. I also budget the context myself. My project's main guide file is capped at about 10,000 characters because it loads into every session. Area-specific rules live in smaller files that load only when the agent works in that folder.
Speed shrinks the case for parallel. The run made 315 model calls in about 140 minutes, roughly one every 27 seconds, including builds and installs. Much of that time went on work that can't run in parallel anyway: there is one tablet, and two Gradle builds on my machine collide. Ten agents can't share one tablet.
One trend cuts the other way. Small models keep getting cheaper and better, so a sub-agent on a small model can cost less than the main agent doing the same search. That makes narrow, well-briefed helpers more attractive, not less.
Is it a token-burning push by big companies?
I don't think it's a plot. But the incentive is real, and the defaults lean the expensive way, so it pays to ask what each "recommended" option costs.
The case for suspicion is simple. Vendors sell tokens by the million, and a team of agents uses several times more of them. Demos with ten busy panes look like progress. Benchmarks reward spending, since token usage alone explained 80% of the variance in Anthropic's own BrowseComp tests.
The case against is just as concrete:
- The vendor published the warning. The same post that reports the 15× figure says coding tasks are a weaker fit for many agents than research.
- My harness asks first. Claude Code starts a multi-agent workflow only when I opt in, and its own option text said the team "uses noticeably more tokens".
- Flat-rate plans flip the incentive. On a subscription, extra tokens cost the vendor compute and cost me only my usage limit. The vendor's gain there is indirect at best: a nudge toward a bigger plan.
- Sometimes the team really is better. On broad research, the multi-agent system's 90.2% gain was measured, not marketed.
What I'd watch is the nudge, not a conspiracy. In my run, the "recommended" label sat on the six-to-eight-agent option. A default like that, repeated across thousands of users, moves a lot of tokens, whatever anyone intended. I now have a standing rule with my agent: no fan-outs unless I ask.
Single agent or many: a rule of thumb
Start with one agent. Split only when the parts stand alone, can run at the same time, and finishing sooner is worth several times the tokens.
Start with one agent, and make the second one earn its place
So, are multi-agent systems overrated? Not useless, and not a scam. But for connected work they are oversold, and the second agent should have to prove it is worth its tokens.
My unattended run did a code review, a rebrand, the store paperwork, a release build and a device test with zero sub-agents. It worked because one mind held the whole job, the window was big enough to hold it, and the cache made a long context cheap to keep.
Next time an agent recommends a team, I'll ask three things:
- Shared decisions. What does each agent need to know that another one decided?
- Real parallelism. Which parts can truly run at the same time?
- The price of speed. How many times the tokens am I paying, to finish how much sooner?
If the answers are "nothing", "most of them" and "worth it", I'll fan out. Otherwise, one agent can read the diffs.
See what one agent helped build
CricCuts turns raw cricket footage into highlight reels, on your phone.
Get CricCuts How CricCuts is builtSources. Anthropic, How we built our multi-agent research system, 13 June 2025. Walden Yan, Cognition, Don't Build Multi-Agents, 12 June 2025. Anthropic, Prompt caching, Claude Platform docs, read 27 October 2026. H. Pashler, Dual-task interference in simple tasks: data and theory, Psychological Bulletin 116(2), 1994. J. S. Rubinstein, D. E. Meyer and J. E. Evans, Executive control of cognitive processes in task switching, Journal of Experimental Psychology: Human Perception and Performance 27(4), 2001. S. Leroy, Why is it so hard to do my work? The challenge of attention residue when switching between work tasks, Organizational Behavior and Human Decision Processes, 2009. E. H. Schumacher and others, Virtually perfect time sharing in dual-task performance, Psychological Science 12(2), 2001. N. Cowan, The magical number 4 in short-term memory, Behavioral and Brain Sciences 24(1), 2001. N. F. Liu and others, Lost in the Middle: How Language Models Use Long Contexts, 2023. F. P. Brooks, The Mythical Man-Month, 1975, via Brooks's law on Wikipedia. The psychology abstracts were read through PubMed. The case-study figures come from my own Claude Code session transcript of 27 October 2026.
Related reading: build with a genius, ship a machine, many small models working together, the ball doesn't read the docs (building CricCuts with three AI coding agents), and the idea the AI missed. More on the CricCuts blog.
