Agentic Protocols Adapted for Hospitality

Overview

Overview

Primary audience: This guide is primarily for CTOs, architects, engineers, integrators and technical/product teams at hotel companies and vendors who select, build or assess agent integrations, including the security, privacy and procurement teams supporting those decisions. Operators, owners and commercial leaders are a secondary audience: they can use it to define business requirements and discuss integration choices with technical teams.

A hotel use case tells you what the business wants to achieve. A capability describes the data or action the software must expose. A protocol defines how the participants interact. Keep those three levels separate, then connect them through an explicit contract.

This guide maps every case in the AI Hospitality Alliance’s 100+-use-case catalog ↗ to a practical integration choice, semantic objects and controls. The catalog covers eight categories and layers. Its priority scores and adoption labels describe the submitted use cases, not protocol maturity or independently verified returns.

Read the protocol map first, use the selection steps to describe your boundary, then open the relevant use-case entries. The capability and control references let an operator’s question lead directly to an engineering discussion.

For SMB/independent hotels, start with a managed integration, narrow permissions and an explicit manual fallback. Enterprise teams can apply the same controls through portfolio-wide identity, registries and shared services. Property teams own local facts, fulfillment and escalation; corporate teams own common contracts, vendor admission, identity policy and cross-property access.

Contributor participation does not imply endorsement of every recommendation or mapping.

How the pieces fit together

How the pieces fit together

The seven layers are responsibilities to check, not seven products to buy or a mandatory sequence of network hops. A configured integration may skip dynamic discovery. Identity, control and evidence apply throughout.

The Workgroup 2 integration and control layer → explains where orchestration and deterministic checks sit. Workgroup 3 covers platform architecture →; Workgroup 4 → covers data readiness; Workgroups 5 and 6 cover discoverability and visibility outcomes. Those responsibilities complement this guide’s protocol and capability choices.

Technical capability and AI visibility answer different questions

This is not simply a chatbot on your website. A chatbot is a user-facing interface. It may use these protocols underneath, but a conversation alone does not show that software can retrieve authoritative hotel data or act on a guest’s behalf.

This is not another distribution channel in itself. Exposing a capability does not add an OTA or settle commercial participation, commissions, attribution or rate-parity terms. It makes an existing hotel-system capability accessible to permitted software; the commercial arrangement still needs its own review.

This is not the same as AI visibility. A hotel can be frequently recommended by AI yet lack a usable booking integration. It can also expose a reliable booking integration and receive little AI visibility. These are separate dimensions, not a guaranteed cause-and-effect sequence.

Use the Workgroups 5 + 6 visibility guide → for visibility measurement. Workgroup 1 does not define visibility KPIs, and a visibility score does not define or prove an integration contract. If a metric says “bookable within an AI assistant,” specify the actual transaction and required technical evidence before counting it. A mention, link or referral is not a completed booking.

What each protocol is for

What each protocol is for

Protocol selection at a glance

Compare the purpose and interaction boundary first. The detailed entries below describe objects, selection conditions and limitations. Confirm exact client, server, browser and channel support with the participants in your implementation.

These mechanisms are complementary, not interchangeable competitors. Distinguish formal specifications, implementations and publishing conventions when selecting an integration.

Choose the smallest sufficient integration

Choose the smallest sufficient integration

Start with one concrete action, not a preferred protocol. The same use case can be embedded in one product, connected directly by API, or exposed through MCP. These are deployment alternatives, not contradictions.

A long-running tool operation does not automatically require A2A: MCP has optional task-related extensions. Choose A2A for an independent agent’s ownership boundary, not simply because a response takes time.

Connect capabilities to implementation controls

Connect capabilities to implementation controls

Start with what the agent needs to do, such as reading room availability or changing a reservation. The capability and protocol selection table connects that task to a suitable integration method, the hotel data it must exchange and the tests it needs. CAP identifiers keep the same capability connected across the use cases, workbook and safeguards. They are reference labels, not conformance marks.

Capability and protocol selection

CAP-01 through CAP-11 describe core integration capabilities. CAP-12 through CAP-16 are supplementary editorial recommendations for operational writes, application interfaces, conversations, payment-authority evidence and plugin packaging. They are not additional conformance requirements.

The catalog directly maps CAP-01, CAP-02, CAP-05, CAP-06, CAP-11, CAP-12 and CAP-15 to use cases. Other capabilities describe shared prerequisites or options for particular architectures; they are not automatically needed in every case. CAP-03, property identity and authority, is a shared prerequisite wherever hotel-specific data or actions are involved, even when a case does not repeat that tag. “Supplementary” describes how CAP-12 was added to the framework, not its importance: operational writes recur throughout the catalog. These mappings describe proposed needs, not tested implementations.

