One Agent With Good Context Beats a Swarm: Why Handoffs Break Multi-Agent Code

Seven agents, one deleted function

An orchestrator spun up seven agents. Six of them wrote the same function, and the seventh deleted it. Here's the trimmed diff, because seeing it beats being told about it:

+ def limit(req):            agents/a2.py
+ def rate_limit(req):       agents/a3.py
+ def check_limit(r):        agents/a4.py
+ def limiter(request):      agents/a5.py
+ def apply_limit(req):      agents/a6.py
+ def limit(req):            agents/a7.py
- def limit(req):            agents/a7.py  (removed a2's copy)

That's five versions of one forty-line function, each perfectly sensible alone, none aware that the others existed. Then a seventh agent spotted a duplicate name, did the responsible thing and removed the version everything else imported. Watching that scroll past while real money burned didn't produce frustration. It produced embarrassment, because the most expensive machine imaginable had just built a folder that doesn't compile, from an architecture diagram someone was proud of.

If you've ever drawn boxes labeled Planner, Coder, Reviewer and Tester and felt a small glow from designing something serious, this applies to you.

The arithmetic missing from slides

Take an agent that's right 95 percent of the time, which is a genuinely good one. Chain five together and watch what happens. The loop takes four seconds to run:

p = 0.95
for n in range(1, 6):
    print(n, round(p**n, 2))

1 0.95
2 0.9
3 0.86
4 0.81
5 0.77

A solid A became a C, and the bill is five times higher. Plenty of talks on agent orchestration exist, yet this little loop rarely appears on a slide.

Handoffs are where it breaks

This took the longest to notice. An agent deep in a problem carries a huge amount of unspoken state. It knows the auth middleware is held together with tape, that the test suite overstates coverage, and that the obvious fix was already tried and blew up.

A handoff carries none of it. What gets passed along is a note of maybe three hundred tokens, or a thousand at most, and the rest vanishes when the process ends. So the second agent doesn't work from what the first one knew. It works from a summary of it, then makes load-bearing decisions on top of that compressed leftover.

FIVE AGENTS

  [A1] --msg--> [A2] --msg--> [A3] --msg--> [A4]
   |             |             |             |
  full          ~300          ~300          ~300
  context       tokens        tokens        tokens
   |             |             |             |
  knows         guesses       guesses       guesses

ONE AGENT
   retrieval ---+
   memory    ---+---> [ AGENT ] ---> output
   tools     ---+         ^  |
   compaction---+         |  |
                          +--+
                     one head, one state,
                     nothing lost in transit

The best case for multi-agent

The opposing view is a strong one, so it gets a proper hearing. First, specialization works: on a given job, an agent with a tight prompt beats a generalist. Second, windows are finite, and five of them give you five times the space. Third, a fresh context is the one reviewer you can trust. An agent that has spent sixty thousand tokens talking itself into a design is badly placed to judge it. Finally, the research systems that dig through many sources at once do beat single-threaded ones, and that gain was measured, not advertised.

So fan-out isn't dead. People just reach for it along the wrong dimension.

Reading spreads out, writing doesn't

Counting agents isn't the right test. What counts is whether the subtasks make choices that have to be consistent with one another. Reading splits up almost for free, whether it's forty sources, a hundred files or six claims to verify, because nobody commits to anything and there's no shared state to break apart.

Writing is the opposite. Let two agents pick an API shape on their own and you get two designs that each make sense and don't mesh. Reconciling them takes longer than doing the job one step after another.

hits = par([find(q) for q in qs])   # reads fan out
patch = run(req, ctx + hits)        # writes go through one head

In short: fan out the reading, funnel the writing through one place. The whole rule fits on a napkin.

The dull part is the real work

The heavy lifting isn't "one agent." It's good context, and that's tedious, unphotogenic work:

• retrieval that surfaces the right four files, not the top twenty by cosine similarity
• compaction that holds up over a long session
• memory that records why an approach was rejected instead of what was typed
• tool output shaped so that one call doesn't swallow half the window

Conference organizers don't ask for talks on compaction strategy, so people build swarms instead. A diagram of orchestration is easy to read at a glance, which three weeks of work on the prompt's contents will never be. Those three weeks are worth spending, and worth spending again.

Try this tomorrow

Log every token that enters your agent's window during one full session. Then read the log back and estimate what share of it bore on the decision the agent actually had to make. In this case it was under a third. A brilliant model had been fed a firehose of noise and then blamed for its aim.