From Discovery to Booking: UCP Lodging and the Agentic Web for Travel

A few weeks ago in Zurich, at the W3C × GS1 workshop on e-commerce and AI agents, I had the chance to meet Amit Handa, one of the creators of the Universal Commerce Protocol (UCP), and see him present where the protocol is going next.

What caught my attention was the direction of travel. UCP is moving beyond its initial shopping use case into vertical commerce: shopping has carts and checkout, food has menus and orders, and now lodging has bookings. Amit’s presentation makes this progression very clear, and for anyone working in travel it is worth looking at the original slides from the workshop.

For travel marketers, this matters because AI is moving from recommending a property to participating in the transaction. An agent can increasingly understand a request, identify the right property, check availability, retrieve a rate, explain the conditions and move the traveler toward booking. The question is no longer only whether your hotel, apartment or destination appears in AI search. It is whether an agent can actually work with it.

This connects directly with something we discussed after my own presentation in Zurich in From Markup to Memory: Building an Open Web for AI Agents. The main argument there was that structured data for agents cannot remain a block of markup attached to a page. Agents need navigable memory: stable entities, relationships, provenance and declared capabilities. From Markup to Memory: Building an Open Web for AI Agents

UCP adds an important piece to that picture: once the agent understands the entities, how does it act on them?

From memory to booking

Consider a fairly normal travel request: Find me a family apartment in Lungau for four people, close to hiking, and check whether it is available next weekend.

There is much more happening here than keyword matching. The agent needs to understand that Lungau is a region, Mariapfarr is a place within it, a property is different from the apartments it contains, and each accommodation has relationships with amenities, trails, ski areas, offers and rate plans. It then needs current information about availability, price and booking conditions.

That is why I see the agentic travel stack as a progression from content to entities, from entities to live commercial data, and from there to actions. The Knowledge Graph acts as memory; booking systems provide live state; UCP gives agents a shared protocol for commerce.

This is also the natural continuation of what we have been building with Alpina.travel. In From Travel Website to Agentic Storefront, we described how Alpina moved from a conventional destination website toward a KG-first architecture in which destinations, places, attractions and accommodation are entities that both humans and agents can navigate. From Travel Website to Agentic Storefront

Now we are taking the next step: connecting that memory to booking.

Testing UCP Lodging on Alpina.travel

Alpina is useful as a laboratory because the entity layer is already there. An agent does not have to treat “Samspitze 4” as an arbitrary string found on a webpage. It can understand it as a specific accommodation in Mariapfarr, connected to a property, a destination and the surrounding network of places and activities.

When the traveler asks whether that apartment is available, however, we leave the relatively stable world of knowledge and enter the world of live commercial data. Availability changes. Rates change. Different occupancy can produce different offers. Cancellation and payment conditions matter.

This is where UCP Lodging becomes interesting.

Alpina now publishes its UCP profile openly at /.well-known/ucp. Anyone can inspect it to see the machine-readable capabilities that Alpina exposes to agents.

Open Alpina.travel’s live UCP profile

The profile advertises the new dev.ucp.lodging.booking capability and connects it to Alpina’s live booking infrastructure. The UCP Lodging model deals with the concepts a travel transaction actually needs: property, accommodation type, rate plan, dates, occupancy, policies, guest information and payment conditions.

The draft specification is public as well. Read the UCP Lodging Booking specification. And because UCP is being developed in the open, it is also worth following the discussion around Lodging implementation and evolution on GitHub.

One detail in the specification is particularly important from an entity-centered perspective: the booking flow assumes identifiers such as property.id, accommodation_type.id and rate_plan.id are already available. In other words, the transactional protocol does not remove the identity problem. It depends on it having been solved.

Before you can transact, you need to know exactly what you are transacting on.

This is why I would resist treating UCP as another piece of markup to add to a website. The interesting architecture is the combination of persistent entity memory and live capabilities.

How far can the AI go?

For marketers, the easiest way to understand this is to look at the handoff.

An AI system such as Google AI Mode — and, as these capabilities propagate, other AI agents — can understand the traveler’s request, resolve destinations and accommodation entities, compare options, request live availability, retrieve a quote and explain rates, fees and policies. With UCP, it has a standardized way of interacting with the commerce layer rather than trying to infer the next step from webpages.

On Alpina today, however, there is still a deliberate boundary. The agent can get very close to the transaction, but final checkout and payment remain with the booking provider. Availability is revalidated, the user explicitly authorizes the next step, and only the provider confirms the reservation.

I think this handoff is one of the most important concepts for travel marketers to understand. Agentic commerce does not require giving an AI platform control of inventory, pricing or the customer relationship. The operator can expose increasingly rich capabilities while retaining control of the systems where the actual transaction takes place.

Over time that boundary will move. More steps will happen inside AI experiences and some booking flows may eventually be completed without leaving them. But the underlying architecture remains remarkably similar: the agent understands the entities, queries live state, operates within declared permissions and crosses the transaction boundary only when authorized.

What travel marketers should look at now

I would not start with the question, “Do we support UCP?” Start by testing whether an agent can follow the complete path:

• Identity: does it know exactly which destination, property or accommodation it is dealing with?
• Memory: can it navigate the relationships around that entity instead of relying on isolated snippets of markup?
• Live state: can it obtain actual availability, rates and policies rather than infer them from indexed content?
• Capability: can it discover what actions the business allows?
• Handoff: is it clear where the AI stops and where the booking platform, human or partner takes over?

For the upcoming season, turn these questions into a practical readiness exercise:

1. Audit your core entities. Confirm that your destinations, properties, room types, offers and rate plans have stable identifiers and consistent names across your website, booking engine and distribution partners.
2. Connect content to live data. Make sure an agent can move from a property description to current availability, rates, occupancy rules and booking policies.
3. Document your capabilities. Identify which actions you want agents to support now: discovery, availability checks, quotes, booking requests or referrals to your booking provider.
4. Define the handoff. Decide where payment, consent, customer support and reservation confirmation should take place, and make that boundary clear.
5. Test real traveler journeys. Use seasonal scenarios such as family holidays, ski weekends, shoulder-season breaks and last-minute stays. Check whether an agent can understand the request, find the right entity and reach the correct booking step without ambiguity.
6. Measure the gaps. Record where the agent loses context, uses outdated information, confuses properties or cannot complete the next action. These gaps are your implementation roadmap.

This is the part of agentic commerce that I find most interesting after Zurich. We started with structured data because machines needed help understanding webpages. We moved toward Knowledge Graphs because agents need persistent, navigable memory. Now protocols such as UCP are adding a transactional language on top of that memory.

The progression is becoming very concrete: search helped machines find pages; structured data helped them interpret pages; Knowledge Graphs help them understand and remember entities; UCP gives them a standard way to act on those entities.

For travel, this means the distance between “Where should I stay?” and “Book it” is getting much shorter.

The most useful next step is to assess what this means for your business before the upcoming season begins. If you are a hotel, destination, accommodation provider or travel platform, contact us and share your business goals for the season ahead. We can help you identify the entities, data connections and agentic capabilities you need to make your inventory easier for AI systems to understand, recommend and transact with.