Apply the read/write patterns only to actions actually enabled. Optional delegation, browser and commerce patterns are additions for real boundaries, not mandatory dependencies for every row.

Apply identity, control and evidence

Apply identity, control and evidence

Authentication establishes identity. Authorization permits a specific action. Consent and transaction confirmation establish what the person agreed to. Record them separately. Keep the guest, booker, payer, agent, intermediary and service credential distinguishable.

Use established OAuth/OIDC or the endpoint’s supported security model. For protected remote MCP, bind tokens to the MCP resource and do not pass them through to downstream vendors. Multi-hop token exchange is an option when explicit delegated authority must survive a boundary, not an A2A requirement.

Reusable safeguards by action

These reusable safeguards cover actions such as reading data, changing a record or handing a task to another agent. Use the action names to choose the safeguards your workflow needs. The reference codes connect the same safeguards across this guide, the use cases and the downloadable workbook; they are not protocols, risk tiers or certification levels.

Choose controls for the action’s risk

Classify the actual AI use with Workgroup 8’s governance risk framework → before choosing its technical safeguards. Risk depends on autonomy, impact, data sensitivity, reversibility, realistic human oversight and scale/reach. The same product can have different risk tiers in different deployments. The summary below follows that framework; read/write or booking labels describe actions, not risk ratings.

A read can expose highly sensitive information, and a seemingly small write can have a serious effect. Do not assign a risk tier from a protocol name or an action label alone. The assigned tier sets the ceiling for autonomy. Start new deployments with heightened supervision and expand permitted autonomy only as reliable behavior is demonstrated; reduce or withdraw it after incidents, material changes or degraded performance. [R35]

Match safeguards to the action as well as the risk

After classifying risk, identify every action in the workflow and apply its relevant safeguards. These unnumbered action types do not form a second tier system.

Trace a request across systems

W3C is the World Wide Web Consortium. Its Trace Context standard defines a shared tracking reference that software passes with a request so engineers can follow it across services. For example, an agent, the integration layer and a hotel booking system can connect their diagnostic records to investigate where a booking request failed. The traceparent HTTP header carries trace and request-position identifiers; tracestate carries optional system-specific tracing information. These identifiers are not guest identity, permission to act, proof of payment or a booking confirmation. W3C Trace Context specification →

Use the governance framework → to set the required logging and retention controls. Pass trace context only where both sides support it and your trust policy permits. If external trace data is not trusted, start a local trace and retain an approved correlation link. For legacy services, record the vendor request ID. Keep credentials, payment secrets and unnecessary guest data out of diagnostic logs. Retain a separate business audit record of the actor, approval, action, owning system and confirmed or uncertain result.

Minimum behavioral contract

A behavioral contract is the agreed description of how an AI action must behave: who may request it, what it may change, what evidence it must retain and what happens if it fails. It is an implementation agreement enforced by software and operations, not a new protocol. The record below helps a team reconstruct a material action afterward.

This recommended checklist describes what every material AI action should preserve, whatever protocol is selected. It covers sensitive reads and delegation as well as writes; idempotency applies to material writes.

Preserve timestamps, source evidence, retention class and access policy. Do not record secrets, payment credentials, unnecessary personal data or model chain-of-thought.

Contain legacy credentials and detect API drift

Where a vendor requires long-lived keys, keep them in the integration boundary, never in model context. Restrict the capabilities exposed to the agent and rotate/revoke centrally. API drift means that an integration’s behavior changes even when its documented version does not. Pin versions and run behavioral tests for schemas, errors, authorization, idempotency, side effects and authoritative state: a vendor can change rate limits, error behavior or side effects without a major version change.

Optional mechanisms for specific security boundaries

Where the authorization server supports it, OAuth Rich Authorization Requests (RFC 9396) can carry structured, fine-grained authorization_details. Where the integration requires message-level integrity and sender authentication, HTTP Message Signatures (RFC 9421) can authenticate selected HTTP message components. Define covered components, key trust and replay controls for that deployment. Neither mechanism replaces hotel business authorization, guest consent or a supported endpoint contract, and neither is a universal prerequisite.

Safeguards for each capability

Use these eleven rows after choosing a capability above. Each translates that capability into identity checks, tracing, action limits and the system that owns the final record. The seven reusable safeguard sets describe common actions across many workflows; these rows apply safeguards to CAP-01 through CAP-11. They are two complementary views, not different risk classifications.

