Agentic Commerce for Hospitality

This article is part of the series Agentic Enterprise Capabilities: Solutions for the Hospitality Industry. Upcoming articles cover in-stay interactions for property operations staff, guest and staff interactions through personal agents, and EnterpriseLLM, a small language model built for hospitality. Follow us to learn more about agentic enterprise use cases for hospitality.

The shift: guests plan and book inside AI assistants

Travel planning is moving into artificial intelligence (AI) assistants. AI platforms sent 44.5 million visits a month to travel sites, on average. That covers June 2025 to May 2026. It is up 115.6% on the year before (Similarweb, 3 Sep 2026). In the US, 56% of travelers used AI for at least one trip last year. That is more than double the 2024 share (TravelAge West and Phocuswright, 26 Mar 2026). And 44% of US travelers say they would book directly inside an AI platform (PhocusWire and Phocuswright, 28 Jul 2026).

Large hotel brands are already there. IHG has an app inside ChatGPT. It hands the booking back to IHG's own channels (IHG, 3 Jun 2026). Hilton's AI Planner, in beta, follows the same pattern (Hilton, 10 Mar 2026). In both, the assistant helps the guest decide, and the brand keeps the booking.

Figure 1. Three signals: devices, guest attention, and governance. AI glasses are one more place a guest can ask an assistant. Sources: Counterpoint Research, 12 Aug 2025 and 27 Feb 2026; Similarweb, 3 Sep 2026, an estimate. ISACA AI Pulse Polls: 7 May 2024, 25 Jun 2025 and 5 May 2026, with the 2024 value as restated in the 2025 release.

Why hotels first

Booking a trip is hard work. Many attempts never finish. Travel carts are abandoned about 87% of the time. For ecommerce overall, the figure is about 70% (Stripe, updated 29 Jul 2026). An assistant shortens that path. It puts search, comparison, and payment in one conversation.

Accenture asked 5,003 travelers which steps they would fully hand to an AI agent. 40% would let it compare options. Only 14% would let it complete a reservation. Just 10% would let it make the payment (Accenture Research, 10 Sep 2026).

Those numbers suggest a simple design. Let the assistant search, compare, and hold a room. Let the guest confirm and pay.

Direct booking makes this worth money. Hilton's CEO told investors that "80% plus of our business is already direct" (Hilton Q1 2026 earnings call transcript, 28 Apr 2026). IHG says its loyalty members are about ten times more likely to book direct. They also spend about 20% more than non-members (IHG 2026 Half Year Results presentation, 11 Aug 2026). An assistant can protect those relationships, or slowly wear them away.

The risk of waiting

The decision now happens inside the assistant. That is true even when the payment does not. In my view, a hotel the assistant cannot read may never make the shortlist.

A Florida Atlantic University paper argues that AI booking can shift loyalty to the assistant, away from the brand (Florida Atlantic University, 11 Sep 2025). Horwath HTL adds a cost warning. A brand absent from assistants now may pay to win the guest back later (Horwath HTL, Feb 2026).

Readiness is low across commerce. Only 15% of merchants have catalogs an agent can discover. That figure comes from 1,185 retailers in the US, Brazil, and the UAE (Visa Acceptance Solutions and Cybersource, fielded Mar 2026). Hotels were not in that survey, but the lesson applies.

The solution in plain words

Every assistant has its own rules, and new ones keep arriving. A separate link to each does not scale.

The solution is one connection, built once for every assistant. It uses the Model Context Protocol (MCP), an open standard that lets AI assistants use a business's tools. Some call this connection the MCP backbone. Each assistant becomes one more booking channel, beside the hotel's website, call center, and online travel agencies (OTAs).

What the one connection does

