In a new post, Amadeus — the system of record behind roughly 3 billion flight searches a day, 400-plus airlines and 2 million hotel properties — laid out its read on agentic AI in travel. The headline from CTO Sylvain Roy: protocols, not chatbots, are what make agentic travel work, and the protocols that exist today are not ready. MCP, he argues, is "only a first step"; the Universal Commerce Protocol "could open large new distribution and conversion opportunities" but remains "largely retail-native and is still in the process of being adapted to handle the full complexity of travel."

He is right — and we can put data behind it. Before Amadeus weighed in, we built a mock travel server with expiring offers and pointed five frontier models at it. Not one checked an offer's time-to-live before booking. Only one survived a three-second expiry window. None flagged a price change unless explicitly asked. Travel's defining feature — perishable inventory priced in real time — is precisely where today's agents fall over.

So here is the state of play from the monitoring seat: travel's supply side just showed up to UCP, but the demand side cannot reliably transact on it yet, and the protocol needs travel-specific work before it can. This is the read on agentic commerce's hardest vertical. Our bias throughout: we saw it in the data first.

What just happened: travel's supply side standardized on UCP

Two signals landed in quick succession. At Google Marketing Live 2026, Google extended UCP into hotels and local food delivery, naming a launch roster that reads like the entire travel-distribution stack: Accor, Amadeus, Booking.com, Choice Hotels, Expedia Group, Hilton, IHG, Marriott, Trip.com and Wyndham. Booking a hotel "right from AI Mode in Search" is the demo. (We covered the full package — Universal Cart, multi-item checkout, BNPL and the rest — separately.)

Then Amadeus published its position. Notably, it is not an adoption announcement. Roy frames Amadeus as the "embedded and neutral execution layer for travel" and says it is ready to collaborate on travel-ready agentic protocols — but commits to no UCP timeline. The subtext is the honest one: the supply side is interested, the rails are forming, and nobody is claiming travel is solved.

Why travel is agentic commerce's hardest vertical

Retail is, relatively, simple: a product has a fixed SKU, a stable price and a quantity. Travel has none of those guarantees. Amadeus calls out five gaps, and each is a place a retail-native protocol strains.

• Dynamic offers, not fixed SKUs. A flight or room is not a catalog entry — it is a dynamically generated Offer ID built from origin, destination, dates, fare family, ancillaries and disruption rules. There is no stable identifier for an agent to drop in a cart and trust.
• Perishable inventory, real-time pricing. Availability and price change by the second, with no true SKU equivalent. An offer an agent saw thirty seconds ago may already be gone or repriced.
• Complex servicing. Changes, cancellations and disruption handling demand full request context, and the stakes of getting it wrong are far higher than a returned T-shirt.
• Identity, settlement and regulation. Multi-party fulfillment, traveler identity verification and compliance obligations ride on every booking.
• Data quality and control. Personalization needs traveler context shared across parties while suppliers keep visibility and control of it.

UCP models the retail case well — fixed catalog, cart, checkout, payment handlers. (New to how UCP sits next to MCP and AP2? We break the stack down here.) Travel needs primitives the retail spec does not have yet.

The data: agents are blind to time

The perishable-inventory and real-time-pricing problems are not theoretical. They are measurable, and we measured them.

We built a mock travel server that issued offers with explicit expiry windows and ran five frontier models against it across 21 sessions. The results were stark: not one model checked an offer's TTL before attempting to book; only one survived a three-second expiry window; none surfaced a price change unless we asked. The agents treated time-sensitive travel inventory exactly like a static retail SKU — and that is the failure mode that turns a "confirmed" booking into a charge for an offer that no longer exists.

The same blindness shows up on the retail side. Across 33 sessions on a live store, only two of five models caught a stale price even when handed yesterday's number — and the deeper problem was structural: the merchant data layer did not expose temporal metadata at all. A model cannot reason about expiry if nothing in the stack tells it the offer expires.

