How Many Agents Is Too Many? A Cost/Latency Framework

Somewhere between "one agent doing everything" and "a fleet so large nobody can name all its members," there's a right number of agents for a given task. Almost nobody arrives at that number deliberately. Fleets grow the way software teams grow headcount: reactively, one hire at a time, in response to whatever felt like the bottleneck last week, until the org chart bears only a loose relationship to the actual work. This piece is an attempt at the framework that should have been there from the start — three variables that actually determine the right fleet size, and how they trade off against each other.

Variable one: how far the task actually decomposes

The ceiling on useful fleet size is set by how many genuinely independent subtasks your problem contains — not how many subtasks you can invent, but how many actually don't depend on each other's live state. The dominant 2026 production pattern spawns three to five subagents in parallel for complex research tasks, and that number isn't arbitrary: it's roughly where most real-world research questions stop decomposing cleanly. Beyond five, you're usually either splitting an already-narrow subtask further than it needs to go, or forcing artificial independence onto pieces of work that actually depend on each other — the exact trap covered in Orchestrator vs Swarm. Adding a sixth or seventh agent to a task that only had four genuinely independent angles doesn't add coverage. It adds coordination overhead and a longer synthesis step for the lead agent, with no corresponding gain.

The right fleet size question isn't "how many agents can I usefully add" — it's "how many independent subtasks does this problem actually contain," and that number is almost always smaller than it feels like it should be.

Variable two: the token budget, multiplied honestly

Every agent you add to a fleet is not a linear cost — it's a linear cost on top of a baseline that's already roughly 15 times a single chat interaction, the tax covered in The 15x Token Tax of Parallel Subagents. Going from three subagents to six doesn't double your token spend in isolation; it roughly doubles an already-15x baseline, and if your synthesis step at the top also has to reason over twice as much incoming material, that step gets more expensive too. This compounds fast enough that fleet size decisions need to be run through an actual cost projection at expected production volume, not just at demo volume — the same budget-review failure mode that killed a meaningful share of the pilots covered in Why 40% of Multi-Agent Pilots Failed. A fleet that's affordable at ten test queries a day and unaffordable at ten thousand production queries a day isn't a fleet-size problem you can see without doing the multiplication in advance.

Variable three: compounding failure risk

This is the variable most fleet-size conversations skip entirely, and it's arguably the most important one. If each agent in a chain is individually 95% reliable, a three-agent sequential chain's end-to-end reliability isn't 95% — it's closer to 86%. A six-agent chain drops below 74%. This is why the debugging challenges covered in Debugging a Multi-Agent System get disproportionately harder as fleets grow: you're not just adding agents, you're multiplying the number of places a small, individually-reasonable error can enter and compound before anyone notices. Every additional agent in a sequential chain is a tax on end-to-end reliability, even when every individual agent is performing well — which means fleet size decisions have to weigh not just "can this agent add value" but "what does adding this agent do to the probability the whole chain is right."

Parallel fan-out subagents — the three-to-five pattern for independent research — don't compound this way, because they're not sequential; a mistake in one parallel subagent doesn't propagate into the others, it just needs to be caught at the synthesis step. Sequential handoff chains are where compounding risk actually bites, which means the framework has to treat "how many agents in parallel" and "how many agents in sequence" as genuinely different questions with different ceilings.

Putting the three together

A rough way to combine them: let decomposability set your parallel fan-out ceiling (usually three to five, rarely more before you're forcing artificial splits), let token budget at real production volume set whether you can afford that fan-out at all, and let compounding reliability set a hard ceiling on how many agents you chain sequentially before the end-to-end success rate drops below what your use case tolerates. A customer-facing pipeline where a wrong answer is costly should stay to two or three sequential steps with a human checkpoint before anything consequential — the placement question covered in Human-in-the-Loop Checkpoints for Autonomous Agent Fleets — while an internal research tool with a human reviewing every output can tolerate a longer chain, because the compounding error gets caught by the same human who was going to review the output anyway.

If you can't answer "why this many agents, and not one fewer" for every member of your fleet, the honest answer is probably that nobody designed the fleet size — it accumulated.

A worked example: sizing one fleet against all three variables

Take a concrete case: an internal tool that drafts vendor-comparison reports from a purchasing request. Decomposability first — the task genuinely splits into checking each of three to four candidate vendors' pricing, checking each vendor's compliance history, and checking delivery-timeline feasibility, which lands comfortably inside the three-to-five parallel ceiling without forcing any artificial splits. Token budget next — at an expected volume of maybe forty of these reports a day, even a 15x-taxed five-subagent fan-out is a trivial line item next to what those reports would cost in analyst hours, so the budget variable doesn't constrain the design at all here. Compounding risk last — the report drafting is internal, reviewed by a human purchasing manager before any vendor is actually engaged, which means the chain can tolerate more sequential steps than a customer-facing pipeline would, because the human review at the end is itself the checkpoint that catches a compounding error before it becomes a real commitment.

The resulting fleet: five parallel research subagents feeding one synthesis step that drafts the report, no further sequential chain after that, and a human checkpoint before the report's recommendation gets acted on. Every one of those design choices traces to one of the three variables, which is the actual test of whether a fleet size was reasoned through or just accumulated — you should be able to point to which variable is doing the work at each junction, not just gesture at "this felt about right."

The number is almost always smaller than the org chart suggests

Across the failure patterns this series has covered — swarms without an owner, decompositions that weren't actually independent, handoffs that dropped context, checkpoints placed at the wrong seam — a strikingly large share trace back to fleets that grew past the point their task actually justified. Gartner's forecast that up to 40% of enterprise applications will carry task-specific agents by 2026 is a forecast about adoption, not about fleet size, and the two get conflated constantly: more organizations using agents does not mean each of those organizations needs more agents per task. The teams whose systems are still running cleanly a year after launch are disproportionately the ones that treated fleet size as a number to justify line by line, not a number that grows by default every time a new capability feels tempting to bolt on.

Three to five in parallel. Two to three in sequence, fewer where the stakes are high. A checkpoint before anything irreversible. That's not a ceiling on ambition — it's the shape that's actually been surviving contact with production in 2026, and the burden of proof should sit with whoever wants to add the sixth agent, not with whoever's asking why it's there.

Part of the "The Subagent Economy" series on aiskill.market.