AI Agents That Book Hotels: What Your Hotel Needs to Answer

For the last two years the question for hotels has been whether an assistant names you. That question is not finished, but a second one has appeared behind it. Assistants are increasingly expected to complete a task rather than produce a shortlist, and completing a booking task means asking follow-up questions about specifics.

A hotel can pass the first test and fail the second. You get named, the guest asks the assistant whether you have a family room with a cot for three nights in June, and the assistant has nothing to work from except a paragraph about your warm welcome.

The question classes are fairly predictable, and they are the same ones your front desk answers by phone all day. Room types and what occupancy each takes. An indicative rate rather than a marketing "from" price. Whether anything is free on specific dates. The cancellation deadline and what happens after it. Taxes and fees, and whether they are included. Check-in and check-out times, including whether early or late is possible. Pets, children, extra beds. Accessibility, specifically rather than as a tick box.

Notice that almost none of that is new information. It exists in your property management system, your rate sheet and your policy document. The gap is not that hotels lack this data. It is that the data is not in a form anything other than a human can read.

OTAs expose structured inventory through APIs, because their whole business depends on other systems being able to query it. Your own website typically exposes a booking widget, which is an interface built for a person with a mouse and effectively opaque to anything else.

That is the citation gap again, one layer deeper. On the recommendation layer the OTA wins because its page is a denser source. On the transaction layer it wins because its data is queryable and yours is a form. Both are structural rather than a matter of effort, and both are addressable in the same direction: make the facts legible to machines, not just to guests.

MCP stands for Model Context Protocol. It is an open protocol that lets an assistant call named tools against a specific source instead of scraping a page and hoping. In a hotel context the tools would be things like "list room types", "get cancellation policy", "price a stay for these dates".

That is a description of a mechanism, not a claim about adoption. We are not going to tell you what share of assistants support it, how many hotels have implemented it, or what it does to conversion, because we do not have defensible numbers for any of those and the honest state of this is early.

Start with the floor, which is unglamorous and does most of the work. Accurate structured data on the website so a crawler can extract your facts without interpreting prose. One maintained place where your real room types, rates, taxes and policies are written down and kept current. Policies phrased as facts rather than as reassurance, so "cancellation is free until 48 hours before arrival" instead of "we offer flexible cancellation".

The ceiling is a live endpoint an assistant can query directly for availability and pricing. That is the part that is genuinely new, and the part to be cautious about committing to. Staylight has an agent layer in beta for exactly this, opt-in, on the paid plans above the entry tier. It is beta in the real sense: not switched on by default, and not something we would tell you to build a commercial plan around yet.

Write the facts down properly. Room types with real occupancy, an honest indicative rate band, the actual cancellation deadline, the real check-in window, what you do about pets and cots and accessibility. Put it somewhere maintained rather than scattered across a brochure, a PDF and three OTA listings that disagree.

This is worth doing on its own terms. The same accurate fact base improves what every current engine says about you, reduces the chance of an assistant inventing a policy you do not have, and gives your own staff one source to quote. If agentic booking turns out to matter, you are ready. If it stalls, you have still fixed the thing that was making engines describe you wrongly.

There is no public data on how much hotel booking volume currently flows through agents, so any percentage you see quoted is somebody's model rather than a measurement. The commercial arrangements are unsettled: it is not established who pays whom when an assistant completes a booking, or whether that resembles a commission, a referral fee or nothing at all.

It is also not safe to assume any particular protocol wins. Protocols get adopted, replaced and abandoned. The reason we still think the groundwork is worth doing is that the groundwork is protocol-independent: an accurate, maintained set of facts about your hotel is useful to whatever asks.