You Probably Don't Need Multi-Agents

I work across six or seven repositories on one project — a big hybrid thing, part microfrontend, part backend, several apps that all talk to each other. When I started bringing an AI agent into that work, my first instinct was the obvious one: set up an agent in each repo. Seven repos, seven configured agents. It felt right. Each repo is its own world, so each gets its own helper.

I got a couple of repos in before I stopped and asked myself what I was actually doing. My tasks almost never live in seven repos at once. They live in one. In months of work I've had maybe two tasks that touched multiple repos. So I was about to build and maintain seven separate agent setups to serve a reality where the work is overwhelmingly single-repo. I threw it out, put every repo into one workspace, and configured one agent, once. That agent has been better than any swarm I could have wired together — and it cost me a fraction of the effort.

That small decision is the whole argument of this article, scaled up. The industry's default reflex right now is more agents. I think the default should be one agent, taught well — and you should have to justify every agent you add past the first.

The orchestra is a status symbol

Here's the thing that bugs me about most "how I use AI" posts. They read like a flex. "I built an orchestrator that spawns a planner, which hands off to a coder, which pings a reviewer, which triggers a tester." Eight agents, a diagram with lots of arrows, and the unspoken message: look how sophisticated my setup is.

And honestly, some of it would work fine — if the coordination between the pieces were as good as the diagram implies. But that's exactly the part nobody shows you. The arrows in the diagram are doing an enormous amount of invisible work. In practice, an agent that pings another agent — "are the tasks ready yet?", "go run the tests now" — is a coordination protocol you now own, built out of the least reliable component you have: one model trying to communicate intent to another model.

The number of agents in your system is not a measure of its sophistication. It's a measure of how many places your context can fracture.

What a second agent actually costs

Let's talk about the bill, because it's the part the impressive diagrams leave out. Anthropic published numbers from their own multi-agent research system, and they're worth sitting with: a single agent burns roughly 4× the tokens of a normal chat, and a multi-agent system burns about 15×. That's not a rounding error. That's your token budget, tripled and tripled again, in exchange for coordination overhead.

Sometimes that trade is worth it. Anthropic's own finding is that multi-agent setups genuinely win at breadth-first research — questions where you can fan out into many independent directions at once, each subagent exploring its own slice with its own context window, then compressing what it found. If the task is "find every board member across these 400 companies," parallel agents crush a single agent that has to plod through sequentially. That's a real, honest use case.

But look closely at what makes it work: the subtasks are independent. One agent's findings don't change what another agent should do. That's the property that makes parallelism safe. And it's exactly the property most of our work doesn't have.

Coding is the wrong shape for a swarm

Anthropic say it plainly, and it matches everything I see: most coding tasks involve fewer truly parallelizable subtasks than research, and today's models aren't good at coordinating and delegating to each other in real time. Code is a web of dependencies. The change you make in one file constrains the change in the next. Split that across agents and you don't get parallelism — you get two agents making conflicting assumptions about the same system.

The team behind Devin wrote a whole piece called "Don't Build Multi-Agents," and their core point is sharper than the cost argument. Every action an agent takes carries an implicit decision. When you split work across parallel subagents, each one makes its own implicit decisions, and those decisions quietly conflict. Their example is perfect: ask two subagents to build a "Flappy Bird clone" in parallel, and one builds a Super Mario background while the other builds a bird that moves nothing like Flappy Bird. Now your final agent has to reconcile two subtly incompatible worlds. Nobody was wrong on purpose. The context just couldn't be shared thoroughly enough for them to agree.

Actions carry implicit decisions, and conflicting decisions carry bad results.

That's why even Claude Code, when it spawns a subtask, usually only asks it to answer a question — never to go off and write code in parallel. The subagent investigates, reports back, and the main agent keeps making the actual decisions in one continuous line of context. It's a deliberately simple design, and the simplicity is the point.

The default should be one continuous context

Strip away the fashion and the reliable pattern underneath is almost boringly plain: a single agent, working in one continuous context, making decisions in sequence. It sees everything it did earlier because it never handed off. There's no telephone game, no reconciliation step, no second model guessing at the first one's intent.

Yes, you eventually hit a ceiling — a task so large the context window overflows. But the answer to that is rarely "spawn a committee." It's better context management: summarizing completed phases, storing decisions in memory, spinning up a fresh context with a clean handoff when you truly need one. You reach for that when the single agent stops fitting, not before — and even then you're managing context, not orchestrating a crowd.

The real lever isn't more agents

Here's what actually moved the needle for me, and it wasn't a second agent. It was teaching the one agent my workflow properly and giving it the right tools. I wired in the MCP servers it needs — reading Jira, Confluence, docs, Postman — so it works with real context instead of guessing. And I invested the months it took to teach it how I actually work, step by step.

The payoff is that I can now start a fresh session and type "take task 123 and do it as usual," and it knows what that means: assign the ticket to me, move it to In Progress, pull it into the sprint if it's sitting in the backlog, estimate it if it has no points, branch off an updated main by our convention, commit with human-readable messages, open the PR with a real description and the right people tagged, link it to the ticket, and watch the pipeline — fixing it if it goes red. One agent. One phrase. No orchestra.

That's a whole article of its own — how I taught one agent to "do it as usual" — and it's the honest alternative to the swarm. The effort I didn't spend maintaining seven setups, I spent deepening one.

The reframe

The multi-agent orchestra is seductive because it looks like engineering. Boxes, arrows, roles, a system. But most of the time it's complexity cosplaying as capability — three times the token bill, a coordination protocol built on the flakiest possible substrate, and results that are worse because the context keeps fracturing between the players.

So my rule is simple: reach for the second agent only when you can name the work it's doing — work that is genuinely independent, genuinely parallel, and genuinely worth 15× the tokens. Research that fans out? Maybe. Almost everything else? One agent, one context, taught well. The sophistication was never in the number of agents. It was always in how much of your actual work you managed to hand off cleanly to a single one.

If you're running a multi-agent setup right now, do one honest audit: for each agent past the first, write down the independent, parallel task it owns and what it costs you. If you can't name that task without hand-waving, you don't have an architecture — you have a diagram. Tell me which agent you'd delete first.