Why the booking agent is the wrong place to start

Every operator I meet wants to build a booking agent first. "An AI that takes guests from intent to confirmed reservation, in chat, in any language." It sounds like the obvious flagship use case. It is also the workflow that has burned the most money across the early agentic deployments I have audited. The reasons are specific, and they are not about the LLM being weak.

Reason 1: The action space is huge

A booking agent that can actually book has to: search availability across rate plans and room types, evaluate promotions and discount eligibility, handle loyalty-member identification, apply correct taxes and fees (which vary by stay date, length, and guest country of origin), execute a payment authorization, hold the room with the correct guarantee policy, write the reservation to the PMS, sync to channel managers if relevant, send a confirmation email in the correct language, and log everything. That is 12-20 actions, with branch points at every step.

Compare to a reservation-modification agent: 4-5 actions, linear flow. The complexity gap is an order of magnitude — and complexity is where agents fail.

Reason 2: The asymmetric failure cost

When a reservation-modification agent makes a mistake, the guest sees an incorrect modification on their existing booking; you fix it in the PMS, send a corrected email, apologize. Recoverable within 15 minutes. When a booking agent makes a mistake — wrong dates, wrong price, missing tax, no-show policy not communicated — the guest shows up at the front desk with an expectation mismatch, and the property either honors the mistake (lost margin) or argues with the guest at check-in (lost guest, plus likely a one-star review). The blast radius is much larger.

Reason 3: The competitive landscape

Booking flows are a solved problem from a UX perspective. Your direct booking engine works. OTAs work. The marginal value of "the same booking experience but in chat with an AI" is small — guests have to learn the agent's conventions, they cannot see availability calendars, and the trust threshold for handing over a credit card to a chatbot is genuinely higher than for a familiar booking form. Operators consistently overestimate guest demand for chat-based booking.

Where I have seen booking agents actually pay off is in narrow, high-context channels: WhatsApp inquiry handoffs where the alternative was a human reservations agent typing in the same flow, or inbound voice calls routed through a voice agent during overnight hours when the desk is unstaffed. Those are real wins, but they are not the "AI books you a room from chat" flagship the operator team usually imagines.

What to build instead

Build a reservation-modification agent first. Run it for three months. Learn the patterns of logging, rollback, human escalation, and prompt iteration on a workflow where the failure cost is bounded. Then build group block management. Then channel rate parity. By the time you get to a booking agent — if you still want one — you will have the operational muscles to ship it without the failure mode that has burned every team that started there.

At the second chain we worked with, the CEO insisted on the booking agent as the first project. Eight months and €180,000 later, we shipped a reservation-modification agent instead. He still tells me it was the most useful project we ran together.