CAP-12 through CAP-16 use the relevant reusable safeguards above. They do not have separate capability-specific rows.

Make hospitality meaning explicit

Make hospitality meaning explicit

Two systems can exchange a message successfully and still interpret it differently. Agree the meaning and format of the hotel information first: for example, whether a room means a room category or an individual physical room, and whether a quoted price includes all mandatory charges. A semantic object is a named business concept such as Reservation; its schema defines the fields and allowed values. The table below identifies what the implementation team must make explicit.

Protocol capability → hospitality gap

General-purpose protocols provide interaction mechanisms. Each hotel integration must also specify the business meaning and rules below. A gap here is a contract or implementation detail to settle; it does not mean the protocol is incapable of carrying an extension.

Protocols transport objects; they do not make all hotels mean the same thing by “room,” “rate,” “guest” or “confirmed.” The objects in the case mappings are contract requirements and proposed vocabulary, not a claim that every field has an adopted AIHA schema.

The Workgroup 4 → contribution provides detailed starting contracts for lineage, Room/RoomType, Organization/Property and controlled amenity/accessibility vocabulary. Rate/Offer, Reservation/Stay, Guest and operational activities require the current Workgroup 4 → contract plus action-specific extensions and validation. Public Schema.org mappings are useful starting points, not complete transactional schemas. Select the correct LodgingBusiness subtype and verify whether HotelRoom represents the intended category or unit in your mapping.

The hotel company’s systems are the source of truth

The hotel company’s own systems are authoritative for its property information and business records. Match external property identifiers to the company’s records, then use the company-designated system for each kind of information or action. A verified third-party domain or signed catalog does not override those records.

An authorized vendor or intermediary may connect to or operate the hotel company’s systems within granted permissions; it does not become an independent source of truth. Keep the approved source, property mapping, permitted actions and access expiry explicit. If information conflicts, check the designated hotel-company system and ask its responsible team to correct the discrepancy. Do not let the agent choose a third-party claim over the company’s records.

Test discovery without confusing it with trust

Test discovery without confusing it with trust

ARD’s current v0.91 proposal uses /.well-known/ard.json and rel="ard". The former /.well-known/ai-catalog.json path is an optional predecessor lookup for consumers, so relying only on it can make a resource undiscoverable to an otherwise conforming client.

Publishers describe resources; a registry indexes and searches them. An optional trust manifest supplies evidence under a declared trust framework. A search relevance score is not a trust score. Verify the publisher and represented property, then authenticate and authorize at the selected endpoint.

Run these tests against the intended implementation before relying on discovery. An ARD demonstration can answer how discovery works without establishing hotel authority or end-to-end booking safety. This also explains why a “trusted handshake” needs more than discovery metadata.

Execute and recover safely

Execute and recover safely

Use booking as a worked example of the general control pattern. The same boundaries apply to a service task, rate change or profile update, with the relevant authoritative system and action tier.

Minimum booking tool surface

Idempotency is a business-operation contract

The caller supplies a stable key for one logical mutation. An illustrative tool field is idempotency_key; use the provider’s supported parameter or header rather than assuming a universal field spelling. Bind it to the tenant, authenticated caller/authority context, operation and business intent; retain a request fingerprint. Same key and same request returns the prior result or a reconcilable state. Same key with different material input is a conflict. A new session must not accidentally duplicate the same financial or booking intent.

Define the retention window with the owning system and business process. A 24-hour example is not a universal rule. Key expiry does not make an uncertain prior attempt safe to repeat: check authoritative state and the durable operation record before issuing a new operation.

Outcomes and safe recovery

Use one outcome reference for booking, payment and delegated work. An outcome can be a rejection, a request for more input, an uncertain result, a partial completion or a safely suppressed duplicate. The labels below are illustrative application examples, not mandatory protocol codes or an executable specification. Map each provider response to its actual meaning before implementation.

Read the three recovery questions independently. Retry means another attempt at the same logical operation, not an instruction to resend identical bytes: credentials, offers or inputs may need correction. Preserve the operation’s duplicate protection according to the provider contract; changed material inputs may require a new request identity. If any consequential write may already have been accepted, establish its authoritative state before another attempt, regardless of the label. Recheck current permission and all approved material terms before any commitment.

Normalize equivalent example spellings such as OFFER_EXPIRED and RATE_LIMITED to offer_expired and rate_limited in application documentation. Preserve the actual provider wire values in the adapter mapping. Temporary upstream failure maps to upstream_unavailable only when the underlying condition is the same; a timeout remains a separate observation of uncertainty.

