Executive summary: AI shopping agents are about to multiply flight-shopping volumes by orders of magnitude while the number of actual bookings stays flat. Airline offer engines compute prices in real time per request, so this is not a bandwidth problem. It is a unit-economics problem, and the industry's look-to-book ratio is the metric that captures it. The only economically viable answer is a caching architecture that treats the offer, a priced and expiring commitment, as the cached unit, serves cached content for exploration, and re-prices live only at the moment of commitment. This article gives IT directors the framework and the three questions to put to their architecture teams.
Distribution economics already bite, before any AI agents show up
Start with what today's costs look like, because the agentic problem is an amplification of pressures that are already reshaping the channel mix.
On the airline side, distribution through the global distribution systems (GDSs: Amadeus, Sabre, and Travelport, which together handle the overwhelming majority of travel-agency bookings) carries per-booking costs that some carriers now surcharge explicitly. The Lufthansa Group's Distribution Cost Charge, introduced as a flat €16 in September 2015, differentiates by GDS as of January 2026: €18.00 per ticket booked via Amadeus, €22.50 via Sabre, €23.00 via Travelport, with a further Amadeus increase already announced for May 2026. The same group has pulled its cheapest "Light" fares on German domestic routes out of the legacy EDIFACT GDS channel entirely and offers its continuous-pricing fares only through NDC channels. Meanwhile NDC, the XML standard airlines use to distribute rich offers directly (the full standards map is here), has grown from roughly 11% of indirect airline sales in 2023 to roughly 24% by early 2026, per figures reported from IATA's NDC tracking.
On the seller side, the cost that bites is look-to-book: shopping requests per actual booking. Airlines' own websites run at roughly 100 to 300 searches per booking. Online travel agencies and metasearch run at 1,000-to-1 at best, and commonly beyond 10,000-to-1, because a single user search fans out into hundreds of backend availability-and-pricing queries across dates, airlines, and cabins. Aggregators meter and rate-limit accordingly, and agencies bear the cost. That ratio has been climbing for two decades: industry analyses put it at a few hundred searches per ticket in the mid-2000s and in the five-figure range today.
The multiplier: from look-to-book to compute-to-order
Now add autonomous shopping agents. An AI agent asked to "find me the best way to spend a week in Lisbon in October under €400" does not search once. It sweeps date ranges, fares across alliances, alternative airports, and cabin and ancillary combinations, then re-checks them as it reasons. GDS operators have publicly projected search volumes rising toward 200,000 searches per booked ticket as agentic traffic scales.
At that point look-to-book stops being a marketing metric and becomes what it always secretly was: compute-to-order, the total computation the industry burns per confirmed booking. Every one of those searches is not a static page load. An airline offer engine runs real-time dynamic pricing per request: availability, fare rules, ancillary pricing, and increasingly continuous-pricing models, computed on demand. The offer engines cannot absorb a 10-to-100× multiplication of that load, and the agencies and aggregators in the middle cannot afford to pay for it per request.
The bookings, meanwhile, do not multiply. The same passenger flies to Lisbon once. Revenue per booking is flat while cost per booking explodes. That is the equation an IT director has to fix, and it cannot be fixed with rate limits alone, because throttling agents means losing exactly the demand the airline wants to win. Agents will buy from whoever can afford to answer them.
Caching is not an optimization here: it is the economic mechanism
The standard toolbox answer is "cache it." In agentic distribution, caching is not a performance tweak; it is the mechanism that makes the whole model viable. But airline offers resist naive caching for one fundamental reason: an offer is a priced, expiring commitment, not a fact. Aggregator APIs typically give an offer around 30 minutes of validity (it varies by airline) before the offer ID is dead and the price is no longer honored.
So the design question is sharp: how long can a cached offer be served before staleness turns into a mispriced booking, either by quoting a price the airline will no longer honor or by hiding a better one? Cache too little and the offer engines melt; cache too much and your conversion funnel fills with quotes that die at checkout.
Two design principles resolve most of it.
Principle 1: cache the offers, not the requests
Request-level caching keys on the query: dates × routes × passengers × cabin × channel context. That cardinality explodes combinatorially, and agentic traffic makes it worse, because every agent phrases its sweep differently, so hit rates collapse exactly when you need them most.
Content-level caching stores the normalized offer itself (the airline's priced product, with its own identity, terms, and expiry) once, then serves it to many differently-shaped queries. The offer becomes the atom of your cache, whatever the consumption channel: an NDC API response, an MCP tool call from an AI agent, a metasearch feed. Just as importantly, freshness logic hangs naturally off the cached object, because the offer's owner, the airline, is the source of truth for how long its price lives. This presumes you have a canonical model of what "an offer" is across your sources, which is the harmonization problem we map in the standards article.
Principle 2: split the funnel into cached exploration and live commitment
Not every shopping call deserves the same freshness. The workable pattern:
| Funnel stage | Traffic share | Served from | Freshness contract |
|---|---|---|---|
| Broad exploration ("where can I go for €400?") | Overwhelming majority | Cache, aggregated & indicative | Explicitly indicative pricing |
| Narrowing (specific dates, fare families, ancillaries) | Small | Cache with short TTLs, selective refresh | Near-live, still not guaranteed |
| Commitment (create the order, pay) | One booking's worth | Always live re-price | Guaranteed price, never cached |
The commit step is always live. Everything upstream of it is a freshness-budget negotiation between compute cost and quote accuracy, and the budget should differ by product. A long-haul business fare with volatile continuous pricing deserves a tighter staleness budget than a fixed-price ancillary bag.
Reality check: can an AI actually book you a flight today?
It is worth walking the end-to-end flow as it stands, because its failure points confirm the architecture above.
Discovery and connection: a general-purpose assistant cannot reach arbitrary flight APIs on the open internet; a connector (an MCP server, typically wrapping an aggregator API) must be installed and authenticated. Shopping: genuinely works. With a connector live, an agent can search and price real offers with real offer IDs, which is the read-heavy, cacheable tier. Buying is where it stops, for three reasons that are not bugs:
- Payment is a separate layer. A wave of agentic-commerce protocols emerged precisely for this: Google's AP2 (Agent Payments Protocol, September 2025), Stripe and OpenAI's Agentic Commerce Protocol (September 2025), and the Google-and-Shopify-led Universal Commerce Protocol (January 2026). All exist to create a verifiable mandate proving a human authorized this specific charge, and they still need funded credentials and merchant integration behind them.
- Commitment needs a gate. A non-refundable ticket is exactly the high-consequence, irreversible action that governed-agent design keeps behind human confirmation. The responsible pattern is: the agent assembles, the human confirms and pays. (We have written before about why agents need governed definitions, not just API access, which is the same logic one step earlier in the funnel.)
- Offers expire. By the time the human approves, the offer ID may be dead, so the commit step must re-price live regardless. The funnel split is not just economics; it is forced by offer perishability.
The clunkiness is the market gap. The pieces all exist: protocols, connectors, standards. What does not yet exist is a clean, governed, airline-neutral version of this flow, and the caching-and-freshness layer is the unclaimed middle of it.
The strategic caveat: today's NDC price gap is a migration subsidy
One analytical point most coverage misses, worth internalizing before you build a business case on channel arbitrage. The NDC fare is not cheaper because NDC is technically more efficient. It is cheaper because the airline chose to make the other channel more expensive: the surcharge is a fare component the carrier adds and can remove, and NDC-only private fares are contractual and can be re-pointed. The current price gap is best understood as a migration subsidy, with airlines funding the movement of volume off a channel that costs them money. Channel-shift incentives have a history of being withdrawn once the shift completes.
So a distribution strategy whose margin depends on the NDC/GDS differential is renting someone else's strategic decision. What survives the migration is what is true either way: airlines want lower total distribution cost and control over who sees which offer, and everyone needs instrumentation covering channel-mix economics, look-to-book monitoring, and conversion by offer source, on top of the classic revenue and demand analytics stack we cover in our deep dive into travel data analytics. Build the instrumentation; treat the arbitrage as temporary.
The regulatory closer: nobody has decided how agents fit the rules
European law still governs how computerized reservation systems display airline content under a Code of Conduct designed in 1989 (Regulation 2299/89) and last replaced in 2009 (Regulation 80/2009), before NDC existed and long before shopping agents. The European Commission's own 2020 evaluation questioned whether the regulation is still fit for purpose, and the revision has been pending ever since, with stakeholder consultations still active. How an autonomous shopping agent maps onto a legal framework built around neutral display in a travel agent's terminal is an open question.
Which is an opportunity hiding in plain sight: when the revision finally moves, the parties holding real data on how agent traffic actually behaves (volumes, sweep patterns, conversion, cache-hit behavior) will be the ones informing the answer. Instrumenting your agentic traffic now is cheap; being the organization with the numbers later is not.
Takeaway: three questions for your architecture team
- What is our cached unit? If the answer involves request URLs or query parameters rather than normalized offers, cardinality will eat the cache exactly when agent traffic arrives.
- Where is our live-commit boundary? There must be a precise line where cached, indicative content stops and live, guaranteed pricing begins, and nothing on the commitment side of it may ever come from cache.
- What is our staleness budget, per product? "As fresh as possible" is not a policy. A number of minutes, per product type, with an owner and a mispricing-cost model behind it, is.
If those three questions do not have crisp answers today, that is the work, and it is definition-phase work, cheaper now than after the traffic arrives. Our travel and tourism data practice designs exactly this layer: canonical offer models, governed MCP interfaces for agents, and caching architectures with explicit freshness contracts, from blueprint to build.
