Agent Delegation: When One Agent Beats a Swarm

Estimated read: 24 minutes. The short version: the pitch right now is to spin up a swarm of AI agents and delegate everything to them. The builder data says the opposite. A single agent matches or beats a multi-agent setup most of the time, a swarm burns roughly fifteen times the tokens, and most agent pilots never reach production at all. The thing that decides whether your AI ships is not the model. It is how you design the delegation: what becomes a tool, what stays one agent, what earns a swarm, and how much autonomy you hand over.

This month the agents got loud. Microsoft shipped Scout, an always-on agent that runs in the background, holds its own identity, and takes action without waiting for you to prompt it. OpenAI rolled out a row of business agents for sales, data, banking, and investing, and reported that knowledge workers are now its fastest-growing group of Codex users. Google has its own version in the same lane. The message under all of it is identical: stop doing the work yourself, spin up a team of agents, and let them run.

I run two companies where AI already does most of the production work, so I am the target customer for this pitch. I went looking for where the swarm actually beats a single agent, expecting the answer to be “usually.” It is not usually. It is rarely. And the gap between the demo and the deployment is where almost everyone loses.

Here is the number that reframes the whole thing. At an equal token budget, a single well-built agent matches or beats a multi-agent system on most tasks, and roughly seven out of ten briefs that get drawn up as “multi-agent” would be cheaper, faster, and more reliable as one agent with a good set of tools. A swarm is not a free upgrade. It is a tax you pay in tokens, latency, and entirely new ways to fail.

This is the durable version of the story, the part that stays true long after this month’s launches are old news. The launches are real and the autonomous-agent direction is right. What almost nobody is teaching is the unglamorous skill that decides whether any of it works: agent delegation. Not which model you pick, but how you decide what to hand off, to how many agents, and with how much rope. That is what this is about.

The swarm reflex, and why it is usually wrong

Watch how a team reaches for multi-agent and you will almost always see the same move. The demo of a swarm looks incredible. Five little agents with job titles, a researcher, a writer, a critic, a manager, passing work to each other like a tiny company. It photographs well. It sells well. So the instinct becomes: my problem is complicated, therefore I need many agents.

That instinct is backwards. Complexity in the problem is not a reason to add agents. It is usually a reason to add tools and context to one agent. The number of agents you run should track the structure of the work, not the difficulty of it. A hard problem with one continuous line of reasoning wants one agent. An easy problem split across forty independent documents might want several. Difficulty and agent count are different axes, and conflating them is the single most expensive mistake I see builders make.

The cost of getting it wrong is not theoretical. Most agent projects do not fail loudly. They fail quietly, in the long gap between a demo that works on a tuesday and a system anyone can depend on. The most-cited figure in enterprise AI right now is that 88 percent of agent pilots never reach production, a number that started in research from Anaconda and Forrester and has been repeated in independent surveys since. Other production studies put the in-the-wild failure rate somewhere between 70 and 95 percent depending on how hard the task is. One analysis of 97 percent of companies that deployed agents found only 11 percent actually running them in production, a roughly 68-point gap between “we have agents” and “we use agents.” I went deep on the demo-to-production cliff in a separate piece on why AI agents fail in production. The short version is that most of those failures are not model failures. They are design failures, and a lot of them are delegation failures specifically: work handed to the wrong number of agents, with the wrong context, at the wrong level of autonomy.

When Forrester broke down the root causes, the top three were unclear success criteria at 41 percent, agents that could not reach the tool or data they needed at 33 percent, and evaluation coverage that drifted over time at 26 percent. Notice what is missing from that list. “The model was not smart enough” is not on it. The bottleneck is upstream of the model, in how the work was scoped and handed off. That is good news, because scoping and handoff are things you control completely.

The Delegation Test: four homes for a unit of work

So I stopped asking “how many agents should this take” and started asking a cleaner question for every single piece of work: where does this belong? Not every task should be an agent at all. Some should be plain code. Some should be one agent. A few should be a swarm. The job is to route each unit of work to its correct home before you write a line of orchestration.