• It answers with the hotel's own facts. It returns the hotel's prices, availability, and policies. It runs no AI model of its own, so it gives the same answer to every assistant.
• It lets the assistant hold, not sell. The assistant can hold a room for 15 minutes. The guest then confirms the exact total.
• It keeps payment with the hotel. The guest pays on a hosted checkout page from the hotel's payment provider. On Alexa+, the guest pays through Alexa+ checkout. Card details never enter the chat.
• It gives each assistant only the permissions the hotel grants. Each approved assistant can search with its own credential. A signed-in guest can book. The hotel can switch off one assistant without touching the others.
• It knows the guest across assistants. Each guest has one account, and joins the loyalty program automatically at the first sign-in. A booking made in one assistant appears in the others.
• It works in chat, voice, and interactive views. Every answer comes as text and data, plus cards to tap where the assistant shows them.

Two rules matter most: nothing an assistant says can change a price, and no assistant moves money.

The hotel's systems stay in charge

The hotel's systems keep the official record. The central reservation system (CRS) keeps rates, availability, and bookings. The property management system (PMS) runs the front desk, from check-in to housekeeping (Cloudbeds, 2 Apr 2024). The folio is the guest's running bill (Hotelogix, updated 21 Oct 2026). The hotel can run each one on AWS, on its own premises, or as a vendor's service. One booking service is the only part that calls them. No assistant reaches them directly.

Payment follows a pattern hotels already know. The guest's card is authorized first. It is charged only after the CRS confirms the room. If the room is gone, the hold is released. Stripe notes that "hotels often authorize a payment in full before a guest arrives" (Stripe, accessed 22 Oct 2026).

Money can also flow the other way. A guest may ask the hotel to arrange a tour. After the guest approves, a fixed workflow, not an AI model, pays the partner through Amazon Bedrock AgentCore payments. The hotel pays only partners on its approved list, within a set cap. The guest sees one charge, on the hotel bill. The hotel funds these payments from a digital wallet that holds a stablecoin, a digital currency tied to a currency such as the US dollar. So this step needs its own legal and finance review before the hotel turns it on.

The solution runs on Amazon Bedrock AgentCore, an AWS service for running AI agents and their tools. Figure 2, at the end of this article, shows it for your technical team.

Watch it work

The narrated walkthrough below is the recorded demo, and it is the reference implementation of this solution. I recorded it in October 2026. It shows one hotel booking service on five AI surfaces, in this order:

1. Meta Muse, text only. The guest checks saved bookings and asks for a Miami hotel. The guest reviews the dates and total, confirms, and pays.
2. Claude, with an interactive view. Claude shows an interactive view from the MCP Apps extension beside the chat. The guest browses reservation cards from the same booking record, holds a room, and pays.
3. ChatGPT, with an interactive view. The guest checks loyalty benefits, including member rates. The guest explores hotel cards and room offers, holds a room, and pays.
4. xAI Grok. Grok pairs an interactive view with short chat requests. The guest finds a Raleigh stay, compares room offers, and pays through the payment link.
5. The hotel's own assistant. It combines on-screen choices, chat, and voice. The guest asks by voice, taps to choose, and books at the member rate.

Video. “Recorded demo: one guest, every AI assistant” (narrated walkthrough).

The live demo uses ZenithStays, a reference brand for demo purposes, and synthetic data. Every guest payment ran on Stripe's hosted checkout in a sandbox (test mode), so no money moved. The demo does not show partner purchases through AgentCore payments. The video is a personal project, not an official AWS video. No company shown in it sponsored or endorsed it.

One point applies to every hotel. Each assistant gets the same data, but it can add its own reading. In the walkthrough, one assistant added detail from the web, and the guest saw numbers that were not the hotel's. The price the guest confirmed still came from the hotel. Even so, the brand can answer for what an assistant says, as the section on trust shows.

Trust and governance

When an assistant gets it wrong, the brand pays. In Moffatt v. Air Canada, a tribunal held the airline responsible for its chatbot. It rejected the claim that the chatbot was a separate legal entity (BC Civil Resolution Tribunal, 14 Feb 2024).

Hospitality now has its own starting point. On 4 October 2026, the AI Hospitality Alliance (AIHA) published its Hospitality AI Governance Framework. Where AI can act, it says governance should define "the scope of its delegated authority". It should also define "the identity under which it acts", and when autonomy can grow or shrink (AI Hospitality Alliance, 4 Oct 2026).

