What it does: Instead of propagating a failure or halting the pipeline entirely, each agent has a defined fallback behavior for when its primary function is unavailable — a simpler, safer response that keeps the system operating at reduced capability.
Fallback hierarchy (most to least desirable):
The customer service example (Scenario 5): Instead of all 6 agents failing when the LLM API was unavailable, each could have fallen back to: keyword-based intent classification → templated responses for common queries → human handoff for unmatched cases. Customers would have received slower, less personalized responses — but responses, not silence.
What it does: When a request to a dependency fails, the retry schedule uses increasing delays: attempt 1 after 1s, attempt 2 after 2s, attempt 3 after 4s, attempt 4 after 8s. Jitter adds a random offset (±25%) to each delay to prevent all agents from retrying simultaneously.
Why fixed-interval retry is dangerous: If 4 agents all fail simultaneously and all retry every 2 seconds, every 2 seconds there is a burst of 4 simultaneous requests hitting the recovering dependency. The burst may repeatedly push the recovering dependency back into failure. The solution is not to space retries — it's to randomize them so the bursts don't align.
Maximum retry budget: Retry policies must define a maximum retry count and a maximum total retry duration. An agent that retries indefinitely with exponential backoff will eventually have a retry interval of hours — at which point it is effectively stuck. Maximum retry budget + circuit breaker ensures the system transitions to fallback mode rather than waiting indefinitely for a recovery that may not come.
Ask your team: when one of your AI agents fails, does the system keep retrying it endlessly — or does it give up gracefully and deliver a partial result to the user? Endless retries on a failing service can bring down other services that were working fine. Ask what the fallback plan is when an agent can't complete its task.