--- title: Error Recovery in Agentic Systems description: APIs fail. Users change their mind. Flights sell out mid-booking. How an AI agent recovers from failure defines its quality. canonical: https://nowah.xyz/blog/error-recovery-agentic-systems lastModified: "2026-08-07T08:06:03.516Z" --- # Error Recovery in Agentic Systems APIs fail. Users change their mind. Flights sell out mid-booking. How an AI agent recovers from failure defines its quality. An AI agent that works perfectly when everything goes right is table stakes. The quality of an agent is defined by [what happens](/blog/what-happens-after-you-book) when things go wrong. In a travel booking system, things go wrong constantly. APIs time out. Flights sell out between search and booking. Payment processors return cryptic errors. Users change their mind mid-transaction. Networks drop. Third-party services go down for maintenance at the worst possible time. Roughly 3% of flights experience significant delays or cancellations daily. Booking errors can cost travelers hundreds or thousands of dollars. The agent cannot shrug off failures. It has to recover gracefully, quickly, and correctly. I want to walk through the taxonomy of failures we handle, the recovery strategies we use, and the architectural decisions that make recovery possible. ## The failure taxonomy ![Illustration for this section](https://pics.nowah.xyz/website-media/ai-research-009-img-1.webp) We classify failures into four categories based on their cause and recoverability. **Transient failures** are temporary. An API times out because of a momentary load spike. A network hiccup drops a connection. These failures resolve themselves if you wait and retry. Recovery strategy: exponential backoff with retry. **State failures** occur when the world has changed between steps. You searched for a flight, it was available, the user selected it, and by the time you tried to book, the fare was gone. The information was correct when retrieved but stale by the time it was acted on. Recovery strategy: re-query and present alternatives. **Logic failures** happen when the agent makes a bad decision. It selects the wrong tool. It misinterprets a user message. It passes incorrect parameters to an API. Recovery strategy: detect the error from the API response, reason about what went wrong, and self-correct. **Systemic failures** are when entire services are unavailable. The flight data provider is down. The payment processor is experiencing an outage. Recovery strategy: [graceful degradation](/blog/graceful-degradation-slow-ai) with honest communication. Each category requires a different recovery approach. Treating all failures the same, with a generic "something went wrong, please try again" message, is the hallmark of a system that was not designed for failure. ## Graceful degradation When a tool call fails, the worst outcome is a complete conversation breakdown. The agent stops responding, or responds with an [error message](/blog/anatomy-of-perfect-error-message) that offers no path forward. Graceful degradation means: even in failure, deliver maximum value. If the flight search API is down, the agent cannot search for flights. But it can still be useful. It can discuss destination options, help the user narrow their preferences, check hotel availability through a different provider, and save the flight search for when the API recovers. The conversation continues even though one capability is temporarily unavailable. If a booking fails mid-process, the agent does not just say "booking failed." It explains what happened, checks whether the fare is still available, and if not, immediately searches for alternatives. The user should never be left in a dead end. We measure graceful degradation with a metric we call partial completion rate: when a task cannot be fully completed due to failure, what percentage of the possible value was still delivered? A search that returns hotel results but not flight results is partial completion. A booking that fails but immediately presents alternatives is partial completion. Zero value delivered is a system failure. ## Retry and fallback ![Supporting diagram](https://pics.nowah.xyz/website-media/ai-research-009-img-2.webp) Transient failures get retries. Our retry strategy uses exponential backoff: first retry after 1 second, second after 2 seconds, third after 4 seconds. Most transient failures resolve within the first retry. But retries are not free. Each retry adds latency to the user's experience. We cap retries at three for any single tool call and surface a status update to the user after the first retry: "The search is taking a moment, still working on it." Transparency during retry is important. The user should know the agent is working, not stuck. When retries fail, the agent falls back to alternative approaches. If one flight data source is unavailable, we can sometimes query a different data path. If a specific payment method fails, the agent suggests an alternative. Fallback is not always possible, but when it is, it is dramatically better than giving up. ## Idempotency in booking The scariest failure mode in a booking system is the double-booking. Here is how it happens: 1. User confirms a booking 2. Agent calls the booking API 3. The network times out before the response arrives 4. Did the booking succeed or not? The agent does not know 5. If the agent retries, it might create a duplicate booking 6. The user gets charged twice for the same flight We prevent this with multi-layer idempotency. **Client layer:** Every booking request gets a unique idempotency key generated before the first attempt. If the agent retries, it sends the same key. The server recognizes the duplicate and returns the result of the first attempt. **Server layer:** The booking service records every transaction attempt with its idempotency key. Before processing, it checks for existing records. If a matching attempt exists, it returns the prior result without re-processing. **Payment layer:** The payment processor has its own deduplication. Even if our server-side check fails, the payment provider rejects duplicate charges with the same reference ID. Three layers of protection. Any single layer might fail. All three failing simultaneously is vanishingly unlikely. ## Communicating errors without eroding trust How an agent talks about errors matters as much as how it handles them technically. Bad error communication: "Error 500: Internal Server Error." Bad error communication: "Something went wrong. Please try again later." Bad error communication: "I'm so sorry! I made a mistake! Please forgive me!" Good error communication: "That fare is no longer available, but there are similar options. Here are three alternatives at comparable prices." The principles we follow: **Be specific.** Tell the user what happened, not that something happened. "The $480 fare sold out" is better than "there was an error." **Be solution-oriented.** Every error message should include a next step. "The fare sold out. Here are three alternatives" beats "the fare sold out" alone. **Be proportionate.** Do not apologize excessively for minor issues. Over-apologizing makes the user worry more than the situation warrants. A search taking a few extra seconds does not need an apology. A booking failure does. **Be transparent about uncertainty.** If the agent does not know whether a booking succeeded, it says so: "The booking may have processed but I have not received confirmation. Let me check." Then it actually checks. Proactive AI [disruption handling](/blog/disruption-handling-ai-killer-app) saves travelers 60% or more on rebooking costs compared to waiting for human assistance. Speed matters. But speed without clear communication creates anxiety. The combination of fast recovery and clear communication is what builds trust. ## Building antifragile agents An antifragile system does not just survive failure. It gets better because of it. Every production failure at [Nowah becomes](/blog/platform-thesis-nowah-becomes-infrastructure) a test case. We log the failure, analyze the root cause, create an evaluation scenario that reproduces it, implement a fix, and verify the fix against the eval scenario. The failure library grows continuously. Over time, the agent becomes more robust not because we anticipated every failure, but because we learned from every failure that occurred. The system is antifragile in the Nassim Taleb sense: it benefits from the stressors it encounters. This requires good observability. Every tool call, every error, every retry, every recovery attempt is logged with enough context to reconstruct what happened. When a user reports a problem, we can trace the exact sequence of events that led to it. The goal is not zero failures. That is impossible in a system that depends on [external APIs](/blog/circuit-breakers-external-apis), network connectivity, and real-time inventory. The goal is zero unrecovered failures: every failure is either recovered automatically by the agent or surfaced to the user with a clear path forward. Travel booking errors are not abstract engineering problems. They cost real money, disrupt real plans, and create real stress. The quality of an AI travel agent is measured not by how well it works when everything is fine, but by how well it handles the inevitable moments when things break. --- 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](https://app.nowah.xyz).