You bought into the multi-agent pitch. More agents, more parallelism, more output. New research from evals firm Vals AI, published October 11, complicates that story considerably.

Testing GPT-6 Sol and Claude Opus 5.5 both solo and in teams on the Vibe Code Bench, the research found that multi-agent setups cost between 1.8x and 5.1x more per task. And in three out of four test comparisons, the team produced no statistically significant improvement in quality over a single agent running alone. The one exception: GPT-6 Sol at medium reasoning effort, where the team scored 7.3 points higher. At maximum reasoning effort: the mode where you're already extracting the most from the model: agent teams added nothing at all.

Anthropic's own internal research pointed in the same direction. Beyond ten agents on a task, quality gains flattened sharply while token costs kept rising. The curve doesn't stay upward for long.

This matters for operators because "add more agents" has become the default answer to almost every AI workflow problem. Response quality not good enough? Add a review agent. First draft needs improvement? Add a critique agent. Output feels generic? Add a specialized sub-agent. Each of these is a legitimate technique in the right context: but they all carry a real cost, and that cost compounds fast.

Here's the structural issue most operators miss: the model is rarely the bottleneck. When a single-agent output disappoints, the problem is usually the prompt architecture, the available context, or the vagueness of the task definition: not the fact that only one agent is thinking about it. Adding a second agent to a poorly structured task doesn't improve the structure. It multiplies the confusion.

What actually works is more boring than a swarm of 1,000 collaborating agents: specificity. A single agent with a narrow, well-defined scope, given clean input data and clear success criteria, will usually outperform a team of agents wrestling with an ambiguous brief. Every time you find yourself spinning up a second or third agent to "check" the first one's work, that's a signal to go back and fix the original task definition instead.

This isn't an argument against multi-agent systems. Complex, parallelizable tasks: processing hundreds of documents, running simultaneous market research across multiple sources, building software with distinct components: genuinely benefit from coordinated agent teams. The Vals AI research isn't saying agents don't work. It's saying that deploying teams of agents on tasks that don't require them is an expensive way to solve the wrong problem.

For the bootstrapped operator running AI across sales follow-up, client intake, content drafting, and internal ops, this research is practically a budget memo. Before you add the third agent to your workflow, ask a simpler question: do you actually know what the single agent is getting wrong, and why? If the answer is no: if the problem is vague or the input is messy: more agents won't save you. They'll just burn more tokens on the same ambiguity.

The right starting point for any AI workflow isn't "how many agents do I need?" It's "what is the clearest, most specific instruction I can give one agent, and what does a good output actually look like?" Get that right first. Build out from there only when you can prove the single-agent ceiling with real data, not assumption.