Are you using one LLM or an army of agents??

The Multi-Agent Trap: Why More Agents Often Means More Problems

The demo looks impressive: a researcher agent, a writer agent, a reviewer agent, all passing work between them like a well-oiled team. Then the invoice arrives. A University of Illinois study spanning 15 datasets and 7 task categories found that multi-agent systems consume 4–220x more input tokens and 2–12x more output tokens than a single-agent setup doing the same job.

The performance payoff, meanwhile, is often embarrassingly thin. In roughly 80% of test cases, the study found the two approaches were statistical ties — you pay the token multiplier and get nothing measurable back. And the gap keeps shrinking: MetaGPT's multi-agent advantage on code generation fell from 10.7% with older models to just 3.0% with a frontier LLM, because modern models handle long-context reasoning and tool use that originally motivated splitting work apart.

The failure modes are structural, not random. The UIUC researchers identified three recurring patterns:

• Node-level failures: a "critical agent" bottlenecked on the hardest subtask drags the entire system down with it.
• Edge-level failures: downstream agents get overwhelmed by "overthinking" inputs from upstream agents.
• Path-level failures: errors propagate and context gets lost at every agent handoff.

Practitioners see the same thing. GitHub's engineers report that multi-agent systems behave "much more like distributed systems" than chat interfaces — with implicit assumptions about state and ordering producing subtle bugs like one agent closing an issue another just opened. Field reports add that a four-agent crew can burn 3–5x the tokens of a single agent, while producing different results on different runs — making testing genuinely harder.

Even OpenAI's own guidance cuts against the army instinct: maximize a single agent's capabilities first, because more agents add complexity and overhead that often a single agent with tools simply doesn't need. The uncomfortable truth is that extra agents amplify whatever your workflow already is. If it's vague, they make the vagueness more expensive — and harder to debug. Before you scale headcount in silicon, it's worth testing whether a well-equipped single agent, loaded with proven skills like the ones SkillzBench is building its directory to vet, can already close the gap.

When One Agent Wins - and When It Genuinely Doesn't

The evidence points to a clear answer: start with one agent, and split only when your workload forces you to. OpenAI's official guidance is blunt about it — "maximize a single agent's capabilities first," because more agents introduce complexity and overhead, and often a single agent with tools is sufficient.

The data backs this up. A University of Illinois study across 15 datasets and 7 task categories found that roughly 80% of test cases were ties between single-agent and multi-agent systems — while multi-agent setups burned 4–220x more input tokens. Even more striking: multi-agent advantages shrink as models improve. MetaGPT's edge over a single agent on HumanEval code generation fell from 10.7% with ChatGPT to just 3.0% with Gemini-2.0-Flash. Frontier models now handle the long-context reasoning and tool usage that originally motivated multi-agent designs.

So when does splitting genuinely pay off? The research points to concrete triggers:

• Your prompt has become a tangle of conditional branches that degrade performance even after you've improved tool descriptions
• Your workflow involves multi-step processes with branching decisions, validations, and tool interactions that overload one agent
• You're hitting context-window limits and the "lost-in-the-middle" phenomenon, where growing context triggers hallucinations
• Your tasks map naturally to distinct roles — email triage, content publishing, research pipelines

One nuance from OpenAI deserves attention: tool similarity matters more than tool count. Some implementations successfully manage 15+ well-defined, distinct tools, while others struggle with fewer than 10 overlapping ones. So "too many tools" alone doesn't justify adding agents — confusion between similar tools does.

If you do split, engineer the result like a distributed system, not a chat interface. GitHub's engineering team found that multi-agent systems behave much more like distributed systems, requiring typed schemas, action contracts, and MCP enforcement to stay reliable. And because multi-agent benefits erode with each model generation, plan to re-evaluate your architecture every time a frontier model lands.

Whatever architecture you choose, the tools and skills you load onto each agent shape its performance — SkillzBench is building a free, verified directory of agent skills, with per-agent loadouts that let each agent see only the tools you've chosen for it, so you can browse, test, and equip with confidence.

The Hybrid Middle Path: Route and Cascade Your Way to Better Results

If the single-vs-multi-agent debate feels like a coin flip, that's because for most tasks it is — roughly 80% of test cases ended in a tie. The real opportunity lies in knowing when to use which, and that's exactly what hybrid architectures solve.

