Error Handling in Conversational Systems

On a traditional website, error handling looks like this: a red banner at the top of the page says "Something went wrong. Please try again." Or a modal pops up with an error code. Or the page just fails to load and you refresh.

In a conversational AI system, none of these patterns work. There's no banner. There's no modal. There's no page to refresh. The AI is your interface, and when something goes wrong, the AI has to explain what happened, propose a recovery path, and continue the conversation as if errors are a normal part of working together.

This is harder than it sounds. Traditional error handling is about displaying state. Conversational error handling is about reasoning through failure and communicating about it in natural language, in real time, without breaking the user's trust.

Error modals are dead

When our flight search API returns an error, we can't pop up a modal that says "Error 500: Internal Server Error." The user is in a conversation. They asked for flights. The appropriate response is something like: "I wasn't able to search that route right now. This might be a temporary issue with our flight data providers. Want me to try again, or should we look at different dates?"

That response contains three things a modal never could: an explanation (what happened), a prognosis (it might be temporary), and options (retry or adjust). The user stays in the conversation flow. They don't lose context. They don't feel like the system broke.

60% of users abandon complex booking flows on traditional OTAs, and errors are a contributing factor. When an error forces you out of your flow (back to the search page, or worse, back to the homepage), the cognitive cost of restarting is high. Many users just leave.

In a conversation, errors are conversational. The agent acknowledges the problem and keeps going. That continuity is worth a lot.

Translating technical errors into conversational language

Behind the scenes, our system produces structured error data: error codes, HTTP status codes, provider-specific error messages, timeout durations. None of this is useful to a user.

The agent's job is to translate technical errors into conversational explanations. We do this with a mapping layer between error categories and conversational responses.

No results found. "I searched for direct flights from Austin to Reykjavik and didn't find any. That route doesn't have direct service. Want me to look at connecting flights, or try a different departure city?"

Provider timeout. "My flight search is taking longer than usual. This happens sometimes with busy routes. I'm still working on it, but if you'd prefer, I can try a different approach."

Sold out. "That specific flight just sold out. The other two options I showed you are still available. Want one of those, or should I search again?"

Payment declined. "Your payment didn't go through. This could be a card issue or a temporary problem with the payment system. Want to try a different card, or should we try again in a few minutes?"

Each error category has a template that the agent uses as a starting point, but the actual response is generated by the model using the template as guidance and the conversation context for specificity. This means the response fits naturally into the conversation rather than feeling like a canned message.

Retry strategies the agent orchestrates

The agent doesn't just report errors. It decides what to do about them.

For transient errors (timeouts, rate limits, temporary outages), the agent retries automatically. The user sees "Let me search again..." and usually the retry succeeds. If three retries fail, the agent gives up and explains the situation.

For partial failures, the agent adapts. If the flight search returned results but the detailed fare info for one option failed, the agent presents the two complete options and notes that a third is being checked. If the fare info eventually comes back, it's added to the conversation.

For permanent failures, the agent pivots. "I can't find any flights for that route" is a permanent failure. The agent doesn't retry endlessly. It suggests alternatives: different routes, different dates, different airports.

The retry logic is in the orchestration layer, not in the model itself. The model signals that something went wrong and what category of error it is. The orchestration layer decides whether to retry, how many times, with what backoff, and when to give up. Then it feeds the outcome back to the model for conversational presentation.

Partial failure handling

Real systems have partial failures constantly. One API call succeeds while another fails. One provider is fast while another is slow. One part of a booking works while another doesn't.

In a conversation, partial failures need to be handled with nuance.

Search partial failure. The flight search returned results but the hotel search failed. The agent presents the flight results and says "I'm having trouble with hotel search right now. Want to lock in the flight first and I'll check hotels in a minute?"

Booking partial failure. Payment was authorized but the booking confirmation failed. This is the most delicate case. The agent says "Your payment is on hold (not charged) while I work on confirming the booking. Give me a moment." The system retries the booking. If it ultimately fails, the payment hold is released and the agent explains.

Data partial failure. Flight results came back but price verification for one option failed. The agent presents it with a note: "I'm still confirming the exact price for this option. The other two are verified."

Each partial failure scenario has a specific handling path. The agent doesn't just show what worked and hide what didn't. It communicates about the incomplete state and sets expectations about resolution.

Graceful degradation

When an upstream service is down, the agent should adapt its capabilities, not crash.

If the flight search service is completely unavailable, the agent can still help with trip planning, answer travel questions, check visa requirements, and do other things that don't require flight data. It says "Flight search is temporarily unavailable, but I can help with other parts of your trip planning. Want to look at hotels or talk about your itinerary?"

If the payment service is down, the agent can still search and present options. It says "I can find flights and hotels for you, but booking is temporarily unavailable. I'll save your selections and we can book as soon as the system is back."

This degradation is possible because our agent is multi-capability. It has many tools, and the unavailability of one doesn't disable the others. The agent dynamically adjusts what it offers based on which services are currently healthy.

Real-time monitoring and alerting for all services means the agent knows which capabilities are available at any moment. The health status of each backend service feeds into the agent's context, so it can proactively route around problems instead of discovering them when a tool call fails.

Error analytics for conversational systems

Traditional error dashboards track HTTP error rates, response times, and error codes. These are still useful, but they miss the conversational dimension.

We track conversation-level error metrics:

Error recovery rate. When an error occurs in conversation, how often does the conversation recover and continue to a successful outcome (booking, answered question)?

Error abandonment rate. How often does a conversational error cause the user to leave?

Error explanation quality. Sampled manually: did the agent's error explanation make sense? Did it offer useful recovery options?

Cascading error rate. How often does one error lead to a chain of follow-up errors? A flight search failure that leads to a booking failure that leads to a payment error is a cascade that should be caught early.

These metrics give us visibility into how errors affect the user experience, not just the system state. An HTTP 500 that the agent handles gracefully (retry succeeds, user never notices) is very different from an HTTP 500 that kills the conversation.

Conversational AI reduces booking time by three to five times, partly through smoother error recovery. The speed advantage of conversation disappears if errors force the user to start over. Good error handling preserves the speed advantage by keeping the conversation moving forward, even when things go wrong.

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.