Skip to content
Back to Blog
August 1, 2026

Why Legacy OTAs Will Struggle to Add AI

Expedia, Booking.com, and Google built around search-results pages. Adding AI on top does not fix the architecture. Here is why AI-native wins.

Why Legacy OTAs Will Struggle to Add AI
M

Every major online travel agency announced AI features in 2024. Expedia has a chatbot. Booking.com has an AI trip planner. Google has AI-generated summaries in search results. The press releases were impressive. The actual products are not.

This is not a talent problem. These companies employ thousands of brilliant engineers. It is an architecture problem. When you have spent two decades building a product around the search-results-page paradigm, adding AI on top does not transform the product. It adds a chat window next to the search form. The search form is still doing the real work.

I want to explain why this is harder to fix than it looks, and why companies that build AI-native from scratch have a structural advantage that incumbents cannot easily replicate.

The weight of architectural decisions

Illustration for this section

Expedia's codebase was started in 1996. Booking.com followed in 1997. These platforms were designed around a specific interaction model: user fills out a search form, system returns a page of results, user browses and filters, user clicks to book. Every system, from the database schema to the API layer to the frontend components, was designed to support this flow.

The database stores inventory in structures optimized for filtered queries. "Show me hotels in Paris between these dates, sorted by price, filtered by star rating." The APIs return paginated result sets designed for page rendering. The frontend renders grids and lists with sort and filter controls. The analytics track pageviews, clicks, and form submissions.

When you try to add AI to this stack, the AI has to work within these existing structures. It can query the same database, but the database was not designed for the kinds of queries an AI agent needs. An AI agent wants to search with soft constraints ("somewhere warm in March, not too expensive, with good food") that do not map cleanly to SQL WHERE clauses. It wants to rank by multidimensional preference matching, not just price or star rating.

The APIs return paginated result sets because the UI shows results in pages. An AI agent does not want pages. It wants all the results at once so it can rank them holistically. Retrofitting the APIs to support this while maintaining backward compatibility with the existing UI is possible but expensive and error-prone.

Why chatbot-on-search misses the point

Expedia's AI approach is representative. They added a chatbot that can answer questions about destinations and help narrow down search criteria. When you are ready to actually search and book, you end up in the traditional search flow.

This is like putting a concierge desk in the lobby of a self-service laundromat. The concierge can tell you which machine to use and how much soap to add, but you still have to do the laundry yourself.

The chatbot cannot execute a booking because the booking system was not designed to be driven by AI. It was designed to be driven by sequential form submissions with human validation at each step. Retrofitting it for AI-driven execution means rewriting the booking pipeline to accept programmatic input instead of form data, adding idempotency guarantees for AI-initiated transactions, and building error recovery logic that the AI can understand and act on.

That is essentially a rewrite of the booking stack. And rewriting a booking stack that processes billions of dollars in transactions annually is not something any company does casually.

Data model constraints

Supporting diagram

The deeper problem is in the data model. Legacy OTA data models are page-oriented. They store the data needed to render specific pages: search results pages, hotel detail pages, booking confirmation pages. The relationships between data elements reflect the page navigation flow.

An AI-native data model is conversation-oriented. It stores the evolving context of a user interaction: what they asked for, what they were shown, what they reacted to, what preferences they expressed or implied, what booking state they are in. The relationships reflect the conversation flow, not the page flow.

Converting from a page-oriented to a conversation-oriented data model is not a schema migration. It is a conceptual shift that affects how data is written, read, indexed, and cached. Every query pattern changes. Every caching strategy needs revisiting. Every analytics pipeline needs rebuilding.

AI-native companies start with the conversation-oriented model. The AI agent's needs drive the data architecture from day one. There is no legacy to migrate, no backward compatibility to maintain, no existing analytics to preserve.

The AI-native advantage

When we designed our system, every decision started with "how does the AI agent need this to work?" The database schema was designed for preference-based ranking queries. The APIs return complete result sets with metadata the agent needs for decision-making. The booking pipeline accepts programmatic input and returns structured results the agent can interpret.

This is not better engineering. It is engineering for a different paradigm. Legacy OTAs engineered brilliantly for the form-and-results paradigm. We are engineering for the conversation-and-agent paradigm. Neither is wrong in the abstract. But if the future of travel booking is AI-driven, the architecture designed for that future has a permanent head start.

AI-native teams iterate in days where legacy platforms iterate in months. Not because the teams are faster, but because changing AI behavior in a system designed for AI is a prompt update. Changing AI behavior in a system designed for forms is an architecture project.

Predictions for OTA evolution

I think incumbents will follow one of three paths.

Some will acquire AI-native startups. This is the fastest way to get the right architecture, but integration with legacy systems is brutally hard. Most acquisitions in this space will struggle with the same architectural mismatch they would face building in-house.

Some will build AI-native products as separate business units, disconnected from the legacy stack. This is the right approach architecturally, but it creates internal competition. The legacy product still generates all the revenue, and organizational gravity will pull resources toward it.

Some will try to retrofit AI into their existing architecture incrementally. This is the most common approach and the least likely to produce a good product. Incremental retrofits produce incremental improvements. The gap between "search with a chatbot sidebar" and "AI agent that handles your entire trip" is not incremental.

OTAs currently hold about 40% of total travel bookings. That share was earned by being better than calling an airline directly. The question for the next five years is whether incumbents can adapt fast enough to remain better than talking to an AI agent directly.

I have my doubts.

How each incumbent falls short differently

Expedia's chatbot is the most visible effort, and it demonstrates the problem clearly. You can chat about your trip, but when you want to book, you enter the traditional funnel. The AI and the booking system are parallel paths, not integrated ones.

Booking.com has done better work on AI-powered recommendations within their hotel listings, but they remain fundamentally a hotel listing platform. Their AI improves the existing experience rather than replacing it. For flight booking, their AI capabilities are limited.

Google has the most interesting position because Google Flights was never a booking platform. It is a search product that redirects to airlines and OTAs. Google's AI travel features are summaries and suggestions, not actions. Google can tell you about flights. It cannot book one. And because Google's business model depends on sending traffic to booking sites, building a booking capability would cannibalize their own revenue.

Each of these approaches has merit within its constraints. But none of them produces the experience that an AI-native architecture can deliver: a single conversation that takes you from "I want to go somewhere" to a confirmed booking with a boarding pass in your inbox.

That experience requires architecture designed for it from the ground up. And that is why we built one.


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.

Share this article

Ready to Plan with Nowah?

Bring the idea. Nowah will help turn it into a trip.

Try Nowah