--- title: "Circuit Breakers for AI Travel: Handling Upstream Failures" description: "When a flight provider goes down, the AI agent must degrade gracefully, not crash. Here is how circuit breakers work in an AI agent context." canonical: https://nowah.xyz/blog/circuit-breakers-ai-travel-upstream-failures lastModified: "2026-08-07T03:46:42.893Z" --- # Circuit Breakers for AI Travel: Handling Upstream Failures When a flight provider goes down, the AI agent must degrade gracefully, not crash. Here is how circuit breakers work in an AI agent context. Last Tuesday at 3:47 PM, one of our flight data providers went down for 12 minutes. Our users did not notice. The AI agent continued searching for flights, presenting results from other providers, and booking trips. When the provider came back, traffic to it resumed automatically. This worked because we built [circuit breakers](/blog/circuit-breakers-external-apis) into the AI agent's [tool calling](/blog/tool-calling-at-scale-ai-travel-search) infrastructure. Without them, every flight search during those 12 minutes would have hung for 30 seconds waiting for a timeout, the user would have seen a spinning indicator, and the conversation would have felt broken. Circuit breakers are a well-established pattern in distributed systems. Applying them to AI agent tool calls introduces some interesting twists. ## The circuit breaker pattern adapted for AI agents ![Illustration for this section](https://pics.nowah.xyz/website-media/engineering-064-img-1.webp) The classic circuit breaker has three states. Closed (normal operation, requests flow through). Open (the downstream service has failed too many times, requests are immediately rejected without trying). Half-open (the circuit breaker lets a probe request through to test if the service has recovered). In a traditional web service, opening a circuit breaker means returning an error to the caller. That is fine when the caller is a UI that can show an error message. But when the caller is an AI agent, "return an error" is the wrong response. The agent needs enough context to decide what to do next. When our flight search circuit breaker opens, the agent does not receive a generic error. It receives a structured signal that includes which provider is unavailable, which providers are still available, and an estimated recovery time based on historical patterns. The agent uses this information to adjust its search strategy. If one out of three search providers is down, the agent searches the other two and presents results with a note: "I was not able to check all available carriers right now, so there might be options I missed. Want me to check again in a few minutes?" This is honest, helpful, and maintains user trust during a partial outage. If all providers are down (rare but possible), the agent communicates this clearly: "Flight search is temporarily unavailable. I can help you with hotel search, destination information, or try flights again shortly." It does not pretend nothing is wrong, and it does not go silent. ## Fallback strategies when providers are unavailable Circuit breakers are the detection mechanism. Fallback strategies are the response mechanism. We have three fallback tiers. **Tier 1: Provider substitution.** If one provider is down, route traffic to another provider that covers the same inventory. This is transparent to the user. They do not know or care which backend provider served their search results. **Tier 2: Cached results.** For popular routes and recent searches, we cache results with freshness timestamps\. If a provider is down, we can serve cached results with a "prices verified as of \[time\]" disclaimer\. Cached results are not ideal because prices change, but they are better than nothing for a quick outage\. **Tier 3: Scope narrowing.** If fallback data is limited, the agent narrows the search scope rather than returning nothing. Instead of "here are flights from all carriers," it becomes "here are the direct flights I could find" or "here are options for your specific dates." Partial results with context are more useful than no results. The choice between tiers depends on the outage characteristics. A 30-second blip triggers retries. A 5-minute outage triggers provider substitution. A 30-minute outage triggers cached results. A prolonged outage triggers scope narrowing with regular recovery probes. ## How the agent communicates degraded service ![Supporting diagram](https://pics.nowah.xyz/website-media/engineering-064-img-2.webp) This is where the AI-native approach shines compared to traditional [error handling](/blog/error-handling-conversational-systems). A traditional web app shows an error banner: "Some results may be unavailable." It is technically correct and practically useless. An AI agent can communicate degraded service naturally within the conversation. The user asked for flights, and the agent responds with results and context: "I found three good options on the carriers I could check. One search provider is having a slow day, so I might be missing some budget airlines. These are your best options right now, and I can try a broader search in about 10 minutes if you want." This communication does several things. It is honest about the limitation. It provides useful results despite the limitation. It sets expectations. And it gives the user a choice about how to proceed. Compare this to a spinner followed by an error page. The natural language communication of degraded state is possible because the AI agent understands the context. It knows what the user asked for. It knows which providers failed. It knows what results it did get. A traditional error handler knows none of this; it just knows that an HTTP request returned a 503. ## Monitoring and automatic recovery Circuit breakers need to know when to re-close. We use exponential backoff probes. When a circuit is open, we send a lightweight [health check](/blog/health-check-hierarchy) request every few seconds, with the interval increasing exponentially. When a probe succeeds, the circuit transitions to half-open and allows a real request through. If the real request succeeds, the circuit closes and normal operation resumes. We monitor circuit breaker state as a first-class metric. An open circuit breaker is an operational event that the on-call team should know about, even if the agent is handling it gracefully. The metric dashboard shows the current state of every circuit, the failure rate that triggered each open circuit, and the estimated time to recovery. We also track the impact of open circuits on user experience. When a circuit is open, we measure whether users noticed. Did conversation quality scores drop? Did booking completion rates decrease? Did average response time increase? This data tells us whether our fallback strategies are working well enough or need improvement. ## Transient failures vs. outages Not every failed request should open a circuit. Travel APIs have a baseline level of transient failures: occasional timeouts, rate limit responses, and temporary errors. If the circuit breaker trips on every transient failure, it would be open half the time, routing traffic away from a perfectly functional provider. We distinguish between transient failures and sustained outages using a sliding window approach. The circuit breaker tracks the failure rate over the last N requests. If the failure rate exceeds a threshold (say, 50% of the last 20 requests failed), the circuit opens. A single failure in an otherwise healthy stream does not trip the circuit. For transient failures, we retry with backoff. Our retry logic uses the same timeout and retry configuration as our integration tests (generous timeouts to account for the natural variability of travel APIs). Only when retries consistently fail do we escalate to the circuit breaker. This two-layer approach (retry for transient, circuit break for sustained) keeps the system responsive during the normal noise of external API calls while protecting against real outages. ## How traditional OTAs handle this (usually poorly) Most OTAs handle provider outages at the infrastructure level. Load balancers detect unhealthy backends. Error pages appear. Support tickets get filed. The user sees "we are experiencing technical difficulties" and tries again later or goes to a competitor. There is no [graceful degradation](/blog/graceful-degradation-slow-ai) at the application level. No partial results. No context-aware communication about what is and is not available. No automatic fallback to alternative providers within the same user session. The conversational interface of an AI agent makes graceful degradation possible in a way that page-based UIs cannot match. A page either renders or it does not. A conversation can adapt mid-stream. This is a genuine architectural advantage of the AI-native approach, and it translates directly to better user experience during the inevitable failures of distributed systems. Circuit breakers are not exciting technology. They are well-understood, well-documented, and have been in use for decades. But applying them to AI agent tool calls in a conversational context produces a resilience pattern that feels genuinely new, and it is one of the reasons our users do not notice when things go wrong behind the scenes. --- 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).