Back-Pressure for Agent Fleets: Staying Stable When Upstream Systems Slow
It is the last working day of the month at a bank's operations centre. Forty agents are posting reconciliation entries to the core banking system, alongside the month-end batch jobs that always slow it down. Response times climb from a few hundred milliseconds to several seconds. Each agent, seeing timeouts, retries its request at once. The retries add load, which slows the system further and triggers more retries. Within half an hour the core banking team throttles all automated traffic, and the human operations staff find their own screens frozen. Agent rate limiting is rarely discussed until a fleet turns an ordinary slowdown into an outage.
Why agent fleets amplify slowdowns
A single agent that retries a failed call is harmless. A fleet of agents, each retrying independently, behaves like a crowd pushing on a door that opens inward. Every retry is reasonable from the agent's point of view, and together they multiply the load on a system that was already struggling.
Agents also face limits of their own. Model providers cap requests and tokens per minute, so a busy fleet can find its language model calls rejected at the same moment its downstream systems slow down. An agent that treats a rate-limit response as a transient error and retries immediately makes the problem worse for every other agent sharing the same quota.
The systems agents touch were usually sized for human operators. A core banking platform or an ERP can comfortably serve hundreds of staff working at human speed. It may struggle with a fraction of that number of agents working at machine speed, especially during the periods when batch processing already consumes capacity.
Throttling and graceful retry
The first control is a concurrency limit per downstream system, enforced across the fleet. The question to ask is how many simultaneous requests the core banking system can absorb from all agents combined, never how many each agent may make. A shared limiter enforces that number, and agents wait for capacity instead of competing for it.
Retries need discipline at the level of the fleet. Exponential backoff with random jitter spreads retries out so they do not arrive in synchronised waves. Each workflow carries a retry budget, after which the task is parked for later or handed to a person. A circuit breaker watches error rates on each downstream system and, when they cross a threshold, stops sending traffic for a cooling period, giving the system room to recover.
Retries are safe only if repeating a request cannot duplicate its effect. Every write an agent makes should carry an idempotency key, so that a posting retried after a timeout is recognised as the same posting and applied once. Without that, graceful retry becomes a source of duplicate entries.
Deciding what waits when capacity falls short
When capacity is scarce, the fleet must choose what to process first. Work should be queued by priority and deadline. A customer waiting on a payment status deserves capacity ahead of a reconciliation that can complete overnight. Low-priority work can be deferred automatically when the system is under strain and resumed when load falls.
Visibility makes this manageable. Queue depth and throttling events for each downstream system should appear on a dashboard the operations team already watches, so a growing backlog is seen before it becomes an incident. A self-healing automation runtime such as FORGE manages agents as a fleet in this way, with shared limits and prioritised queues.
The retry storm at month-end
The scene at the start of this piece happened to a bank operations team in its second month of operating reconciliation agents at scale. Each agent had been configured with three immediate retries on timeout, a setting that worked well during testing, when the agents executed one at a time against a quiet test environment.
At month-end, the retries compounded exactly as described, and the core banking team throttled all automated traffic to protect the system. A second problem surfaced in the reconciliation the following day. One of the agents' workflows lacked idempotency keys, and a handful of postings that had succeeded but timed out before confirmation had been posted twice. The duplicates were reversed before the books closed.
Every write now carries an idempotency key, enforced at the gateway, and a fleet-wide concurrency limit with jittered backoff and a circuit breaker replaced the per-agent settings. Reconciliation work is marked low priority during month-end windows, so it yields to customer-facing traffic and completes overnight.
An agent fleet is a new kind of load on systems that were designed for people. Treated carefully, it can absorb the slow periods those systems always have, without turning them into outages. A head of IT operations should ask what happens to the fleet when the slowest system it depends on halves its throughput, and whether that scenario has been tested. A fleet that degrades gracefully under that test delivers outcomes that survive scrutiny.
Related: Agentic AI
Tell us the number you need to move.
…outcomes that survive scrutiny.