There are exactly four homes, and the Delegation Test is the order you check them in. You always start at the cheapest, most predictable option and only move up when the work forces you to. The flowchart below is the whole framework in one picture, and the rest of this post is just the four boxes explained.

Read the test top to bottom. Most of what people try to make into agents is actually a tool, a fixed procedure that does the same thing every time: send the email, write the row to the database, call the API, run the report. If the steps do not change based on judgment, you do not want a model in the loop at all. You want code. It is faster, it is free, and it never hallucinates the procedure.

If the work genuinely needs judgment across changing context, you drop to the next box, and the next box is the default. One agent. Single line of reasoning, one continuous context, one set of tools. You only leave this box for a very specific shape of work: tasks that split into independent pieces that can run at the same time, where the pieces are mostly reading and gathering rather than writing and changing shared state. That is the narrow door into a swarm. And even then, the swarm you want is not five peers chatting. It is one orchestrator that owns the context and spawns isolated workers who each go off, do one piece, and hand back a short summary. The true free-for-all, agents talking to agents and writing to the same state, is the last box, and you should treat it as almost never.

Home	Best for	Token cost	Main failure mode	How hard to debug
Tool	Fixed, repeatable procedures	Near zero	Wrong tool gets called	Trivial
One agent	Sequential reasoning, shared state, anything that writes	About 4x a chat	Context overflow on long tasks	Easy: one log, one loop
Orchestrator + subagents	Parallel, read-heavy, breadth-first search	About 15x a chat	Bad task splitting by the lead	Medium
True multi-agent	Independent domains, async, no shared writes	Highest, hard to predict	Conflicting assumptions between agents	Hard: many logs, race conditions

That last column matters more than people expect. The thing you are really choosing when you add an agent is how hard your own system will be to understand when it breaks at 2am. One agent gives you one reasoning loop, one context window, and one log to read. A swarm gives you a distributed system with all the race conditions and coordination bugs that implies, except the nodes are non-deterministic. You are not just paying in tokens. You are paying in your own ability to ever debug the thing.

Here is the test run against six tasks I have actually had to make this call on. Notice how rarely the answer is a swarm, and how often “this feels complicated” resolves to “one agent, better context.”

The task	Shape of the work	Where it belongs	Why
Send a templated onboarding email	Fixed procedure, no judgment	Tool	Same every time. A model only adds risk and cost.
Reconcile two spreadsheets, flag mismatches	Deterministic rules	Tool	It is code, not cognition. Do not dress it up as an agent.
Triage a support ticket and draft a reply	Sequential, writes, needs judgment	One agent	One thread, one context. Send the hard cases to a human.
Ship payroll and pay vendors	Writes, high blast radius, low reversibility	One agent, low autonomy	Rung 3 with approval, never an autonomous swarm.
Write a feature, then review it for bugs	Two roles, one writer	Orchestrator	Generate-then-review. The critic advises, never writes.
Research a market across 40 sources for a memo	Parallel, read-heavy, high-value	Orchestrator + subagents	Breadth-first. Workers gather, never touch shared state.

The Handoff Tax: what every boundary actually costs

Every time work crosses from one agent to another, you pay a toll. I call it the Handoff Tax, and once you can see it, you stop adding boundaries casually. The tax has four lines on it, and only the first one is obvious.

The token line is the one people quote. Anthropic measured its own agents and found a single agent uses about four times the tokens of a normal chat, mostly because it makes many tool calls and carries a working context. A multi-agent system, the kind with a lead delegating to parallel workers, used about fifteen times the tokens of a chat. That is not a rounding error. That is the difference between a feature that is profitable and one that quietly bleeds money on every run, which is exactly why so many teams are now measuring AI work by cost per correct task instead of raw output.

