Is one AI agent better than many? A builder’s take

On October 25, Anthropic published guidance arguing that in many cases, one well-designed AI agent beats a whole pipeline of specialist sub-agents on quality, speed and cost. Plenty of people building with AI took it as a reversal of what we'd been told for the past year: split big jobs across a team of agents.

I read it with extra interest. The most complex thing I've built this year is a trip planner made of several AI agents working together. So I wanted to know: was splitting it up a mistake?

What Anthropic actually said

The headline makes it sound like "multi-agent is dead." The guidance is more careful than that.

The argument is that every handoff between agents costs something. Each one adds delay, adds cost, and loses a little information along the way. Anthropic also points to two habits that creep into agent systems. One is that the design ends up copying the org chart, with each team adding its own sub-agent. The other is what they call a "Frankenprompt": a main prompt built from so many teams' additions that the rules start to conflict.

Their recommendation is one main agent with a lean setup that loads skills, tools and reference material only when it needs them. In one customer's case, the single-agent version ran about twice as fast as the multi-agent one it replaced.

But they still name three cases where splitting makes sense:

• The context gets so full that performance measurably drops.
• Tasks are truly independent and can run in parallel.
• One agent has so many tools that it struggles to pick the right one.

And they warn against merging blindly. In one test, folding a sub-agent into the main agent made it faster but broke something that worked: the main agent started answering on its own instead of handing off to the right specialist.

What I built

Pack Your Bags is a trip planner. You tell it your nationality, destination, dates and preferences, and it coordinates three agents: one checks visa rules, one finds flights and hotels, and one suggests restaurants and activities. Before it writes anything to your calendar or sends an email, it stops and asks a human to approve.

Where splitting helped

Independent work ran in parallel. Finding flights and hotels has nothing to do with finding restaurants. Running those side by side was a natural fit, and it's exactly one of the cases Anthropic says still justifies separate agents.

One failure didn't sink the whole plan. Each agent retried once if it failed. If it still failed, the plan came out anyway and said clearly what was missing. A broken hotel search didn't take down the flights.

Changes only redid what was needed. If someone said "Kyoto instead of Tokyo," only the affected parts ran again.

Here's the honest part, though. Looking back, most of these benefits came from having a clear structure with defined steps, not from having many agents. A single agent inside the same structure could have kept most of them.

Where it cost me

Information got lost at the handoff. The final step turned everything the agents found into one written summary, and it would sometimes reword or drop the map and booking links for hotels, restaurants and flights. The links were safe in the data the whole time. They only went missing when the summary step rewrote them. It’s a close cousin of the loss Anthropic describes: every time an AI step rewrites another step’s output, details can slip. I fixed it by showing those results as cards built straight from the data, each with its real link.

More moving parts meant harder testing. A full run touched several agents and outside services. Runs were sometimes unreliable because of hangs and rate limits, so I ended up saving test results one check at a time instead of trusting a single end-to-end run.

Where I've landed

My rule now is simple: only split work across agents when the pieces can run in parallel with no dependency on each other.

If one step needs the output of another, keep it in the same agent. Every handoff between dependent steps is a chance to lose details, add delay and pay twice for the same context. In my planner, the visa check shapes everything that comes after it, so it belongs with the main flow. Flights, hotels and restaurants don't depend on each other at all, so running them side by side is the one place where separate agents clearly pay off.

What I'd keep no matter how many agents I use are the guardrails: the check that catches requests that don't make sense, and the human approval before anything gets written or sent. Those are about safety and control, not about architecture.

My take

The debate is framed as one agent versus many, but I think that's the wrong question. The better question is: does each handoff earn its cost?

For me, the answer is yes only when the work is truly independent. If it isn't, you're paying in speed, money and lost details for an architecture that looked good on a whiteboard.

It's also worth remembering that this is one company's guidance, written with its own newer models in mind. What holds for their customers may not hold for your setup. The only way to know is to measure before and after you change anything.

If you've built with multiple agents, did splitting help or hurt? I'd like to hear what you found.

Sources

• The Decoder: Anthropic says one AI agent beats many subagents
• Tech Times: Single agent beats multi-agent teams on cost, speed, and quality