Note: AWS staff sit on the AIHA advisory board.

Here is how I read the solution against them. This is my own mapping, not an AIHA review:

• Identity. Each assistant connects with its own sign-in. The hotel can limit or switch off each one alone.
• Delegated authority. Searching needs the assistant's own credential or a signed-in guest's. Booking needs the guest's own account. Payment always needs the guest's own confirmation.
• Autonomy. The assistant may search, compare, and hold. It may not set prices or take money. Widening that is a hotel decision, not an assistant's.
• Accountability. Price, booking, and payment stay in the hotel's systems. The hotel can stand behind every confirmed booking.
• Guest data. Each tool returns only the fields its task needs. Stored guest data is encrypted with keys the hotel controls. A guest can ask the hotel to delete their data. The assistant's maker also sees the conversation, under its own terms. The hotel's legal review sets the data rules for each market.

The framework is version 1, from AIHA Workgroup 8. Hotels that test it can help shape version 2.

Two more AIHA workgroup guides provide further guidance on:

• AI orchestration. Workgroup 2's AI Orchestration Framework for Hospitality puts one shared control layer between AI agents and hotel systems. Its rule is short: "Models propose. Deterministic code acts." Here, the one connection is that layer. Plain code makes every booking, and no AI model holds the keys to the hotel's systems.
• Agentic protocols. Workgroup 1's Agentic Protocols Adapted for Hospitality asks hotels to choose the smallest integration that meets the need. Here, every assistant uses one protocol, MCP, with OAuth sign-in. The gateway checks each token and never passes it on to the hotel's systems, as the guide advises. The guide treats payment protocols such as MPP as optional. Here, one appears only when the hotel pays a partner.

Together, the three guides cover governance, orchestration, and protocols. This solution shows how they fit together in one design on AWS.

What the guest gets, and what the hotel keeps

• Guest assistants
  • What the guest gets: Search, hold, and book in ChatGPT, Claude, Alexa+, Meta Muse, Grok, Perplexity, WhatsApp, and others.
  • What the hotel keeps: One connection for every assistant, and the power to switch any one off.
• The hotel's own assistant
  • What the guest gets: Voice and chat, with on-screen choices.
  • What the hotel keeps: Its own channel, on its own systems.
• Website, app, and OTAs
  • What the guest gets: The same rooms and rates as every assistant.
  • What the hotel keeps: One CRS that keeps every channel in step.
• Prices and bookings
  • What the guest gets: The exact total, confirmed before paying.
  • What the hotel keeps: The CRS, PMS, and folio keep the official record. Only the booking service calls them.
• Guest payment
  • What the guest gets: Hosted checkout, or Alexa+ checkout. Card details never enter the chat.
  • What the hotel keeps: The card is authorized first, then charged after the CRS confirms.
• Partner purchases
  • What the guest gets: Tours and transfers the guest approves, on one hotel bill.
  • What the hotel keeps: A workflow pays the partner through AgentCore payments, within a set cap.

How a hotel can start

1. Make your facts readable. Put rates, availability, and policies in a form an assistant can read. An assistant cannot sell what it cannot read.
2. Decide who can do what. Do this before you build anything. Approved assistants can search. A signed-in guest can book, with loyalty benefits from the first sign-in.
3. Get one connection to your own systems. A hotel group can build it. An independent hotel can ask its CRS or PMS vendor for one. Keep price, inventory, and the guest's bill where they are today. Start with read-only access to rates and availability.
4. Start small, and keep checkout. Launch on one assistant plus your own channel. Let the assistant hold, and let the guest pay on your checkout. Check your distribution contracts first. They may limit which rates each assistant can show.
5. Measure, then grow. Track assistant traffic as its own line in your booking funnel. Add the next assistant as it opens.

Figure 2. Reference architecture: hotel services on AI agent surfaces with Amazon Bedrock AgentCore. Full detail: Serve agentic AI surfaces from one MCP backend on Amazon Bedrock AgentCore. Select the diagram to open it at full size.

The author works at AWS, and the views here are his own.