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.
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.
| Feedback incorporated (D. Bosancic) 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 Integration inventory–7. |
|---|
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.