The fallback is part of the AI experience

An AI feature’s weakest moment is not always a wrong answer. It is the moment the system cannot answer and leaves the user with nowhere to go.

A generic “Something went wrong” tells a person nothing about whether they should retry, rephrase, provide more context, or switch to another path. The fallback is part of the product interface, not an implementation detail.

Give uncertainty a useful shape#

Start by distinguishing three cases: the system lacks information, the request is ambiguous, or the model’s output failed a quality check. They need different next steps.

• If a source is missing, say which source or detail would help.
• If the request has two plausible meanings, show the choices and let the user select one.
• If the answer fails a quality threshold, say that the feature could not produce a dependable result and offer the existing non-AI route.

Do not ask the user to “try again” when another attempt is unlikely to change the evidence. Do not present an uncertain answer as complete just to avoid an empty state.

Keep the user’s task moving#

A good fallback preserves what the user already entered, explains what happens next, and avoids making them start over. If the system can safely complete part of the task, label that partial result. If it cannot, make the manual path easy to find.

Before launch, test at least these states: no relevant source, conflicting sources, unclear intent, a timed-out request, and a low-confidence result. For each one, specify the message, the available action, and whether the user’s input is retained. Treat a repeated timeout differently from a single slow response: after a retry budget is reached, move the person to another path rather than asking them to keep clicking.

The practical rule: whenever the AI path stops, the product should still tell the user what they can do next.