I Default to One Agent

The architecture debate of 2026 is multi-agent orchestration versus the single agent, and it has settled into two camps talking past each other. One side points at research showing a swarm of sub-agents outperforming a lone one by huge margins on hard tasks. The other points at data showing single agents match or beat swarms on the majority of real work. Both are right, and both miss the actual question a builder faces on a Tuesday morning: do I add another agent here, or not?

My answer, almost always, is no. I default to one agent. And I keep a short, specific list of the moments I split.

Why the swarm is seductive

Multi-agent orchestration is architecturally beautiful. It mirrors how we already think about teams — a researcher, a writer, a reviewer, each with a clear role, handing off cleanly. It reads like good engineering before you’ve run it. That’s the trap. It looks like the system you’d design on a whiteboard, and whiteboards don’t charge by the token or fail on a network boundary.

The pitch is usually one of three things: specialization, parallelism, or a context window that’s too small for one agent to hold the job. Two of those are real reasons. One is an excuse.

The hidden taxes

Every boundary between agents is a boundary you pay for in production. The costs are real and they compound:

• Debugging across the seam. When a single agent misbehaves, there’s one trace. When three agents hand off and the output is wrong, you’re reconstructing a conversation across context windows, each of which has dropped or paraphrased something on the way through.
• Compounding per-step error. A single agent at 95% per step holds up better than a chain of three agents at 95% each. Errors multiply across handoffs the way they multiply across a long tool-calling loop — only now each step is a whole agent.
• Coordination overhead. Sub-agents don’t just do work; they negotiate what work to do. On anything but the hardest tasks, the orchestration burns more than the task itself.

The net effect: a swarm that’s elegant to design and miserable to operate. I’ve watched teams reach for multi-agent because the single agent “felt too simple,” and ship something slower, costlier, and harder to reason about than the thing it replaced.

The rule I actually use

I split only when one of these is true:

1. The job genuinely exceeds one context window — and only after I’ve tried context engineering first. Most “the window’s too small” problems are “the context is bloated” problems.
2. There’s real parallelism — multiple independent tracks of work that run at the same time and are wasteful to serialize. Not theoretical parallelism; work that’s actually faster in parallel.
3. There are conflicting personas that corrupt each other in one context — a planner that needs to think loose and a checker that needs to think strict, where blending them makes both worse.

If none of those fire, I stay at one. Cheaper, debuggable, deterministic enough to trust.

Where one agent won

Traffic Driver watches twelve platforms, and the obvious architecture is twelve platform agents under an orchestrator. It’s the diagram everyone draws. The version I trust is closer to one agent with a wide tool bench and a strong filter — because the job isn’t twelve different jobs, it’s one job (find the relevant conversation) repeated across surfaces, and a single agent with good context holds the through-line that a swarm fragments. The swarm looked right. The single agent was right.

None of this means multi-agent is wrong. On the tasks it was built for — genuinely decomposable, parallel, beyond one window — it’s the only honest answer. The mistake is reaching for it as a default, as though complexity you chose is safer than simplicity you have to defend. It isn’t. The simplest agent that holds the whole job in one head is the one I trust to run unattended. Everything more elaborate has to earn its boundaries.

---

When in doubt, one agent, one trace, one thing to debug. Split only when the job refuses to fit.