Agent capacity planning needs a physical failure assumption
Grid stress belongs in workload planning. Ask what pauses, what resumes and what capacity remains independent before assuming another endpoint is a fallback.
I would add one question to an agent capacity review: what happens if the infrastructure supplying the work has to reduce its load? A second endpoint is an answer only if its capacity remains available under the same event.
PJM’s June 30 operations update makes the physical dependency concrete. During forecast extreme heat, the grid operator described emergency approval to direct transmission owners, as a last resort before voltage reduction or load shedding, to curtail data centres and other large loads with backup generation. The notice concerns specific emergency preparations. It does not establish that every AI customer would lose service.
That distinction matters. A facility may have backup generation, a provider may move work, and an application may never see an interruption. The useful engineering response is to investigate the dependency, rather than turn a grid notice into a prediction that an API will fail.
Start with the work that can wait
A capacity plan usually becomes more useful when it stops treating all requests as equivalent. An interactive user waiting for an answer, an overnight document batch and a speculative background research job have different consequences when delayed.
For a hypothetical document-processing service, I would decide in advance which jobs can pause without losing useful progress. Preserve the last confirmed result and the position in the input set. Make it clear whether an interrupted external action should be retried, checked for completion or sent for review.
That last distinction is easy to miss. Restarting analysis may waste compute. Repeating an already completed payment, message or database update can create a separate problem. Capacity recovery should not turn uncertainty about completion into automatic duplication.
The plan needs a visible degraded mode too. If the service accepts work it cannot finish within its usual window, tell the user the revised expectation. A growing queue hidden behind successful request acknowledgements can look healthy until the deadline arrives.
Check whether the fallback shares the constraint
I would ask a supplier which failure assumptions its resilience design addresses and what the customer can verify. Two model names may still depend on common infrastructure. Two regions may offer stronger separation, but that does not establish independence from every shared service or capacity constraint.
The point is not to demand an impossible promise of no correlated failure. It is to distinguish a tested recovery path from a second URL in configuration. Under simulated reduced capacity, can the application slow admission, prioritise important work and resume paused jobs without losing their state?
This is a proposed exercise, not a benchmark of any provider’s power resilience. Application teams also do not control grid operations or facility backup systems. Their responsibility is narrower: understand the service boundary and design their workload’s response to reduced availability.
A service-level agreement belongs in that discussion, but compensation after an incident does not itself complete a delayed business task. Review the contractual commitment and the operational recovery separately. Both can be useful; neither should stand in for the other.
I would finish the review with a small recovery demonstration. Pause a disposable batch, reduce its available workers, then restore them. Inspect completed outputs, duplicates, outstanding jobs and the user-visible status. If those cannot be reconciled in a test, adding more peak capacity will not repair the recovery story.
Plan agent capacity around work that can pause and resume safely, and verify that the fallback survives the constraint it is meant to cover.
