Overview
Overview
Four flows showing how the capabilities sit between agents and the systems of record. They are illustrative reference patterns — Use-Cases A and B are templates to run against real vendor systems, C and D are generalized from production deployments — not approved implementation sequences.
A joint test needs at least two member/vendor stacks, an agreed evidence template and an operator-controlled non-production environment or witnessed vendor sandbox. The guide does not claim those tests have been run.
Include the operational teams affected by each workflow, such as Front Office, Reservations, Housekeeping, F&B, Revenue and Engineering. Test realistic exceptions and assess whether the outcome is operationally appropriate, not only whether the system calls succeed. Record the teams’ decisions and reasons alongside the technical evidence to inform later refinement.
Use-Case A — check-in event fan-out
Demonstrates the event path (Control plane) with partial-failure containment.
- Guest completes check-in → the request is routed to the PMS, authenticated by Auth & governance.
- The PMS confirms the reservation and assigns the room (synchronous, through the layer).
- The PMS emits a "guest checked in" event → the event path fans it out to room locks (issue credential), GRMS (recall preferences), guest messaging (welcome), POS (open folio), and housekeeping (update status).
- Every downstream call is written to Observability & audit as it happens.
- A room with an open maintenance ticket does not auto-complete — policy routes it to human handoff.
| Not all downstream failures are equal: a failed welcome message is cosmetic, a failed lock credential is a guest standing in the corridor. Each flow marks which failures can be deferred and which must halt the workflow and alert a human immediately — here, credential issuance is halt-and-alert; messaging and status updates are deferrable and retried. The delivery guarantees this relies on (at-least-once, ordering, replay) are stated in Event delivery requirements. |
|---|
Use-Case B — AI-assisted room upgrade
Demonstrates guarded write under a policy-gated approval. The agent’s request attaches identity and reservation; Tool orchestrator calls CRM (tier) and RMS (upgrade inventory and price) in sequence; policy checks whether this agent, for this tier and rate plan, may comp or discount — and if not, holds the action and hands off to staff with context attached. On approval, the change executes in the PMS through the guarded-write surface; the model holds no authority to authorize it.
Use-Case C — voice booking via guarded conversion
Demonstrates guarded conversion. The agent quotes availability through read-only calls, agrees the stay, and issues a pre-filled deep link to the caller’s number. At submission the guarded surface revalidates availability, price and cancellation terms before any write; where inventory has sold, the guest is re-quoted rather than refused; on a multi-room link, revalidation runs per room. Deterministic code then creates the reservation and runs the guarantee cycle. A mis-captured detail cannot corrupt the reservation, because the guest supplies their own identity data on the surface the model does not control.
Use-Case D — verification-gated access release via guarded disclosure
Demonstrates guarded disclosure. Reservation matching binds the conversation using practical keys (name plus arrival date; phone plus arrival date on voice; email). Deterministic code checks reservation and verification state, and only then does the corresponding knowledge tier enter the model’s context — general information before verification, access details after. On a verification event, the event path promotes the tier so a guest who checks in mid-conversation need not ask again. The pattern is sharpest in short-term rentals, where access details are unit-specific — one reason unit-level inventory is a Phase 2 extension rather than a change to the architecture.
Employee-assisted late checkout (illustrative)
An employee asks whether a guest can check out late. The assistant brings together the reservation, entitlement, next arrival and housekeeping capacity, using sufficiently current information from the responsible systems or teams. It presents an option and its constraints for the employee’s judgment; missing or stale information prompts confirmation rather than an assumed answer. Where approval is required, the authorized employee decides. Any resulting system change follows the existing guarded-write controls. This illustrates the existing architecture; it is not a validated implementation sequence.