The second line is latency. Every handoff is a round trip, and they stack. A chain of agents waiting on each other feels slow in a way users notice, and the slowness is structural, not something a faster model fixes.

The third line is the one that does the real damage: a brand new failure mode that one agent simply does not have. When two agents work from slightly different assumptions, or one acts on incomplete information the other never passed along, you get a coordination failure. The team at Cognition that builds the Devin coding agent published a piece bluntly titled “Don’t Build Multi-Agents,” and their core finding was that multi-agent setups are fragile precisely because the failures “generally boil down to missing context.” A subagent does not know what the other subagents know. It guesses, it diverges, and the work comes back inconsistent. Google researchers found the same thing from the performance side: on sequential reasoning tasks, multi-agent coordination actually reduced performance by 39 to 70 percent compared to a single agent, because the coordination overhead was pure cost on work that never needed splitting.

The fourth line is security, and it is the one founders forget until it bites. Every agent boundary is a new place to be attacked. Every tool a worker can call, every handoff, every write to shared memory is a fresh vector. A swarm has a far larger attack surface than a single agent doing the same job, which I unpacked in detail in the piece on the AI agent identity gap. More agents is not just more cost. It is more surface for something to go wrong on, accidentally or on purpose.

When one agent wins, which is most of the time

The default home in the Delegation Test is one agent, and I want to make the positive case for it, not just the case against swarms. A single agent has one advantage that is easy to undervalue right up until the moment you need it: predictability. One reasoning loop. One context window. One set of logs. When it does something strange, you can actually trace why, because there is a single thread to follow. That is worth more in production than almost any capability gain, because the thing that kills agents in production is not that they are not clever enough. It is that nobody can tell why they did what they did.

The principle underneath this has a name now, the single-writer principle. Keep one agent as the only thing that writes or acts. If you want more intelligence in the loop, add it as advice, a critic that reviews, a tool that fetches, a model that compresses history, not as a second hand on the wheel. The moment two agents are both allowed to act and write, you have a coordination problem. As long as the writing stays single-threaded, you mostly do not. Cognition’s recommendation lands in the same place, and it is almost aggressively simple: use a single-threaded linear agent where the context is continuous, and only break that rule when you are forced to.

The obvious objection is that one agent cannot handle a big job. It can, and the proof is in production. Rakuten pointed a single coding agent at a 12.5-million-line codebase to extract activation vectors, a genuinely large and fiddly task, and it finished in about seven hours with 99.9 percent numerical accuracy. That is not a toy. That is one agent, one continuous context, doing work that would have looked like an obvious candidate for “let’s split this across a team of agents,” and it succeeded because the work was one long coherent thread, not many independent pieces.

When a single agent does start to strain, the answer is usually not more agents. It is better context. When a task is so long that the context window genuinely overflows, the move that works is to add one specialized model whose only job is to compress the history so far into the key decisions, events, and state, and feed that back to the same agent. You keep the single thread, you just give it a memory that does not blow up. This is the heart of context engineering, and it solves far more “I need multiple agents” problems than actually adding agents does. Nine times out of ten, “my agent is struggling” is a context problem wearing an architecture costume.

When a swarm actually pays for itself

I am not anti-swarm. I am anti-swarm-by-default. There is a real and specific shape of work where a multi-agent setup earns its fifteen-times token bill, and it is worth knowing exactly what that shape is so you can recognize it when it shows up.

The work has to be parallelizable, read-heavy, and high-value. Parallelizable means it genuinely splits into independent pieces that do not need to talk to each other while they run. Read-heavy means the pieces are mostly gathering and analyzing, not writing to shared state, so there is no coordination problem to create. High-value means the answer is worth fifteen times the tokens, because it will be, so the task had better be expensive to get wrong.

