Error States in AI Products

Every AI product fails. Models misunderstand queries. APIs time out. Search returns no results. Payment processing hiccups. The question is not whether your AI travel agent will encounter errors. The question is whether users trust it more or less after the error, based on how it handles the situation.

Most AI products handle errors terribly. "Something went wrong. Please try again." "I am sorry, I cannot help with that." These responses tell the user nothing useful and leave them stranded. They erode trust quickly, and in a domain like travel booking where the stakes are real money, eroded trust means lost users.

I have a strong opinion on this: error handling is the most underinvested area of AI product design. Teams spend months on happy-path experiences and minutes on error states. This is backwards. The happy path is where you meet expectations. The error path is where you build trust.

The error spectrum

Not all errors are the same, and they should not be treated the same. We think about errors on a severity spectrum:

Minor misunderstandings. The agent interprets "not too expensive" differently than the user intended. The fix is simple: clarify and adjust. "When you say not too expensive, are you thinking under $150 per night or under $250?"

Ambiguity. The user says "book the early one" when two of three options depart before noon. The agent needs to resolve this: "Both option A (7:15 AM) and option B (10:30 AM) are morning flights. Which one?"

Partial failures. The flight search worked but the hotel search timed out. The agent can present what it has while retrying what it does not: "I found great flights. I am still working on hotels. Here are the flight options while we wait."

Tool failures. An external API is down. The agent cannot search for flights right now. It should explain what happened and offer alternatives: "The flight search system is temporarily unavailable. I can check again in a few minutes, or I can start with hotels while we wait."

Complete failures. Something broke badly. The agent cannot function. This should almost never happen if the system has proper fallbacks, but when it does, honesty is the only option: "I am experiencing a technical issue and cannot process your request right now. Your conversation is saved and I will be back shortly."

Each level requires a different tone, a different amount of information, and a different recovery path. Treating all errors with the same generic message is like a doctor saying "something is wrong" regardless of whether you have a cold or a broken arm.

The apology pattern

When the agent makes a mistake, the apology needs to accomplish three things:

Acknowledge specifically. Not "something went wrong" but "I misunderstood your dates. You meant April 3-10, not March 3-10."

Take responsibility. The agent should not blame the user even when the user's input was ambiguous. "I should have confirmed your dates before searching" is better than "your dates were unclear."

Recover immediately. The apology should come with an action. "I am re-searching with the correct dates now" is infinitely better than "please try again."

Trust can survive errors if the recovery is competent and transparent. In user studies, people who experienced an error that was handled well reported higher trust than people who never experienced an error at all. The reasoning: they saw how the system behaves under stress, and it behaved well.

Graceful degradation

Partial results are almost always better than no results. This principle guides our error design.

If the agent searched 500 flights and 480 returned successfully but 20 timed out, it should present the 480, not fail the entire search. If hotel availability data is stale by two hours but was fresh when cached, it should present the cached data with a note: "These prices were checked 2 hours ago. I will verify the exact price before booking."

The user is trying to plan a trip. They need information to make decisions. Perfect information delivered eventually is less useful than good information delivered now.

We designed specific degradation levels:

• Full quality: all data sources responded, results are complete and fresh
• Slightly degraded: one data source was slow, results are 95% complete
• Noticeably degraded: a key data source failed, results are partial but useful
• Minimally useful: most data is unavailable, but cached results or alternatives exist
• Non-functional: nothing works, communicate clearly and recover gracefully

The user should only notice degradation at level 3 or below. Levels 1 and 2 should be invisible. This requires engineering effort in fallback logic, but it dramatically improves the perceived reliability of the product.

Recovery prompts

When the agent misunderstands a request, the worst response is to ask the user to repeat themselves identically. Repetition does not resolve ambiguity.

Instead, we use recovery prompts that help the user restate their request in a way the agent can better understand:

Offering interpretations. "Did you mean flights on April 3rd, or flights that cost around $403?"

Requesting specifics. "Could you tell me the city you are flying from? I want to make sure I search the right airports."

Suggesting alternatives. "I could not find any direct flights for those dates. Would you like me to check one-stop options, or try different dates?"

Recovery prompts reduce conversation abandonment after errors. Users who receive a helpful recovery prompt continue the conversation at much higher rates than users who receive a generic "try again" message. The difference is that recovery prompts give the user a clear path forward instead of dumping the problem back on them.

Building resilience into the experience

Here is the counterintuitive insight: users who survive an error well become stronger believers in the product. They have seen the edge case. They have seen the agent handle it gracefully. They now have evidence that the system works even when things go wrong.

This is analogous to how trust works in human relationships. You do not fully trust someone until you have seen them handle a difficult situation. The same applies to AI agents. A flawless experience is good but fragile; the user wonders what happens when something goes wrong. An experience that included a well-handled error is resilient; the user knows.

For AI travel booking, where booking errors can cost hundreds of dollars, this matters enormously. Users need confidence that the agent will not silently fail on a payment or book the wrong dates. Demonstrating competent error handling, even on small errors, builds that confidence incrementally.

Design your errors with the same care you design your features. In many cases, they matter more.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.