Agentic AI Chapter 11: Reliability Controls for Agentic Systems

Part of the Agentic AI study series.

An agent can make individually reasonable calls and still overwhelm a dependency, spend too much, or leave work in an unknown state. Reliability controls shape how much work enters the system, how much runs at once, how long it can run, and what happens when a dependency degrades.

Admit work at a sustainable rate

Rate limiting controls how many requests enter over time. A fixed window is simple but can allow a burst at the boundary between windows. A sliding window counts over a rolling interval and gives smoother limits. A token bucket allows short bursts while keeping a long-term average rate; a leaky bucket processes work at a steadier pace. Choose the algorithm based on whether the service needs simplicity, burst tolerance, or smooth traffic.

Rate limits alone do not control simultaneous work. Set a concurrency limit and a bounded queue as well. When the queue fills, backpressure should slow, reject, or defer upstream requests. An unbounded queue only moves overload into memory and increases wait times.

Protect dependencies with a circuit breaker

A circuit breaker has three states. In closed, requests flow normally. If failures pass a threshold, it opens and stops or quickly rejects calls to the unhealthy dependency. After a wait period, it enters half-open and allows a small number of probes. If those succeed, it closes gradually; if they fail, it opens again.

Pair this with bounded retries and backoff. Retries can help with transient failures, but repeated or synchronized retries can add load to an already unhealthy service. Apply limits and jitter, and avoid retrying permanent errors.

Bound time and resource use

Use separate deadlines for queue wait, agent execution, and the customer response. Each answers a different question: how long work may wait before starting, how long the agent may run, and when the user needs an answer. Propagate deadlines to tools so downstream calls do not continue after the request can no longer use their result.

Enforce per-run token, time, cost, and tool-call budgets. Estimate before execution, track actual use during execution, and reconcile afterward. If the next step would exceed a hard limit, stop safely and record why instead of silently overrunning the budget.

Reconcile unknown outcomes

A timeout or cancellation does not prove that a business operation failed. The remote service may have completed the action even though the agent did not receive its response. Record the result as unknown, retain the operation ID, and query the system of record before retrying. Use idempotency keys to prevent duplicate side effects, and escalate when the result cannot be confirmed.

When a dependency recovers, release queued work gradually. Start with a small batch, increase concurrency in steps, and monitor latency and error rates. If errors rise again, slow down or reopen the circuit breaker.

Checkpoint: remember

• Combine rate limits with concurrency limits, bounded queues, and backpressure.
• Use circuit breakers to stop calls to unhealthy dependencies and probe recovery carefully.
• Set queue, execution, and customer deadlines, plus token, time, cost, and tool-call budgets.
• Estimate resource use, track it during execution, and reconcile actual use afterward.
• Treat timed-out side effects as unknown until confirmed; use operation IDs and idempotency.
• Ramp queued work up gradually after recovery and keep monitoring.

Previous: Error Handling and Recovery · Back to the series start