The single hardest engineering problem in shipping a real hospitality agent is not the model, the prompts, or the API integration. It is the state machine. A reservation is not a single object — it is a sequence of states, each with different valid transitions, and any agent that can act on a reservation needs to understand which state it is in and which transitions are allowed from there. Get this wrong and your agent confidently breaks bookings in ways that take hours to unwind.
Why hotel objects are state machines
A reservation moves through states: inquiry → booked → modified → checked-in → in-stay → checked-out → folio-closed → archived. From each state, only specific transitions are allowed. You cannot modify a checked-out reservation. You cannot cancel a checked-in reservation (you do an early departure instead). You cannot apply a cancellation penalty to a no-show in the same way you apply it to an active cancellation. A guest who has already paid in full has a different modification flow than a guest with a credit-card guarantee.
Humans handle this implicitly because reservation agents have been trained over months on what is allowed when. An agent does not have that intuition — it has whatever you wrote in the prompt and the function specs. If you do not explicitly model the state machine, the agent will at some point try to cancel a checked-in reservation or modify a closed folio, and the PMS will either reject the call (best case) or accept it and produce a corrupted state (worst case, which has happened to me twice in production).
How to model the state machine in an agent
Where I have seen this break in production
At the chain in Warsaw, the reservation-modification agent had a function called cancel_reservation. The state-machine model was implicit — I assumed the function would refuse to cancel a checked-in reservation. It did, at the PMS layer. But the agent, on receiving the PMS error, would try the function again with a slightly different argument, then a third time, then send the guest a "your cancellation has been processed" email because the state-machine assumption in the prompt was "successful function call means it worked." Four guests received cancellation confirmations for reservations that were not cancelled. The fix was to make state explicit in the function spec; the cost was a week of rework and one apology call to a corporate client.
The minimum viable state model
Before you write the first function for a hospitality agent, write down: the object types the agent touches (reservation, folio, guest profile, room block), the valid states for each, and the valid transitions between states. This is usually 30-60 minutes of work with the operations director. The output is one A4 page. That page becomes part of every agent system prompt, every function pre-condition, and every audit log entry. Skip this step and you will spend it later, in production, with guests on the phone.