Worked examples

Overview

Overview

Five flows showing how the capabilities sit between agents and the systems of record. They are illustrative reference patterns, not approved implementation sequences: Use-Cases A and B are templates to run against real vendor systems, C and D are generalized from production deployments, and E is a synthetic paid-upgrade scenario.

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.

For planning a bounded implementation, see the Scalable AI Platform Architecture Blueprint for Hospitality’s deployment intake and reliability guidance. Use the Hospitality AI Governance Framework for testing responsibilities and the AI Readiness Guide for Hotels for operational participation. These complement this guide; they do not establish that its examples have been jointly validated.

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.

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.

Use-Case E – paid suite upgrade

Demonstrates the guarded payment pattern for a paid upgrade. This synthetic scenario is illustrative: a guest staying two nights is offered a suite upgrade for $80 per night, $160 in total. Use-Case B still covers complimentary or discounted upgrades that policy or staff approve; this example covers an upgrade the guest pays for. The pattern itself is described under Guarded payment.

• Offer. The tool orchestrator reads suite availability and the upgrade price for both nights from the RMS, and the commercial-constraints check confirms that this agent may make the offer at that price. The guest sees the exact terms, for example: “Upgrade to a one-bedroom suite for both nights of your stay: $80 per night, $160 in total, plus applicable taxes, paid now by card. If the suite cannot be assigned after payment, the hotel will return the amount through its refund process. This offer expires in 30 minutes.”
• Verify. The conversation may already be bound to the reservation, but binding is a lookup, not authority to charge. Because this action can create a charge, the light guest-verification gate does not apply, and a matching channel identifier alone is not enough. The layer applies the stronger, action-specific verification that the operator requires for payment actions, such as a step-up check, or hands the guest to staff.
• Record the agreement. When the guest accepts, deterministic code stores the exact offer text, price, nights, terms, expiry, timestamp and channel, with the verified guest, reservation and conversation references and the action's correlation ID. The record shows what the guest agreed to. It is not payment authentication, and it covers only this offer: a different price or a new offer needs a new agreement.
• Select the payment path. Operator-approved rules, not the model, select a path that the hotel's payment service supports for this charge. In this scenario the rule selects immediate payment through the payment service, with guest authentication where it applies. Alternative sequencing is described below.
• Check policy and operating mode. Before release, the layer rechecks commercial constraints, action precedence (for example, that staff are not already changing this reservation) and operating mode. During the night audit the financial write is held, not executed: it is queued with its idempotency key and shown to staff as pending, and the guest is told the upgrade is pending, not confirmed. When the window closes, the layer revalidates price, availability, authority, precedence and offer expiry before release; if anything has changed, the guest receives a new offer or the request lapses.
• Payment outcome. The deterministic executor sends one request, with its idempotency key, to the authorized payment service, which performs any required authentication and returns the outcome. The layer records the nonsensitive payment reference and the result. The payment token and any charge-capable credential stay with the payment service and never enter agent context.
• Recheck inventory and change the reservation. After a successful payment, the layer rechecks that the suite is still available for both nights. The guarded write then moves the reservation in the PMS under the action's authorization, and the upgrade charge and payment are recorded on the folio as the hotel's PMS integration requires.
• Tell each party what happened. The guest is told the upgrade is confirmed only after the PMS confirms the room change. Staff see the payment reference, folio status, PMS change and any exception. If any outcome is still pending, both messages say so and neither describes it as complete.

Keep three things separate, as Agentic Protocols Adapted for Hospitality does: evidence of payment authority (here, the action-specific verification and recorded agreement), the payment exchange (the payment service's authentication and execution) and the hotel's confirmation (the PMS change). Success in one does not establish the others. Its programmatic payment controls list related implementation checks.

Alternative sequencing. Some hotels' supported contracts call for posting the upgrade to the folio for settlement at checkout, or for a card authorization or authorization increment instead of immediate capture. The offer terms then say so, and the order changes: the layer obtains any authorization or increment the contract requires, rechecks inventory, applies the authorized PMS change and posts the charge to the folio; settlement follows the hotel's normal checkout process. The Scalable AI Platform Architecture Blueprint for Hospitality likewise lets the order depend on the payment method and booking contract. Whichever path applies, an operator rule selects it and each outcome is recorded separately.

Exceptions keep the same controls:

• Payment succeeds, but the upgrade cannot be applied. For example, the suite sells before the PMS change. The layer does not report the upgrade as confirmed or request another payment. It reconciles the payment outcome with the payment service and the PMS, tells the guest the upgrade could not be completed and that the amount will be returned through the hotel's refund process, and opens a staff task. The void or refund is a separate payment action with its own authorization, from an authorized staff member or a pre-approved operator rule, and its own idempotency key.
• Uncertain outcome, such as a timeout. The payment is recorded as unknown. The layer checks the payment service by the request's idempotency key or reference before any retry, and it neither confirms the upgrade nor requests another charge until the outcome is known.
• Decline or incomplete authentication. No PMS change is made and nothing is posted to the folio. The guest is told that the payment did not complete and may be offered another supported path; the offer still expires at its stated time.
• Duplicate request from a retry. The payment service returns the original outcome for the same idempotency key, so no second charge is made and the PMS change is applied once.
• Changed price or expired offer. The earlier agreement does not cover a different amount or a lapsed offer. The guest receives a new offer at the current price, or the request lapses; nothing is charged at either price until a new agreement is recorded.
• Unverified guest or out-of-scope agreement. No payment request is sent and nothing changes in the PMS or on the folio. The guest is routed to verification, to the current offer's terms or to staff.

This example is illustrative and synthetic, not a validated implementation sequence. Confirm payment paths, consent and authentication requirements, and refund authority with the hotel's payment providers and qualified payment specialists. For hotel-payment lifecycle guidance, see the AHLA/HTNG Payment Optimization Playbook [R16].

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.