The clean example is deep research. When Anthropic built its multi-agent research system, a lead agent that plans a query and spawns parallel workers to explore different angles at once, the multi-agent version beat a single agent by about 90 percent on its internal research evaluations. That is a massive win, and it is real. But look at why it works and you see the whole rule. Research is breadth-first. You want to look at forty sources at once, and looking at a source does not change anything, so the workers never step on each other. Anthropic was explicit that the economics only make sense for high-value work like legal due diligence, competitive intelligence, and biomedical literature review, exactly the cases where you are happy to spend a lot of tokens to be thorough.

Their own analysis found that token usage alone explained 80 percent of the performance difference on their browsing benchmark. Sit with that. The swarm did not win because five agents were collectively smarter. It won because it spent more compute, in parallel, on a task that could absorb it. If your task cannot absorb that spend, or cannot be split without the pieces needing to coordinate, the swarm has nothing to offer you except the bill.

The patterns that actually survive in production have narrowed to a short list. One orchestrator with isolated read-only workers, the research pattern. A generate-then-review loop, where one agent writes and a second only critiques, never writes. And a map-reduce shape, where you fan a task out across independent chunks and a single agent reduces the results back down. What these share is that the writing stays single-threaded. The extra agents add intelligence or parallelism, never a second set of hands on the shared state. That is the line. Cross it and you are in the rare last box, building a distributed non-deterministic system, and you had better have a reason worth the pain.

The Delegation Ladder: granting autonomy by blast radius

Deciding how many agents is only half of delegation. The other half is how much rope you hand them, and this is where the always-on pitch gets genuinely risky. An agent that acts in the background without asking is not a single setting you flip on. Autonomy is a ladder, and the rung you put a task on should depend on one thing above all: the blast radius if it gets the task wrong.

The first thing to fix is the unit. Autonomy is assigned per action, not per agent. The same agent can be fully autonomous on reads, conditionally autonomous on low-risk writes, and forced to stop and ask on anything sensitive. Treating “how much can this agent do on its own” as one global switch is how you end up either crippling a useful agent or handing a dangerous one the keys. You set the rung per action, based on what happens if that specific action is wrong.

The bottom rungs are cheap to be wrong on. An agent that suggests, or drafts something you edit before it ships, has a blast radius of roughly zero, because you are the gate. The top rung, an agent acting in the background with no prompt, has the largest blast radius there is, because it can take many actions on an early mistake before any human sees a thing. That is the exact risk the always-on launches are selling past. Acting without being asked is the product feature. It is also the highest rung on the ladder, and most tasks have no business being up there.

The cautionary tale already happened in public. Klarna pushed customer service hard up the autonomy ladder, and for a while the numbers were stunning. By late 2025 the company said its AI was doing the work of more than 800 employees and saving on the order of 60 million dollars. Then the CEO admitted the obvious cost: pushing that far up the ladder had quietly degraded the customer experience, and the company pulled back to a hybrid model where humans step in when the agent hits what they called a “Trust Threshold.” That is not a story about AI failing. It is a story about a rung that was set too high for the blast radius, then corrected. Over-delegating and then pulling back a rung is not an embarrassment. It is the system working, as long as you notice before the damage is permanent.

The practical upgrade here is to kill the “Approve?” button. A bare yes-or-no prompt trains people to click yes on reflex, which is worse than no gate at all because it manufactures the appearance of oversight. Replace it with a short checklist the approver actually has to read: what is the agent about to do, what data and permissions is it using, what is the blast radius, and what is the rollback if it is wrong. The human side of running agents this way, keeping yourself as the editor and standard-setter rather than a rubber stamp, is the whole subject of the agent boss operating system. You are not approving a task. You are deciding the rung.

The four things that actually break delegation

When delegation fails in production, it almost always fails in one of four specific ways. None of them is “the model was dumb.” If you are debugging a flaky agent system, start here, in roughly this order of likelihood.

The first and most common is missing context. This is Cognition’s headline finding and Forrester’s number two root cause, the agent that could not reach the tool or data it needed, at 33 percent of failures. A subagent that does not have the full picture makes a locally reasonable choice that is globally wrong. The fix is almost never another agent. It is getting the right context to the one agent, or compressing context so it survives a long task. Before you add an agent, ask whether the existing one is failing because it is missing information. It usually is.