The most rigorous evidence comes from a University of Illinois Urbana-Champaign study spanning 15 datasets, 7 task categories, 7 frameworks, and 6 models, which tested two hybrid designs that outperformed both pure single-agent and pure multi-agent approaches. The first is Agent Routing: an LLM "rater" examines each incoming task and sends simple ones to a single agent while routing complex ones to a multi-agent team. The result? Up to 2% better accuracy at just 50% of the multi-agent cost.

The second is Agent Cascade, and it delivered the study's most striking numbers. Instead of predicting complexity upfront, the system tries the single agent first and escalates to a multi-agent team only when there's a verifiable failure. This pattern achieved up to a 12% accuracy improvement and, on specific tasks, up to 88.1% cost savings compared to running everything through a multi-agent pipeline.

The cascade approach works because it exploits the study's core finding: multi-agent systems burn 4–220x more input tokens and 2–12x more output tokens than single agents, yet add little value in most cases. When the single agent succeeds — which it usually does — you pay single-agent prices. When it genuinely fails, you pay the multi-agent premium only where it earns its keep.

Across the board, hybrid designs delivered accuracy gains of 1.1–12% while cutting deployment costs by up to 20% — the best overall results of any architecture the researchers tested. For business owners, this reframes the "one LLM or an army of agents?" question: it's not either/or. It's a routing decision made per task, automatically.

Practically, that means:

• Start with a single agent as your default workhorse, consistent with OpenAI's guidance to maximize single-agent capabilities first.
• Add a lightweight rater or verification step that can detect when a task is too complex — or when a first attempt has verifiably failed.
• Reserve multi-agent teams for genuinely hard, branching workflows where parallelism and role separation pay off.
• Re-evaluate the split periodically, since multi-agent advantages shrink as frontier models improve.

The same logic applies to the tools and skills you attach to your agents. SkillzBench is building a free directory that benchmarks agent skills in a sandbox — with and without each skill — so you can see the measurable lift before wiring anything into your workflow. Whether you run one agent or a team, you'll know exactly what each capability contributes. Join the waitlist to get access when it launches.

Your Practical Playbook: Build, Split, and Equip Agents the Right Way

Architecture decisions are cheap to make and expensive to undo — so make them deliberately. The evidence points to a clear sequence: start single, split only when you must, and engineer the split like a distributed system when you do.

Step 1: Start single and split only on concrete triggers. OpenAI's official guidance is blunt: maximize a single agent's capabilities first, because more agents add complexity and overhead (source: OpenAI's practical guide). Split only when prompts tangle into many conditional branches or when overlapping tools degrade performance even after you improve their descriptions.

Step 2: Budget for a multiplier, not a linear increase. Practitioners report a four-agent crew can burn 3–5x more tokens than a single agent on the same task, and empirical research from UIUC found multi-agent systems use 4–220x more input tokens than single-agent systems. If cost matters, try the cascade pattern: single agent first, escalate to multi-agent only on verifiable failure — the study measured up to 88.1% cost savings on specific tasks.

Step 3: Engineer multi-agent like a distributed system. GitHub's engineering team found multi-agent systems behave "much more like distributed systems" than chat interfaces, and they identify three non-negotiables:

• Typed schemas for machine-checkable agent communication — "table stakes," per GitHub
• Action schemas defining exactly what each agent may do, since "most agent failures are action failures"
• MCP as the enforcement layer, validating tool calls before execution

Step 4: Re-evaluate with every model upgrade. The UIUC study found multi-agent advantages shrink as models improve — MetaGPT's edge on HumanEval code generation fell from 10.7% with ChatGPT to 3.0% with Gemini-2.0-Flash. An architecture that justified itself six months ago may be over-engineering today.

Whichever architecture you choose, agent skills extend a single agent's reach cheaply — often delaying the split entirely. But choose them carefully: published research found roughly 26% of published skills carry at least one vulnerability, so verification matters as much as capability. SkillzBench (in pre-launch) is building a free directory of security-scanned, benchmarked skills — every version pinned to a commit SHA, tested in a sandbox, and scored on the measurable Lift it delivers — plus a free MCP connector so any agent sees only the skills you choose for it.

The deeper principle: architecture matters less than workflow clarity. As one practitioner put it, "a framework won't rescue a vague workflow. It will make that vagueness more expensive" (source: PE Collective). Map your task boundaries first, then let the architecture follow.