That is Amadeus's "perishable inventory" and "live search at scale" challenges, observed in production. The protocol that wins travel has to carry time — TTLs, price-as-of timestamps, re-validation before commit — as a first-class signal, and agents have to be built to respect it. Neither is true today.

Retail-native, not travel-ready: what UCP still needs

The encouraging part is that UCP is extensible by design. The spec grows through capability extensions — the Technical Council has been adding cart, order, loyalty and identity primitives since launch. Travel is simply the next, harder extension surface. From the gaps above, the shortlist:

• A dynamic-offer primitive — an offer object carrying a TTL and a price-validity window, replacing the assumption of a stable SKU.
• Re-validation in the checkout flow — an agent must confirm the offer is still valid and still the quoted price before it commits.
• Servicing capabilities for change, cancel and disruption, with enough context to handle them safely.
• Identity and settlement extensions for multi-party, regulated fulfillment.

Concretely, the dynamic-offer primitive looks something like this — a travel offer that carries its own clock:

{
  "offer_id": "LHR-NRT-20260612-A1F2",
  "price": { "amount": 842.00, "currency": "USD" },
  "ttl_seconds": 3,
  "price_valid_until": "2026-06-12T19:30:03Z",
  "revalidate_before_checkout": true
}

A retail SKU carries none of those fields, and that is the whole problem: nothing tells an agent the offer it is holding has already expired. None of these are exotic. They are the difference between a protocol that can sell a tote bag and one that can sell a Tokyo itinerary. And the backers are aligned to build them: the companies behind UCP — Google, Shopify, Amazon, Microsoft, Meta, Stripe and Salesforce, the group whose Technical Council recently expanded — now have the travel-distribution establishment at the table.

What it means

For travel suppliers (airlines, hotels, OTAs, GDSs): being named at a keynote is not the same as being agent-ready. The supply side is forming the rails, but the offer, pricing and servicing semantics that make travel safe for agents are not in the published spec yet. The window to shape those primitives — rather than inherit retail's — is open now, and Amadeus is signalling it wants in.

For demand-side players (agents, assistants, AI shopping surfaces): do not ship autonomous travel booking on retail assumptions. Our data says agents will book expired offers and miss price changes unless both the protocol and the agent treat time as first-class. Until travel primitives land, keep a human on the commit step.

For the ecosystem (us): we do not yet monitor live travel UCP endpoints — there are not any in production to monitor. What we can measure today is the agent side, and we have shown the gap is real. As travel manifests go live, the same validation, scoring and monitoring we run across more than 6,500 retail merchants — tracked monthly in the State of Agentic Commerce census — will extend to them. The neutral measurement layer travel is asking for is the one we already operate.

What we're watching

Whether the Technical Council opens a travel working group or a dynamic-offer extension; which of the GML travel partners ships a live, parseable endpoint first; whether Amadeus moves from "ready to collaborate" to a concrete commitment; and — the one we will keep testing — whether the next generation of models stops being blind to time. We will report what the data shows, not what the slides promise.

Sources

• Amadeus — Agentic AI in travel: why MCP and UCP standards matter (Sylvain Roy, CTO)
• Google blog — Shopping updates from Marketing Live
• Our testing — We Tested 5 AI Models on Expiring Travel Inventory

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate and grade every public UCP manifest we can find, run the merchant directory, the UCP Score and live adoption stats, and test how real AI agents behave against real stores. We track spec and ecosystem events — retail today, travel as it arrives — as they ship.

• Check your store: ucpchecker.com/check
• Grade it (UCP Score): ucpchecker.com/score
• See capability coverage: ucpchecker.com/capabilities
• Browse the directory: ucpchecker.com/directory
• Get notified when an endpoint changes: ucpchecker.com/alerts

Travel is the hardest test agentic commerce has set itself. We will be measuring it.

Retail merchant figures are live from the UCP Checker index and update every 24 hours; agent-testing methodology is on our methodology page.