The vendor layer keeps winning in hotel agentic commerce

Google extended its Universal Commerce Protocol to hotels last week. In a blog post at I/O on 19 May 2026, and in more detail at Google Marketing Live the next day, Google named hotel booking as the next UCP vertical: an AI agent completes a hotel booking inside Google's own surfaces, with Booking.com, Expedia, Marriott, IHG, Choice and Wyndham named as partners and a developer waitlist now open. The hotel stays Merchant of Record, keeping its terms, its guest data and its payment relationship.

It is genuinely capable engineering, and it is also the latest in a fast-moving run of agentic commerce standards pointed at hotel transactions. It runs into the same wall as the ones before it.

The pattern, not the announcement

Walk back through the timeline. Book on Google tried to own the hotel transaction and stalled. In September 2025, OpenAI's agentic commerce protocol with Shopify and Stripe brought in-chat checkout to retail and pointed straight at travel. In January 2026, Google launched UCP as the broader standard, and in February its WebMCP gave agents a structured way to call a website's functions directly. In April, OpenAI quietly retreated from in-chat bookings. Now UCP reaches lodging.

Different names, two large platforms, one constant underneath. Each standard assumes the hotel can do three things: expose live rates and availability through an API, accept a tokenised payment its payment service provider can process, and reconcile a booking that originated somewhere other than its own funnel. For the large chains and OTAs on Google's list, all three are solved. For most independent and small-group hotels, none of them sit with the hotel at all. They sit with the booking engine and the channel manager, behind a white-label widget the hotel embeds but does not control.

That is why the partner list reads the way it does. Every name on it runs an integrated stack or has the budget to build one. The independents are absent, not because Google excluded them, but because the vendor layer between them and Google has not moved. The same chokepoint blocked Book on Google and sat in front of WebMCP. UCP swaps the protocol and leaves the bottleneck exactly where it was.

What Walmart proved about chat checkout

There is a second reason these standards keep stalling, and it has nothing to do with hotels. The chatbot is a poor place to complete a purchase.

Walmart ran the clearest test anyone has published. From November 2025 it offered roughly 200,000 products through OpenAI's Instant Checkout inside ChatGPT. In March 2026, Daniel Danker, Walmart's EVP of AI acceleration, product and design, told WIRED that conversion inside the chat ran three times lower than when users clicked out to Walmart's own website. Retail, with simpler pricing and inventory than any hotel booking, could not close at a normal rate inside a chat window.

What Walmart did next is the interesting part. It did not abandon AI commerce. It moved the transaction into a merchant-owned app, Sparky, that runs inside ChatGPT but checks out in Walmart's own environment, with account linking and loyalty attached. That version converts at around 70% of Walmart.com's rate, more than double what Instant Checkout managed. Letting the merchant own the transaction is what fixed it, not stripping the AI out.

That is the whole argument in one data point. Chat is good for discovery and for narrowing options. The purchase belongs somewhere the brand controls, where the reviews, the imagery and the small reassurances that quiet a buyer's last-second doubt are all present. Strip those out and conversion drops, and in hospitality the buyer who hesitates defaults to the OTA they already trust.

Why owning the data layer is the actual answer

If the protocol is not the problem and the chat interface is not the answer, then what decides whether a hotel benefits from any of this is whether it controls its own data and checkout.

A hotel that owns a first-party data layer, where its booking engine, PMS, ESP and consent records flow into a warehouse it controls, can connect that layer to UCP today, to whatever Google ships next, and to the OTA integrations, without rebuilding each time. The agent works from the hotel's ground truth instead of scraped interface state. When a better protocol arrives, the hotel connects it rather than re-platforming around it.

A hotel that rents its stack does the opposite. It waits for the booking engine vendor to support UCP, then waits again for the next standard, and hands the booking to an OTA every time it is not ready. The gap compounds quietly, and by the time the hotel tries to change something the cost shows up as revenue left on the table and time spent firefighting.

The order matters. Assess the existing stack, unify the fragmented data into a hotel-owned warehouse, then put intelligence and orchestration on top. AI comes last on purpose, because an agent layered onto a fragmented, vendor-controlled stack is just more capable automation running on the same broken foundation. The data layer is what makes everything above it portable, and portability is the only durable hedge when the standards change every few months. That sequence is what we build at Elegia.

What to do now

Ask your booking engine and channel manager whether UCP for Lodging is on their roadmap, and get a date rather than a reassurance. Ask your payment service provider whether it can process Google's tokens; most large PSPs already can. Check that your rate and availability data is clean and exposed through an API, because every agentic standard from here forward assumes it. And treat the answer your vendor gives as information about whether they are the right partner for the next two years, not just the next release.

The protocols will keep changing names. The hotels that own their data are the ones that get to stop tracking which protocol won this quarter, because they can connect to whichever one their guests are using.