Replace the ambiguous phrase invalid property with the actual condition: an unresolved property mapping or a known property the caller is not permitted to access. Keep property-resolution and access-denial handling distinct; do not reveal protected resource details contrary to access policy.

For OAuth bearer-token integrations, RFC 6750 distinguishes invalid_token, which includes expired or otherwise invalid tokens, from insufficient_scope. Use the provider’s actual authentication response rather than introducing a universal authorization_expired code.

Payment decline handling and duplicate-result retrieval are provider-specific. For example, a payment provider may permit a retry for some reasons but require another payment method for others, and an idempotency store can return a failed original result. Verify these behaviors for the actual integration.

Exact purchase approval and advance authority are different

An approved checkout and permission to make a future purchase within limits are not interchangeable. The hotel and payment integration need to know which authority they accept and preserve the evidence behind the final decision.

Record when advance authority becomes valid and when it expires, including the time zone. Define how withdrawal or revocation is checked and whether the permission allows one purchase or limited reuse. Missing or unverifiable validity is not permission for indefinite reuse. An expired or exhausted authorization cannot permit a new commitment, but the system must still check the result of an earlier uncertain attempt. The duration and implementation fields belong to the agreed integration policy; this guide does not prescribe a universal time limit or protocol field.

Record the accepted authority policy

Record the hotel company’s acceptance policy before enabling a purchase. Use a separate record when the property, merchant, action or relevant rate plan has different rules. Corporate teams define and maintain the policy; the integration enforces it. The Implementation review sheet provides editable fields for the record below. Recording that a form is accepted does not itself grant permission to transact.

For AP2, the current documentation uses open and closed Checkout Mandates and Payment Mandates. Open mandates carry constraints before finalization; closed mandates bind authorization to a finalized checkout or payment amount. These are distinct checkout and payment records, not merely two names for one consent field.

Earlier AP2 material used Intent Mandate and Cart Mandate. That historical distinction motivates the comparison above, but it is not a field-name migration rule. Pin the actual AP2 version, supported mandate types, verification and merchant acceptance policy before implementation. AP2 is optional payment-authority evidence, not payment execution, settlement or an AIHA requirement.

Other representative workflows

• Guest request to task: read minimal stay context → validate entitlement and department → create one task → obtain acceptance and owner → track completion or escalation. Human handoff does not need A2A.
• Pricing assistant: retrieve consistent demand/rate data → generate a proposal → validate limits and approval → publish through the rate system → verify applied rates → retain rollback evidence.
• Service recovery: identify the issue and authority → propose an allowed remedy → obtain approval for compensation → execute the relevant case/folio actions → verify each state → hand off anything unresolved.
• Content question: retrieve current attributable facts → label uncertainty → answer within the available evidence → use a live operational read for price or availability, and a separate write for any accepted action.

Validate the integration and ask for evidence

Validate the integration and ask for evidence

First test one bounded workflow in a sandbox or controlled pilot. Define success before enabling autonomous changes. Repeat tests when models, prompts, schemas, connectors, policies or vendors change.

Questions to put to a vendor or internal team

• Which concrete capabilities are live for our systems, versions and property scope? Show a real read and a real write, not just a protocol logo.
• Why is an existing secured API insufficient, if you propose MCP? Why does another independent agent need task ownership, if you propose A2A?
• What authenticates the caller, proves property authority, binds the intended guest and limits each action?
• Where are credentials held, who can revoke them, and can a property suspend an unsafe workflow immediately?
• Show what happens after a duplicate submit, changed price, lost response, rejected payment and incomplete booking.
• Can we trace an agent-initiated booking or change, export the evidence, and distinguish request acceptance from final success?
• What happens to attribution, direct-booking economics, commissions, channel terms and data use? Which assumptions have actually been tested?
• What is live now versus a roadmap promise? Who owns maintenance, compatibility tests, incidents and exit/migration?

A practical implementation roadmap

Use this roadmap to plan and test one specific hotel-system integration. Start by checking that the intended client can find or connect to the correct endpoint, then prove it can read the right data. Add booking or other record changes only when needed and tested; add delegation only if an independent agent must take responsibility. Each row describes what that integration should demonstrate before the team relies on it. These stages are not protocol maturity ratings, organizational-readiness scores or the risk tiers used in Workgroup 8 →.

Use only the stages the business actually needs. No stage requires a fixed ARD/MCP/A2A/AP2 stack. Delegation is optional and needs evidence from the actual integration. These stage names are planning aids, not an AIHA conformance scheme.

