When Google opened the UCP for Lodging waitlist, two things were missing: a published spec, and any named partners. We wrote at the time that it was an announcement, not a release — and gave the prescriptive read on what the lodging spec would have to handle before agents could book hotels safely.

A proposed Domain Tech Council (DTC) charter for Lodging — opened on GitHub on 24 June — just supplied the second of those missing pieces, and sketched the first. It names a committed core of participants and lays out a phased roadmap for how agentic hotel booking gets built. There is still no schema to validate against. But for the first time, there is a shape.

Here is what the charter commits to, what its phasing confirms, and — the part that matters most — what it deliberately leaves for later.

#The participants: a committed core, not the whole waitlist

The charter proposal lists Google as the consumer surface, alongside six hospitality and distribution businesses committing to build to the standard: Booking.com, Expedia, Hilton, Marriott, Trip.com, and Amadeus.

That is worth reading precisely. Google's lodging waitlist had drawn a longer list of names — Accor, Choice Hotels, IHG and Wyndham among them. The charter is narrower and stronger: it is the subset putting their name to a commitment to implement, not just an interest in the category. A standard lives or dies on who actually ships it, and this is the first signal of who will.

#The roadmap, phase by phase

The charter sequences the work into three stages. Quoting the proposal:

Phase 1 — the booking core. "Secure checkout and reservation confirmation, incl. rate selection, availability confirmation and guest details handling," plus native payment execution. In plain terms: an agent can take a chosen rate, confirm it is still real, collect the guest's details, and pay — end to end.

Phase 1.5 — identity and loyalty. "Secure account linking via standardized OAuth wrappers," plus loyalty status and member rates. This is the layer that lets an agent book as you — pulling your Bonvoy number, your Honors rate — rather than as an anonymous guest.

Future — discovery and deals. Real-time lodging discovery, availability fetching, and deals/discounts handling, with timing and priority marked TBD.

The ordering is the tell. The charter starts at checkout, not search. Discovery — the part most people picture when they imagine "ask an agent to find a hotel" — is explicitly deferred. The hard, money-moving part (confirm a real rate and take payment) comes first.

#What the phasing confirms

We will say the quiet part out loud: the roadmap tracks the shape we mapped in May, and that is a good sign for anyone building.

• Phase 1's "availability confirmation" is re-validation by another name — the agent confirming a rate is still bookable before it commits. We flagged this as non-negotiable, because a hotel rate is generated from property × room type × rate plan × dates × occupancy and can vanish mid-session.
• Phase 1's "rate selection" and "guest details handling" are the dynamic-offer and booking primitives a room needs because it is not a fixed SKU.
• Phase 1.5's "loyalty status and member rates" is exactly the identity-and-servicing layer we said lodging would need beyond a one-shot retail checkout.

None of this is a surprise if you have been close to the data. It is confirmation that the people building the spec see the same constraints the rest of us measured.

#What it still leaves open

A roadmap is not a schema, and the charter is careful to stay at the level of intent. The hardest questions — the ones that decide whether an agent books the right room at the right price — are still unanswered:

• How is an offer's clock represented? Phase 1 needs a time-boxed rate, but the charter does not define the TTL, the offer object, or what an agent does when it expires. This is the exact failure mode we measured: we ran five frontier models against expiring travel inventory, and none of them checked an offer's clock before acting. "Availability confirmation" is the right Phase 1 goal; the contract for how it works is what will make or break it.
• What counts as the price? Resort fees and occupancy taxes mean the nightly rate is not the total. Until all-in pricing is specified, agents will quote the wrong number.
• Is cancellation machine-readable? Free-cancel deadlines and penalty schedules have to be structured data, not prose terms, or an agent cannot honour "free cancellation" as a filter.

These are not criticisms of the charter — they are the agenda it implies. Phase 1 cannot ship safely until they have answers, which is precisely why measuring real agent behaviour against real inventory matters now, before the spec freezes.

#What hoteliers and booking engines should do now

You do not have to wait for the schema to get ahead of it. The Phase 1 primitives are predictable enough to prepare for:

1. Make sure your offers carry a clock. Your booking engine should be able to expose a rate with a validity window — that is the object Phase 1 will standardise. Validate your endpoint.
2. Make pricing all-in. An agent needs to read the total with taxes and fees, not just the nightly rate. Check your catalog.
3. Test how agents handle expiry today. Before you integrate, run a frontier model through your flow and watch what happens when a rate changes mid-session. Here is what we found when we did.

We track UCP for Lodging on a dedicated vertical page, and we will update it — and validate against it — the moment the spec lands. The charter is the clearest signal yet that agentic hotel booking is being built in earnest. The next milestone is the one that actually changes what an agent can do: a published spec with an offer object, a price, and a clock.