Every AI feature has a moment when the model call fails: a timeout, a rate limit, an empty or malformed response. In most codebases that moment is handled by whoever wrote the call, usually with a generic catch block and a vague error message. That is a mistake, because what the user sees in that moment is a product decision.
Here are the questions worth answering *before* the incident, not during it:
- Is there a useful degraded mode? Sometimes the honest answer is yes. A search box can fall back to plain keyword search. A summarizer can show the first paragraph. A classifier can route to a human queue. A degraded result that is clearly labelled often beats a spinner followed by an apology.
- Is a wrong answer worse than no answer? For some features, a confident fallback is dangerous. If a stale or generic response could mislead someone, the right fallback is a clear "we can't answer this right now" and a way to proceed manually.
- Does the user know what happened? Silent fallbacks hide quality drops from you as well as from them. Record every fallback as an event you can count, so a rising rate shows up on a dashboard rather than in a support ticket.
- Can the fallback itself fail? A fallback that calls the same provider through the same network path is not a fallback. Test the degraded path on its own.
A small exercise: list your feature's failure modes (timeout, rate limit, refusal, malformed output, empty retrieval) and write one sentence for each describing exactly what the user sees. If you cannot write the sentence, you have found a decision nobody made.
Then put that table somewhere findable and test each row at least once in staging. The goal is not to prevent failures; it is to make sure that when they happen, the behavior is something your team chose on purpose.