The second is unclear success criteria, the largest single root cause at 41 percent. If you cannot say precisely what “done correctly” means for a task, you cannot delegate it, to an agent or a person. The agent will optimize for something, and if you did not define the target, it will pick its own, and you will not like it. This is upstream of all architecture. No amount of orchestration saves a task whose definition of success was never written down.

The third is evaluation drift, at 26 percent. A delegation that worked at launch slowly stops working as inputs shift and the model updates underneath you, and nobody notices because nobody is testing it anymore. You cannot grant autonomy you cannot test. The rung you put a task on should be tied directly to how well you can evaluate it, which is why an evals practice is the thing that lets you safely move tasks up the ladder at all. No evals, no autonomy. Full stop.

The fourth is coordination failure, and this one is unique to swarms. Two agents act on conflicting assumptions, or race to write the same state, and the output is inconsistent in a way that is maddening to reproduce. This is the failure you are choosing to take on the moment you add a second writer. It is the strongest argument for the single-writer principle, because the cleanest way to never debug a coordination failure is to never create the possibility of one.

Three of these four hit a single agent too, which is the point. If your delegation is breaking on context, success criteria, or evals, adding agents does not fix it. It multiplies it, and adds the fourth failure on top. Fix the first three on one agent before you ever consider a swarm.

What most teams get wrong about this

Here is the thing almost everyone has backwards. The market treats adding agents as progress, a sign your system is getting more sophisticated. In production, the opposite is true. The senior move is almost always removing agents, not adding them. The most sophisticated agent systems I have seen are shockingly simple: one agent, a tight set of well-described tools, excellent context, and a human at the right rung of the ladder. The ones that look impressive in a demo, the org chart of little agents passing notes, are usually the ones that never ship.

So “we need multiple agents” should set off an alarm, not a budget approval. Most of the time it is a tell. It means the team has not done the work of getting context right for one agent, and is reaching for architecture to paper over it. Adding a second agent feels like progress because it is visible and it photographs well. Fixing the context for one agent is invisible and unglamorous, and it is almost always the actual answer. Complexity in your agent graph is not a sign of an advanced system. It is usually a sign of an unsolved context problem.

This is why the always-on launches, real and impressive as they are, do not change the builder’s job. They raise the ceiling on what a single well-delegated agent can do. They do not remove the need to decide what to delegate, to how many agents, at what rung. If anything they raise the stakes, because an agent that can act on its own in the background makes every delegation mistake more expensive and harder to catch. The capability went up. The discipline that turns capability into a shipped product, agent delegation, did not get easier. It got more important.

The teams that win the next year will not be the ones running the most agents. They will be the ones who delegated the least, and delegated it well. Fewer agents, tighter scope, context done properly, autonomy granted by blast radius and earned through evals. That is not the exciting answer. It is the one that ships.

What to do Monday morning

Concrete steps you can run this week on whatever you are building, in order.

Run the Delegation Test on your current build. Take every place you have an agent right now and route it through the four boxes. Be honest. How many of your “agents” are actually fixed procedures that should be plain tools? How many of your multi-agent flows are doing sequential work that one agent should own? Most teams find at least one agent that should be code and at least one swarm that should be a single agent.

Collapse to one agent wherever you can. For anything that is not clearly parallel, read-heavy, and high-value, merge it back into a single-threaded agent with a good tool registry. Treat this as a win, not a downgrade. You are buying predictability, lower cost, and a system you can actually debug.

Set the autonomy rung per action, not per agent. List the actions each agent can take. Put each one on a rung of the ladder based on its blast radius. Reads can usually run free. Anything that writes, spends money, or touches a customer starts at “execute with approval” and only climbs after it earns it.

