---
title: How We Built an AI Agent That Books Real Flights
description: "From chatbot to booking agent -- how we engineered an AI system that searches, ranks, and executes real flight purchases end-to-end in conversation."
canonical: https://nowah.xyz/blog/building-ai-agent-that-books-flights
lastModified: "2026-08-07T03:46:24.452Z"
---

# How We Built an AI Agent That Books Real Flights

From chatbot to booking agent -- how we engineered an AI system that searches, ranks, and executes real flight purchases end-to-end in conversation.

Most AI travel "agents" are chatbots wearing a trench coat. They can tell you that Tokyo is lovely in spring, recommend neighborhoods to stay in, maybe even generate a day-by-day itinerary. But ask them to actually book a flight and they'll hand you a link to Expedia.

We wanted something different. We wanted an AI that could take "Find me a direct flight to Tokyo in April, window seat, under $900" and come back with three real options at real prices that you could book right there in the conversation. No redirects. No form-filling. No tab-switching.

That turned out to be a dramatically harder engineering problem than building a chatbot. Here's how we solved it.

## The gap between talking about travel and doing something about it

![Illustration for this section](https://pics.nowah.xyz/website-media/engineering-001-img-1.webp)

There's a meaningful technical distinction between an AI that generates text about flights and an AI that searches for, ranks, and books actual flights. The first is a language problem. The second is a systems engineering problem.

A text-generating chatbot takes your question, runs it through a language model, and produces a plausible-sounding response. It might be accurate. It might be hallucinated. There's no ground truth because the model isn't connected to any real inventory system. Ask it "What's the cheapest flight to Tokyo in April?" and it'll generate a number. That number might have been true six months ago during training. It might be completely made up. You'd never know without checking.

A booking agent, by contrast, needs to decompose your natural language request into structured parameters, call live flight APIs with those parameters, process the raw results through a ranking system, present curated options with real prices, handle your follow-up questions and refinements, then execute a real financial transaction when you're ready.

Every step in that chain can fail in interesting ways. The language model might misinterpret "sometime in April" as April 1st instead of a flexible date range. The flight API might be slow or return stale prices. The ranking system might not account for a preference the user hasn't explicitly stated. The payment might succeed but the booking might fail downstream. Two steps might race against each other if the user sends a follow-up message while the agent is still processing.

The average traveler visits 38 or more websites before booking a single trip. That number exists because no single tool can handle the full journey from vague intent to confirmed booking. We built Nowah to handle all of this in a single conversation thread, and the core of that capability is the tool-calling architecture.

## Giving the AI hands, not just a mouth

The fundamental architecture decision was to build the AI agent as an orchestration system with a comprehensive suite of tools it can call. When you send a message, the agent doesn't just generate text. It reasons about what you're asking, decides which tools to invoke, calls them in the right sequence, processes the results, and synthesizes everything into a coherent response.

Think of it like the difference between a librarian who can only describe books to you versus one who can actually walk to the shelves, pull specific volumes, check them out, and hand them to you. Both are useful, but only one gets the job done.

Our agent instructions covers the full breadth of travel operations. There are tools for searching flights across carriers. Tools for searching hotels by location and preference. Tools for checking real-time availability and verifying prices. Tools for managing traveler profiles and passport information. Tools for executing bookings and processing payments. Tools for generating itineraries, checking [visa requirements](/blog/ai-agents-visa-requirements-documents), converting currencies, and looking up airport information.

The agent decides which tools to call based on the conversation context. "Find me flights to Barcelona" triggers flight search tools. "That second option looks good, book it" triggers the booking and payment tools. "Actually, can you find a hotel near the Sagrada Familia too?" triggers hotel search tools with location context carried over from the flight search. "Do I need a visa?" triggers the visa requirement tool with the destination already known from context.

This is where the engineering gets interesting. The agent needs to select the right tools from a large set, construct the right parameters based on ambiguous human language, handle the results (which might be errors or empty sets), and weave everything into a response that feels like a natural conversation rather than a system readout.

Tool selection is the most underappreciated engineering challenge. With a large tool suite, the model needs clear signals about which tool to use for which situation. We invest heavily in tool naming, description engineering, and contextual availability. Each tool has a precise description of when to use it and what it returns. We dynamically filter the available tools based on conversation state so the model doesn't have to reason about irrelevant options. And we monitor tool selection patterns in production to catch and fix misrouting.

The result is an agent that can handle complex, multi-step interactions in a single thread. "Find me flights to Barcelona next week, check if I need a visa, and find a boutique hotel near Las Ramblas" is three tool calls that the agent can dispatch in parallel, synthesizing the results into one coherent response.

## Why fewer results demand better engineering

![Supporting diagram](https://pics.nowah.xyz/website-media/engineering-001-img-2.webp)

Here's an opinion we hold strongly: showing users 500 flight results is a failure of product design, not a feature. The paradox of choice is real. Research shows that when people face overwhelming options, they make worse decisions, feel less satisfied with their choices, and often abandon the process entirely. About 60% of users abandon complex booking flows on [traditional OTAs](/blog/ai-travel-booking-vs-traditional-otas), and [decision fatigue](/blog/decision-fatigue-travel-science) from too many options is a significant contributor.

We present exactly three options. That's it.

This sounds like a simplification but it's actually the opposite. Anyone can return 500 results. That's just piping an API response to a screen. Picking the right three requires understanding the user deeply enough to filter out 497 results with confidence.

Our ranking pipeline scores every flight result across multiple dimensions simultaneously. Price is obvious, but it's one factor among many. We also score convenience (layover duration, departure time, connection airports), comfort (aircraft type, seat configuration), reliability (airline on-[time performance](/blog/airline-on-time-performance-who-delivers) for that route), and preference match (does this align with what we know about this traveler?).

The weights across these dimensions are not static. A budget traveler gets heavier price weighting. Someone who mentioned they hate layovers gets heavier convenience weighting. A user who always books the same airline gets that factored into preference match. The ranking adapts to the person, not the other way around.

We also enforce a diversity constraint in the final selection. The three options should be genuinely different. A budget pick (best price, acceptable on other dimensions), a comfort pick ([best experience](/blog/best-experience-booking-ai-curates), higher price), and a balanced pick (strong across all dimensions). Not three slightly different versions of the same flight. This gives the user real choice without the paralysis of scrolling through hundreds of near-identical options.

The diversity algorithm works by selecting the top-ranked option first, then penalizing remaining options that are too similar to the selected one (same airline, similar time, close in price), selecting the next best, and repeating. The penalty function is tuned to produce genuinely different options without straying so far from quality that any option feels like a bad recommendation.

85% of travelers say personalization influences their booking decisions. We take that seriously in how we rank. AI-powered travel recommendations increase conversion by 20 to 35 percent over unpersonalized results, and most of that gain comes from showing fewer, better options rather than more options.

## Financial-grade reliability when AI handles money

The moment an AI agent can charge your credit card, the engineering bar changes entirely. A chatbot that occasionally hallucinates a wrong answer is annoying. A booking agent that double-charges you or books the wrong flight is a lawsuit.

We built a multi-layer idempotency checks specifically for this. At the application layer, every booking request gets a unique idempotency key. If the same request arrives twice (because the user double-tapped, or the network retried, or the AI agent re-invoked the tool), the second request returns the result of the first without executing again. The key is a hash of the user, the selected option, and a session nonce. Same user, same flight, same session: same key, same result.

At the payment processor layer, we use the processor's own deduplication to catch any requests that somehow get past the application layer. We pass through our application-level key so the payment processor treats duplicate requests as idempotent. And at the travel provider layer, we check for existing bookings that match the same passengers, flight, and dates before creating new ones.

These three layers work in concert. If any single layer fails its idempotency check, the others catch it. The probability of all three failing simultaneously is negligible. We've never double-booked or double-charged a user.

The other piece is atomicity. A booking involves at least two external systems: the payment processor and the travel provider. We authorize payment first, then create the booking, then capture the payment. If the booking fails after authorization, we void the hold. If payment capture fails after the booking is created, we cancel the booking. Every state transition has an explicit rollback path.

This is a saga pattern adapted for AI-initiated transactions. The key difference from traditional e-commerce is that the AI agent, not a user clicking through checkout pages, is driving the transaction. That means retry behavior, timeout handling, and failure communication all need to work in a conversational context. When a booking fails, the agent doesn't show an error modal. It says "The booking couldn't be completed. Your card hasn't been charged. Want me to try again or look at other options?"

Every AI-initiated transaction gets a full audit trail. We log the conversation context that led to the booking decision, the exact parameters the agent used, the responses from external systems, and the final state. If a customer ever questions a charge, we can reconstruct exactly what happened and why. Average customer service calls in travel cost $6 to $12 each. Our audit trail typically resolves questions without a human needing to investigate at all.

Booking abandonment rates on traditional OTAs hit 80 to 90 percent. Part of that is distrust in the payment process. Our approach, explicit confirmation, transparent pricing, automatic rollback on failure, is designed to earn trust through engineering.

## Memory as a compounding advantage

The first time you use Nowah, you'll have a good experience. The tenth time, you'll have a dramatically better one. That's because of our [agentic memory](/blog/agentic-memory-smarter-over-time) system.

Traditional travel search is stateless. Every time you visit an OTA, it knows nothing about you. You've searched for window seats fifty times, but the search form still defaults to no preference. You always fly out of JFK, but you still have to type it every time. You booked five trips last year, and the platform couldn't tell you a single thing about your travel patterns.

Our memory system tracks three types of information. Explicit preferences are things you've directly told us: "I always want aisle seats" or "I'm loyal to Delta." These are stored with high confidence because the user stated them clearly. Learned patterns are things the agent observes over time: you tend to book morning flights, you prefer hotels under $200 per night, you like direct flights even when they cost more. These are probabilistic, stored with lower confidence that increases when the pattern is reinforced. Contextual history is the state of ongoing conversations and recent searches: what you searched for yesterday, the hotel you liked but didn't book, the dates you're considering.

When you say "Find me flights to London next month," the agent already knows your home airport, your airline preference, your seat preference, and your typical budget range. It can construct a much more targeted search than any OTA that treats you as a stranger every time. Instead of searching all airlines from all local airports in all fare classes, it searches your preferred airline from your home airport in your typical price range, and presents options that match your actual travel style.

The memory system also enables proactive behavior. "You usually fly Delta, but United has a much better fare on this route. Want me to show the United options?" That's the agent reasoning about a tension between stored preference and current search results, and surfacing it. A stateless system can't do this because it doesn't know what "usual" means for this user.

This is a genuine competitive moat. An incumbent OTA could bolt on a chatbot tomorrow, but they can't retroactively build months of personalized memory for their users. The data doesn't exist in their systems because form-based interactions don't generate the preference signals that conversations do. Every conversation a user has with Nowah makes the next one better. That compounds over time in a way that's very hard to replicate.

## What the incumbents get wrong

I want to be specific about this because it matters for understanding the opportunity.

When major travel companies added AI features starting in 2023, they almost universally did the same thing: they took their existing product (search form, results list, booking funnel) and bolted a chatbot onto the side of it. The chatbot could answer questions and maybe suggest some options, but when you wanted to actually book, you got redirected back to the same old interface.

This approach has a structural problem. The chatbot is a feature within the existing product. It can only do what the existing system supports, and the interaction model still revolves around forms and lists and filters. The AI is constrained by an architecture that was designed before AI existed. The chatbot can't book because the booking system expects form data from a checkout page, not a conversational confirmation. The chatbot can't remember preferences because the user profile system stores form-submitted data, not conversationally-derived insights.

We built the other way around. The conversation IS the product. There's no search form behind the chat. There's no results page to fall back to. The AI agent is in the critical path of every user action. That forces us to make the agent reliable enough to handle real transactions, which is hard, but it also means the agent can do things that a bolt-on chatbot never could.

For example, our agent can handle a request like "I need to fly from New York to London on the 5th, then London to Paris on the 8th, and my wife is joining me in Paris from Chicago." Try doing that on any traditional OTA. It requires multiple separate searches, manual coordination of dates and airports, and constant mental bookkeeping to make sure everything lines up. In conversation, it's one sentence. The agent parses the complexity, makes the right tool calls, coordinates the results, and presents a unified plan.

Conversational AI reduces average booking time by three to five times compared to form-based search. Not because conversation is inherently faster, but because the AI does the coordination work that users currently do manually across multiple search tabs. Complex multi-city trips that take an hour on traditional OTAs take minutes in conversation.

There's also a monetization alignment that matters. Traditional OTAs make money from advertising and sponsored placements within search results. Their incentive is to show you many options with paid placements mixed in. Our incentive is to show you the best options and get you to a booking quickly. When the product's revenue comes from successful bookings rather than ad impressions, the AI's ranking can be purely optimized for user benefit.

## Where this goes next

The current version of Nowah handles the full booking flow: search, rank, present options, book, confirm. That's already a significant step beyond what most travel AI can do today. But we see three major capability expansions on the horizon.

The first is proactive planning. Right now, the agent responds to your requests. In the near future, it will anticipate them. You booked a flight to Rome. The agent knows you like walkable neighborhoods and boutique hotels. Before you ask, it suggests three hotel options in Trastevere. It knows your partner is vegetarian and flags restaurants near your hotel with good vegetarian menus. It notices that a museum exhibit you'd probably enjoy is only running during your dates and mentions it. That's the memory system paying dividends, not just for search targeting but for proactive trip enrichment.

The second is multi-agent coordination. Today, our AI agent talks to flight and hotel APIs. Tomorrow, airlines and hotel chains will have their own AI agents. Your agent negotiates with the airline's agent for a better fare or an upgrade. Two AIs working the problem from both sides. The airline's agent knows the load factor for that flight and has flexibility to offer a deal. Your agent knows your price sensitivity and your alternatives. The negotiation produces a personalized offer that wouldn't exist in a static pricing system.

The third is real-time disruption management. Your flight gets delayed and you'll miss your connection. Before you even realize there's a problem, your agent has already searched alternative routes, found a rebooking option, and presents it to you: "Your connection through Dallas won't work anymore. I found a direct flight that gets you there two hours later. Want me to switch?" That level of autonomous action requires deep trust between user and agent, and we're building toward earning that trust incrementally.

We're also watching model improvements closely. Longer context windows mean the agent can handle more complex, multi-week itineraries in a single conversation. Better reasoning means more reliable tool selection and ranking. Faster inference means lower latency. LLM inference costs have dropped roughly ten times in the past eighteen months. Every improvement to the underlying models makes our orchestration layer more capable without us changing a line of code.

The travel industry is projected to be a top-three sector for AI agent adoption by 2027. We think that's conservative. The problem is well-defined, the data infrastructure exists, and the user pain is acute. The average traveler visits 38 or more websites before booking a trip. That number should be zero, because you should be able to open one app, describe what you want, and let an AI agent handle the rest.

We're not there yet for every trip type, but we're closer than anyone else. And every booking we process makes the system smarter for the next one. The compounding advantage of agentic memory, combined with the architectural advantage of being AI-native rather than AI-augmented, creates a gap that widens over time. That's the moat. Not a technological trick, but a product architecture that gets better with every interaction.

---

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).