Plan three capacities, not one: how much work the agent and the systems it calls can process, how much of its held and escalated work your people can review in time, and how much work people can take back if the agent stops. The third is the one most plans leave out, and it decides how safe the others are.
Why is agent capacity different from staff capacity?
An agent does not get tired, but it is not unlimited. It is bounded by the model provider's rate limits, by the systems it connects to, and by your budget. A core banking system that accepts a fixed number of queries a second will cap the agent long before the model does.
More importantly, every agent creates work for people. At depth 2 every draft needs a sender. At depth 3 some actions are still held for approval and some cases escalate. Plan for the agent's throughput alone and you will build a queue that nobody has time to clear.
What do you need to know before you plan?
- Volume and its shape. Daily averages hide month-end, payroll days, renewal seasons and the morning spike after a weekend.
- The agent's certified depth, and the depth each action needs. This sets how much work comes back to people.
- Hold and escalation rates from shadow runs or certification, per case type.
- Limits in connected systems: query rates, batch windows, maintenance periods.
- Fallback handling time: how long people take per case without the agent.
How do the three capacities break down?
| Capacity | What sets it | Who owns it | What you plan for |
|---|---|---|---|
| Agent throughput | Model rate limits, connected system limits, budget | Platform or IT owner | Peak volume with headroom |
| Review capacity | Held items, drafts and escalations per hour, reviewer skill | Process owner | Every held item cleared within its service level |
| Fallback capacity | People and hours available if the agent is stopped | Operations lead | The agent at depth 1, or off, during a peak |
The fallback row is not a disaster scenario. A lapsed certificate or a run that clears no depth drops the agent to depth 1 the same day, and a provider outage can stop it entirely. Either can happen in your busiest week. If your staffing assumes the agent is always on at full depth, one bad run becomes a backlog.
What does a worked plan look like?
Say a utility's billing team handles 6,000 account queries a week, with double that in the week bills go out. An agent at depth 3 resolves routine address and payment-date changes and drafts everything else for a person.
Shadow data shows it resolves about half of queries on its own, drafts 40 in every hundred, and escalates the rest. In a normal week that is 2,400 drafts and 600 escalations for people. In billing week it doubles. At two minutes per draft and ten per escalation, billing week needs about 360 reviewer hours. The team rosters for that, not for the average.
Then they plan the bad day. If the agent drops to depth 1 in billing week, people handle all 12,000 queries at the old rate. The team cannot staff that fully, so the plan says which queries wait, which go to an overflow team, and which customer messages change. That plan is written and signed before go-live, not improvised during the incident.
Which controls keep the plan honest?
- Agent, depth 1: reports volumes and queue ages every hour. Evidence: a filed record of throughput and backlog.
- Person: owns the held queue with a target time to clear each item. Evidence: time from hold to decision on every verdict.
- Person: reviews capacity monthly against actual hold and escalation rates, which change as the agent widens or narrows. Evidence: the revised plan, versioned.
- Rehearse the fallback once a quarter by taking the agent off for an hour in normal volume. Evidence: the time it took people to absorb the work.
These belong in the AI agent deployment plan from the start, with the fallback written into the AI agent rollback plan. The people side, including when to change rosters as the agent takes volume, is covered in planning staffing when an AI agent takes on volume. For the full sequence, see our guide to deploying an AI agent.
Questions people ask
Should the agent queue work when it reaches a rate limit?
Yes, with a visible backlog and an age limit. Past that limit, items should route to people rather than wait silently. A queue nobody can see is the same as lost work.
Does adding a second agent double capacity?
Not if both call the same connected system or share the same reviewers. Capacity is usually limited by the slowest shared resource, which is often a person.
How much headroom should we plan?
Enough to handle your known peak with the agent one depth lower than normal. That margin covers both a surge and a temporary drop in what the agent may do.