Replace every “Approve?” button with a checklist. Intent, data and permissions, blast radius, rollback. If a human is the gate, make the gate mean something. A reflexive yes is not oversight.

Instrument cost per correct task. Track tokens and the correctness rate together for each delegated task. This is the number that tells you whether a swarm is worth its fifteen-times bill, and it is the only honest way to compare architectures. Raw output is a vanity metric.

Tie every rung to an eval. Before you move any task up the ladder, write the test that proves it works, and keep running it. The rule is simple enough to put on a wall: no eval, no autonomy. If you cannot test it, it does not get to act on its own.

Do these six things and you will have done more for the reliability of your AI than any model upgrade will buy you. Delegation is the lever, and it is entirely in your hands. If you want the wider context for where this fits in building a company on AI, it sits inside the broader AI-native founder playbook and connects to the bigger question of where to place your AI bets in the first place.

Frequently asked questions

What is agent delegation?

Agent delegation is the design decision of how to hand work to AI: whether a task should be plain code, a single agent, an orchestrator with subagents, or a true multi-agent system, and how much autonomy the agent gets to act on its own. It is distinct from prompting or model choice. Delegation is about structure and authority, and it is the main thing that decides whether an agent system is reliable enough to run in production.

Is a single agent or a multi-agent system better?

For most tasks, a single agent is better. At an equal token budget it matches or beats a multi-agent setup on reasoning, and roughly seven in ten briefs written as multi-agent would be cheaper, faster, and more reliable as one agent with good tools. Multi-agent only wins on work that is parallelizable, read-heavy, and high-value, such as deep research across many sources at once. For sequential work or anything that writes to shared state, a single agent is both safer and more predictable.

When should I actually use multiple agents?

Use multiple agents when the work genuinely splits into independent pieces that can run at the same time, the pieces are mostly reading rather than writing, and the answer is valuable enough to justify spending many times the tokens. Even then, the pattern to use is an orchestrator that owns the context and spawns isolated workers who return short summaries, not a group of peer agents writing to shared state. Keep the writing single-threaded.

Why do multi-agent systems cost so much more?

Anthropic measured a single agent using about four times the tokens of a normal chat, and a multi-agent system using about fifteen times. The cost comes from every agent carrying its own context, making its own tool calls, and passing work across boundaries. On top of tokens you pay in latency at every handoff, a new coordination failure mode, and a larger attack surface. A swarm is a real cost decision, not a free capability upgrade.

What is the single-writer principle?

The single-writer principle says only one agent should write or take action in your system. If you want more intelligence, add it as advice, such as a critic that reviews or a tool that fetches, rather than as a second agent that also acts. As long as the writing stays single-threaded, you avoid coordination failures where two agents work from conflicting assumptions. It is the simplest reliable shape for an agent system and the reason most production multi-agent patterns keep one writer at the center.

How much autonomy should I give an AI agent?

Grant autonomy per action, not per agent, and set the level by blast radius. Reads and suggestions can usually run freely. Anything that writes, spends money, or touches a customer should start at “execute only with approval” and climb to higher autonomy only after it has proven itself on evaluations. Reserve fully autonomous, always-on behavior for tasks that are reversible, low-stakes, and well-tested. The rule of thumb is no eval, no autonomy.

Are the new always-on agents a reason to build multi-agent systems?

No. Always-on autonomous agents raise the ceiling on what a single well-delegated agent can do, but they do not remove the need to decide what to delegate, to how many agents, and at what level of autonomy. If anything they raise the stakes, because an agent acting in the background makes every delegation mistake more expensive and harder to catch. The capability improved. The delegation discipline matters more, not less.

My single agent is struggling on a long task. Do I need more agents?

Usually not. Most “my agent is struggling” problems are context problems, not architecture problems. If the task is overflowing the context window, add a step that compresses the history so far into the key decisions and state, and feed that back to the same agent. You keep one continuous thread and one debuggable loop. Reach for more agents only when the work is genuinely parallel and read-heavy, not just long.