Self-attestation means the implementer supplies its own evidence-backed statement of tested scope. It is not independent verification, contributor endorsement or AIHA certification. Record the tested capability, systems and versions, date, test method, results and limitations; a stage label alone is not evidence.

Business-outcome evidence is not integration-test evidence

Evaluate two separate questions: does this AI use deliver a useful business result, and does its technical integration work correctly? A reported reduction in staff time may support the business case, but it does not show that a booking API rejects duplicate reservations or handles a lost response safely. Use the catalog grades below to interpret business claims, and retain separate test results for permissions, data accuracy, record changes and recovery.

The 100+ use-case catalog → uses A–D evidence grades to describe submitted business claims. Keep their meaning intact:

No ROI-grade quantified outcome is a separate absence of evidence, not a zero return. These grades describe claims; they do not independently verify returns or certify interoperability. A discovery endpoint test checks correct identity and capability access. A visibility or revenue comparison checks business effects. Both may matter, but one cannot substitute for the other.

Record the source of technical evidence

For each technical claim or test, record its source separately from the assessment result. These labels apply equally to every protocol and connector. They do not replace the business-outcome grades above, rank a protocol’s maturity or establish AIHA certification.

Record the assessment result separately

Record one claim or test per evidence entry: operation and property scope, system/connector/protocol versions, source or assessor and their role, report/test date, method, acceptance criteria, observed result, supporting links or artifacts and limitations. Identify the basis of the assessment in the Evidence source field; if several sources support it, record each separately in the evidence details. Leave that field blank when no source exists. A vendor report can be recorded while the assessment remains Not assessed; after review, evidence may still be incomplete. Reported reservation creation, modification or cancellation does not establish duplicate protection, terms enforcement or safe recovery. Do not mark those checks Passed without their own evidence.

Contributors

People whose substantive inputs shaped this guide

Contributor participation does not imply endorsement of every recommendation or mapping.

External resources

External resources

• [R1] Model Context Protocol specification, 2026-07-28 ↗Official protocol specification
• [R2] MCP authorization ↗Official protocol specification
• [R3] Agent2Agent protocol specification ↗Official protocol specification
• [R4] Agentic Resource Discovery specification ↗Project proposal
• [R5] WebMCP ↗Draft Community Group Report
• [R6] Universal Commerce Protocol ↗Official protocol specification
• [R7] Agentic Commerce Protocol ↗Official developer documentation
• [R8] Agent Payments Protocol ↗Official protocol specification
• [R9] AG-UI overview ↗Official project documentation
• [R10] Open Floor Protocol ↗Official project repository
• [R11] NLWeb reference implementation ↗Official project repository
• [R12] The llms.txt proposal ↗Community proposal
• [R13] AGENTS.md ↗Project documentation
• [R14] EntityMap ↗Community proposal
• [R15] Agent Plugins specification ↗Official project specification
• [R16] OpenAPI specification ↗Official specification
• [R17] OAuth security best current practice, RFC 9700 ↗IETF best current practice
• [R18] OAuth token exchange, RFC 8693 ↗IETF specification
• [R19] OpenID Connect Core ↗Official specification
• [R20] W3C Trace Context ↗W3C Recommendation
• [R21] OpenTelemetry traces ↗Official project documentation
• [R22] Schema.org LodgingBusiness ↗Community vocabulary
• [R23] Schema.org HotelRoom ↗Community vocabulary
• [R24] Schema.org LodgingReservation ↗Community vocabulary
• [R25] AI Hospitality Alliance hotel AI use cases ↗Industry catalog and contributor-supplied evidence
• [R26] Shared AI integration and control layer ↗AIHA implementation guidance
• [R27] AI-ready hospitality data implementation guide ↗AIHA implementation guidance
• [R28] Hotel AI visibility implementation guide ↗AIHA implementation guidance
• [R29] OAuth 2.0 Rich Authorization Requests, RFC 9396 ↗IETF Standards Track specification
• [R30] HTTP Message Signatures, RFC 9421 ↗IETF Standards Track specification
• [R31] AP2 Checkout Mandate ↗Official protocol specification
• [R32] AP2 Payment Mandate ↗Official protocol specification
• [R33] Original AP2 announcement and historical mandate terminology ↗Official historical announcement
• [R34] AI Readiness Guide for Hotels ↗AIHA implementation guidance
• [R35] Hospitality AI Governance Framework risk tiers ↗AIHA governance framework
• [R36] OAuth bearer token errors – RFC 6750 ↗Standard / official guidance
• [R37] Payment decline reasons and next steps ↗Official vendor implementation documentation
• [R38] Idempotent requests and retained results ↗Official vendor implementation documentation