AI Orchestration Framework for Hospitality

Overview

Overview

For hotel estates where more than one AI agent or channel needs hotel data or actions, this guide recommends a shared AI integration and control layer between those agents and the hotel systems of record. The shared layer gives every agent one governed route to current facts and deterministic actions while each PMS, CRS, RMS, CRM, building system and service platform keeps its existing authority.

Scope

• agent-to-system and agent-to-agent routing;
• session, reservation, guest, property, and unit context;
• identity, authorization, consent, and policy enforcement;
• deterministic execution of state-changing actions;
• event handling and cross-system workflow coordination;
• observability, decision lineage, rollback, and human handoff;
• portfolio, property, and multi-vendor deployment patterns.

Operating boundary: the layer governs interactions within hotel-owned or hotel-controlled systems. Third-party OTAs continue to interact with the CRS as they do today; once data reaches hotel-owned systems it is treated as within the hotel-controlled operating boundary, and the layer governs how systems interact from that point forward.

Out of scope

• replacing hotel systems of record;
• third-party OTA distribution channels — out of scope for Phase 1;
• data ownership — introduces legal complexity best handled elsewhere; direct booking does not by itself settle all data rights;
• the data foundation itself — entity definitions, key rules, identity resolution, survivorship and the quality gate are the data-foundation discipline’s; referenced here, not restated;
• selecting a specific cloud, model, orchestration product, or agent vendor;
• unit-level operating and disclosure models for individually managed inventory in Phase 1;
• legal conclusions about channel consent, PCI scope, or distribution access;
• numeric performance targets, until observed data exists (tenancy leakage excepted; its only defensible value is zero).

Metasearch is shown as an external distribution boundary. Whether agentic metasearch transactions belong within the framework’s scope remains unresolved.

What this guide provides

• Capability model and control plane (Control plane) — the required orchestration functions.
• Worked examples — how the systems coordinate, shown as illustrative flows.
• Data plane and topology test (Data plane and topology test) — how the estate’s shape selects the configuration.
• Integration and control-point inventory, and reliability checklist (Integration inventory–7).
• Authorized-agent handshake (Guest and agent authorization) — what constitutes an authorized agent.
• Adopted positions, deployment profiles, and the multi-agent contract (Deployment profiles–11).

Terminology

A joint governance terminology crosswalk remains to be agreed. API gateways, ESBs, event-driven integration, retail order management, telecom ODA, healthcare interface engines and building protocols are useful analogies, not normative authority for hospitality agent behavior. [R7] [R8] [R9] [R10] [R11]

How to follow this guide

Use this guide to decide whether a shared layer is needed, choose the data-plane pattern for your estate, document interfaces and controls, and request evidence from vendors. A separate layer may be unnecessary for a bounded workflow that stays inside one system and one vendor.

Read the high-level quick start →

Metasearch is shown as an external distribution boundary for this release. Whether an emerging agentic metasearch transaction path belongs in the orchestration scope remains unresolved; do not assume an end-to-end distribution standard is supplied here. [R15]

Suggested architecture

Suggested architecture

Why use a shared layer?

Integration arithmetic is the weakest reason. Four agents against five backends is twenty connections; a layer between them makes it nine, and adds one connection per new agent rather than five. The arithmetic is correct and it is the least important of the three.

Consistency is what forces the decision. A guest who asks the same question through web chat and through messaging and gets two different answers is watching the operator’s own information contradict itself, and no prompt engineering inside either agent fixes it, because the disagreement is upstream of both. The same applies to actions: the same authorized intent under matching scope and state should have the same intended effect through either agent, with distinct audit records linked by correlation identifiers.

Substitutability is what pays off over years. If access to the systems of record is mediated by a layer the operator controls, changing a model, adding an agent, or replacing a vendor can be localized to that layer, subject to interface compatibility, policy review and conformance testing. If each agent holds its own credentials and integrations, every such decision reopens a negotiation with every backend, and switching cost — not product quality — is what keeps a vendor in place.

How this interlocks with the platform architecture

The shared layer defines who may act, under whose authority, in what order and with what evidence. A platform architecture defines runtime isolation, storage, scaling and observability. Central, regional and property-local runtime cells are compatible with this guide when they implement the same scope, retrieval, permission, precedence and audit contract.

Several contributions converge on a shared control contract and deterministic execution, but the production examples and adjacent platform material are not three independent validations of the whole framework. The architecture remains a blueprint that must be tested in each estate.

Control plane

Control plane

The control plane is where the AI-aware work happens, so that the PMS, CRS, RMS, CRM, and the rest of the stack keep doing what they already do, exposed through interfaces rather than rebuilt. It is described as five components an implementer can build, nine request-path capabilities those components hold, and a tenth event-handling capability on a separate asynchronous axis. The component view says what to build; the capability view says what each build must be responsible for.

Control plane components

Control plane component capabilities

The capability map is retained as the statement of responsibilities. Nine request-path capabilities are held by the five components; event handling is the tenth capability and runs on a separate asynchronous path (Control plane). Integration boundaries is one of the nine request-path capabilities, but it is a cross-cutting constraint rather than a standalone component.

Integration boundaries is one of the nine request-path capabilities. It is not a standalone component; it is a cross-cutting constraint on the knowledge gateway and tool orchestrator, which call systems of record without absorbing their authority.

The event path (event handling)

The five components above are request-driven: an agent asks, the layer decides, a tool executes. Event handling — the tenth capability — is the asynchronous axis, and it has no home among request-driven components. Yet it is load-bearing: Worked examples, the check-in fan-out, is the framework’s lead flow, and it is an event fan-out, not a request. The layer must therefore carry a distinct event path: state changes emitted by systems of record are published and fanned out to consumers (agents, workflows, downstream systems) without the emitting system knowing about any of them.

Minimum event-path requirements: at-least-once delivery with a deduplication key; per-resource ordering; versioned schemas; a stated replay window and backfill behavior; a correlation identifier on every event (an event that arrives without one terminates the audit trail at the vendor boundary); and operator-visible delivery failure. The event schema itself is the one genuinely open piece and is coordinated with the Agentic Protocols workstream; the envelope and the delivery semantics are separable from it and are stated here.

Three cross-cutting concerns

These are not components. They must be true at every hop, which is a different kind of requirement, and stating them separately keeps them from being delegated to one box and forgotten.

• Tenancy and entitlement. Every request carries the property and organization it concerns, and every retrieval and tool call is checked against what the caller is entitled to for that scope. Checking once at the front door is not sufficient. This is the one requirement with a single acceptable value: a record must never reach a property, guest or agent context that is not entitled to it; explicitly authorized corporate or cross-property workflows remain possible.
• One answer per question. A property of the layer, not of any agent, and a testable one: the same question, posed through applicable channels under matching property, guest, entitlement and freshness context, returns consistent authoritative facts, and someone runs that test on a cadence.
• Observability and evaluation. What the gateway returned, which facts it drew on, which tool ran, and whether the answer was right — without which the layer cannot be improved or defended.

Declared registers

The five components are processing. They are not the whole control plane, because each of them tests a decision against declared state that lives outside the request. That state is what an auditor asks to see, and it is the part most architectures leave implicit. Six registers, and the test for each is the same: can you produce it, and does the layer actually enforce what it says.

Precedence and concurrency control are different mechanisms, and an architecture needs both. A lock decides who was faster. Precedence decides who is authoritative. Concurrency control stops two writes colliding; precedence decides which of two entitled actors should have been writing in the first place. An architecture with resource versions and locks but no declared precedence resolves genuine policy conflicts by timing, which is to say arbitrarily, and the outcome is not reproducible or defensible after the fact. Two agents may each be individually permitted to modify the same reservation. That is not a defect in either permission. It is the case precedence exists for.

Why commercial constraints are a register of their own

The other registers answer whether an actor is permitted and whether now is a permitted moment. Neither asks whether the change itself is permissible under what the operator has signed. A rate write can come from a correctly registered agent, win precedence cleanly, fall outside every blackout window, and still breach a parity undertaking or a brand standard. Nothing upstream would catch it, because nothing upstream is looking at the terms.

It is deliberately not folded into action precedence, and the reason is ownership rather than tidiness. Precedence is owned by whoever operates the platform. Parity undertakings, franchise standards and distribution terms are owned by commercial and franchising, and they change on a contractual cycle that has nothing to do with a release. A register with two owners is a register nobody maintains, and an unmaintained constraint register is worse than none, because the layer will report that it checked.

Multi-agent safeguards and trust boundaries

Multi-agent safeguards and trust boundaries

These three reference patterns combine engineering recommendations with reported production experience. Each brings together several capabilities. Independent validation across multiple vendors is not claimed.

Guarded write

The model proposes intent; no write to a system of record occurs unless it was authorized, validated, attributable, and repeatable — and the decision to permit it was not made by the model. The property, not one implementation, is what matters: either no credential reachable from the model’s context can write, or every write is executed by a deterministic component that validates it server-side against rate, occupancy and restriction rules and refuses on its own authority. A scoped, server-validated write API with an authenticated per-agent principal satisfies this as fully as a design where the model reaches no write path at all. A write whose only gate is model output is the failure.

Guarded conversion (the booking-specific instance)

The agent reads availability and price and agrees the stay, then hands off a pre-filled deep link into the booking engine (or an equivalent guarded surface). Deterministic code creates the reservation and runs the guarantee cycle. Because inventory can sell between agreement and submission, the quote is non-binding by construction: the write surface revalidates availability, price and cancellation terms at submission, and a defined fallback — a short TTL hold, or a graceful re-quote — applies when revalidation fails. On a multi-room link, revalidation runs per room and partial availability resolves to a stated policy (all-or-nothing, or re-composition). The payload of this handoff is specified in the Booking deep-link proposal below.

Booking deep-link proposal

The reusable proposal contains twelve design rules, fifteen example payloads and a validating lint. It covers multi-room composition and occupancy/ages, split-stay dates, entitlement references, preferred server-issued quote references, submission-time revalidation and distinguishable outcome events. Namespace and protocol version are placeholders. It is not an adopted interoperability standard.

Guarded disclosure and untrusted input

What enters the model’s context window is itself a permission decision. Deterministic code selects the information tier before generation — general knowledge for any guest versus content released only after verification — so content the model was never given cannot be extracted by prompt injection, persuasion, or model error. An unverified session never contains verification-gated access instructions, payment details, or another reservation’s data.

Guarded disclosure controls which information enters context. Untrusted-input fencing is the complementary control for guest messages, free-text records and other third-party material that must be processed. The proposed control and tests below address this gap; ownership and implementation evidence remain outstanding.

One owner per guest thread, and default posture

At any moment, one agent or human role owns a guest thread; ownership transfer is an explicit, auditable event. The default posture for reads, disclosure, and non-write tool calls is deny-by-default with explicit, tiered grants: an operator should be able to answer "what can an agent see or do without approval?" with "nothing that has not been granted." The framework retains guarded write, guarded conversion, and guarded disclosure as its operating vocabulary; maintain a short cross-reference to the operator’s governance vocabulary.

The capabilities under multiple agents

The layer’s distinctive work begins where one property, or a group across properties, runs several agents from different vendors against the same systems of record at once. None of the nine request-path capabilities changes in kind; each acquires a second obligation no single vendor can discharge alone: routing becomes arbitration and conversation-level handoff; context management becomes shared-context ownership; identity becomes an agent registry and attestation; permissions become precedence; observability becomes a unified, per-agent-attributable audit; failure handling becomes a halt-or-defer decision across concurrent workflows. The idempotency keys and optimistic locking already required in Reliability and assurance are the right primitives; what changes is that they must hold across parties who share no runtime and no incentive to coordinate.

Untrusted input is data, never instruction

Proposed control: guest messages, reviews, PMS free-text fields and other third-party text carry no authority. Tag their origin, delimit them from operator- and vendor-authored content, and fence them before the knowledge gateway and model. Content cannot change the authenticated principal, promote a disclosure tier, select or authorize a tool.

Provenance and delimiting are necessary controls, not proof that prompt injection is solved. Deterministic authorization must remain independent of the model. Test both an injected instruction that must not execute and the same authorized principal instruction that must execute. UI-1, UI-2 and UI-3 in the self-assessment cover this proposed inclusion control; implementation evidence and a named engineering/governance owner remain outstanding.

A partner agent is outside the operator’s initial trust boundary. Authenticate it and verify registry membership, delegated authority and request scope before it can retrieve information or propose actions. A label on an architecture diagram is not a trust grant.

Protocol boundaries can use MCP for tools and A2A for agent interaction; neither protocol replaces the operator’s authorization policy. [R1] [R2] Input-fencing and least-privilege controls should be reviewed against current prompt-injection guidance. [R6]

Interchangeable services

Interchangeable services

The five components decide. They do not themselves hold the models, the indexed content or the credentials. Those sit in a services band beneath the plane, and the reason to draw them separately is substitutability: every item in that band should be replaceable without touching anything above it. An operator who cannot swap a model provider without reopening each agent has not built this layer, whatever the diagram says.

Legacy adapters belong in the band, not outside it

A simplified diagram can imply that each backend offers an API worth calling. In a real estate several will not. Access may be a nightly file, a scheduled extract, a screen-scraped interface, an on-premise system reachable only from inside the property network, or a vendor interface that exists but is not licensed to the operator.

The adapter for such a backend is a component with its own reliability profile, not a detail of the tool that calls it. It has a staleness budget rather than a latency figure, it usually cannot accept a write at all, and it fails in ways an API does not: a file that did not arrive looks identical to a file with nothing in it. Naming it in the services band puts that profile where a reviewer will see it. Leaving it out produces a diagram that only describes the systems that were easy.

Action path and deterministic execution

Action path and deterministic execution

The shared layer must keep planning and execution separate. Orchestration discovers and sequences permitted work; deterministic execution services hold the least-privilege credentials and perform the specific backend operation.

Orchestration and execution

Orchestration and execution are used interchangeably in most material and name genuinely different jobs with different security properties. Model Context Protocol standardizes a boundary — how a system advertises tools and how a caller invokes them — but it is a protocol, not an architecture: it does not decide where the boundary sits, and it does not make the data behind it trustworthy.

• Execution is the system side. A server that holds credentials for one backend and performs work against it — one PMS API, one maintenance-platform API — knowing that system deeply, including what it permits and rejects.
• Orchestration is the layer side. The component that discovers which tools exist, chooses which tool or sequence satisfies the intent, checks that this agent in this scope is permitted it, sequences the steps, handles failure, and assembles the result.

Why the split matters: the credential boundary belongs at execution — each server holds least-privilege access to one backend, so a compromise is contained to one system. The policy boundary belongs at orchestration — what an agent may do, in whose name, with what audit record. Collapsing the two puts backend credentials directly behind a general-purpose planner, so the blast radius of a prompt injection or reasoning error is every system the planner can reach. One condition is easy to skip: a tool is only as good as what sits behind it — execution servers must point at the authoritative source for the fact they return, which in a mixed estate often means the resolved foundation of Data plane and topology test rather than any single source system.

Guarded write path

Reads and writes are not symmetrical, and a layer that treats them the same will eventually let a model change a system of record on the strength of its own reasoning. The rule that prevents it is short enough to hold in one sentence: models propose, deterministic code acts, and no agent writes directly to a system of record.

What follows is the path a write takes, with the gates named in the order they are checked. Each gate tests the request against one of the registers in Control plane.

The night-audit boundary

One blackout window is specific to this industry and belongs in any hospitality deliverable that claims to be complete. During the night audit, financial writes must be refused and queued until the window closes, and staff have to be told that something is pending rather than left to discover it. Every hotelier knows the constraint. No general-purpose agent framework knows it, which is exactly why it has to be written down here rather than assumed: a layer assembled from a generic reference architecture will attempt a folio posting at three in the morning and either fail in a way nobody notices or succeed in a way the audit cannot reconcile.

Operational mode is the general case

The night audit is one condition among several, and it is worth naming the general form rather than only the instance. A property in a declared condition behaves differently: during a rate-parity event some price writes should refuse, during a renovation some inventory is not sellable however the system reports it, and at peak occupancy the layer may need to shed non-essential work rather than queue it. Each of these is the same shape of rule as the night audit, which is why the register in Control plane is operational mode rather than a list of blackout windows. Blackout windows are the subset of operational mode that refuses and queues writes.

The practical requirement is that mode is declared rather than inferred. A layer that guesses at the condition of a property from traffic patterns will be wrong during exactly the periods that matter most, and it will be wrong differently at each property.

Tokenization boundary

One boundary in the write path is not a policy decision the group gets to make, because it is set outside the group. Cardholder data has a compliance perimeter, and an AI layer is very good at moving data across perimeters without anyone deciding to. Retrieval copies facts into an index. Context assembly copies them into a prompt. A model provider may retain a prompt. None of those steps is visible as a data transfer in an architecture diagram, and all three would put an operator outside scope.

The platform reference architecture in Overview draws this boundary in its integration layer, which is the right place from the platform side. It is drawn here as well because the risk this document is concerned with runs the other way: the boundary is breached from the retrieval side, not from the payment side, and a diagram that shows it only at the payment gateway invites exactly that mistake.

Keep raw cardholder data and sensitive authentication data out of retrieval indexes, caches, prompts, conversation logs and agent context. Payment capture and charge-capable credentials stay with the authorized payment surface or gateway. The agent receives a non-sensitive reference and outcome, not a token it can independently use to charge.

Tokenization is an architectural boundary, not a blanket claim of PCI compliance or de-scoping. Search and inspect the retrieval index, logs and prompt store for prohibited data, validate suspicious matches, and obtain the operator’s qualified compliance assessment. A card-number-shaped text scan alone is not sufficient assurance. [R5]

Governance is a component and a responsibility at every hop

The governance component implements identity, scope and audit records. Enforcement still happens at every retrieval and action boundary; authenticating once at the entrance does not authorize the rest of a conversation.

A dispatcher and a crew

Orchestration is the dispatcher: it selects and orders permitted work. Execution is the crew: it performs a specific operation against one backend. A tool must read the authoritative source, or a governed resolved foundation built from authoritative sources, not a convenient copy that merely looks authoritative.

Choose the data-plane pattern

Choose the data-plane pattern

This is the part that cannot be published as one universal picture; pretending otherwise is how a reference architecture gets adopted by an estate it does not fit. Two configurations cover most of the industry, and a third case is a signal to stop rather than a configuration. The control-plane responsibilities above them are the same; only the path from a source system to a trustworthy answer differs.

Pattern A — normalize and pass through

One product per function across the portfolio simplifies schema mapping, but uniform products alone do not establish identical configuration, source authority or freshness. Pattern A maps source data onto one hospitality model in flight, may cache briefly for read latency, and exposes scoped reads and guarded writes. It has no persistent resolved data foundation; any cache still needs explicit expiry, invalidation and freshness rules. Select it only when cross-system reconciliation is unnecessary and the authoritative sources are sufficiently fresh. A heterogeneous estate or batch-only source may require Pattern B. Standardization supports this pattern but does not replace the topology and freshness tests.

Pattern B — normalize, resolve and persist

Products differ by property, brand or region; data arrives in different shapes and cadences, with code sets that disagree and records that are not clean on arrival. Normalizing in flight makes shapes match but does not make two records refer to the same person, and does not let you report across properties, because you cannot reconcile what you have not landed. So the data plane gains layers — landed (source payloads exactly as received, with arrival time and a durable reference, nothing discarded), conformed (one canonical shape per entity, history preserved), resolved (deterministic identity matching on declared rules, survivorship precedence per attribute, ambiguous matches held for review), and a foundation of one current row per entity key that has passed a quality gate. The control plane reads the foundation, not the raw sources.

A data lake belongs in this design, and it belongs here as an optional, recommended element for complex estates — many already consolidate PMS/CRS/RMS/CRM data this way and would want their AI framework reading the same structure. It is a consolidated read/analytics plane, not a new system of record: the systems of record stay authoritative, and writes still go through guarded write. The entity set, key rules, resolution and quality gate are the data-foundation discipline’s to define; this framework references that work and states only how agents reach the result.

Pattern C — when orchestration is not the constraint

Sometimes the problem is not integration, retrieval or routing: the record does not exist, was never captured, or cannot be attributed — no property identifier, a guest whose identity was never captured, policies that live in people’s heads. Building an orchestration layer on that produces a fast, well-governed, fully audited path to answers nobody should act on. The honest recommendation is to name the gap and fix it first, and a published reference architecture should say so plainly.

The topology test

Four questions an operator can answer without a workshop, to place themselves in ten minutes:

Question 2 moves the most operators and catches those who answered 1 confidently: a uniform stack removes the shape problem but does not resolve a guest who appears in the PMS, the dining system and the loyalty system with three identifiers and no agreed precedence. Uniformity and resolution are different problems.

One control plane, several data services

The call debated whether one orchestration layer is enough or several are needed; both positions were right about different things. One control plane — do not build a second, because two request routers, two knowledge gateways and two authorization models produce two answers and two audit trails, the exact failure the layer exists to prevent. Several data services beneath it — expect them, because availability, guest identity, financial performance, operational tasks and content have different shapes, cadences and correctness criteria (freshness, resolution, stability, delivery, provenance), and forcing them into one service produces the all-encompassing layer nobody can change. The guardrail: the control plane owns routing, policy and audit and nothing else; business logic belongs to a data service or the consuming application.

Reuse an existing data lake or lakehouse

Where an enterprise data lake already exists

Pattern B describes four layers by what they do, not by what they are bought as, and a reader with an existing data lake or lakehouse should recognize the first two immediately. Landed is what their raw zone already holds. Conformed is what their curated zone already holds. Where that estate exists, the AI foundation belongs inside it rather than beside it. A second copy of guest data, with its own resolution logic and its own refresh cadence, is precisely the inconsistency this layer exists to prevent, so building alongside an existing lake contradicts the position in Positions and tests on one answer per question.

So the recommendation is to reuse it. Two things have to be said alongside that, though, because the phrase "the data is already there" is true of the first two layers and usually false of the next two.

• A lake gives you landing and conforming. It rarely gives you resolution. Most hotel data lakes were built for reporting. They land source data and conform it for dashboards, which tolerates a duplicate guest in a way that an agent about to act on that guest does not. Deterministic identity matching on declared rules, survivorship precedence per attribute, and a quality gate that blocks promotion are the three things a BI-oriented lake most often lacks, and they are exactly what data-foundation guidance specifies. Reusing the lake is right. Assuming it is already AI-ready is the trap.
• Analytical storage and serving latency are different problems. A lake tuned for batch loads and columnar scans will not answer a guest-facing agent inside a few hundred milliseconds. Treat the lake as the system of derivation, where the foundation is built and governed, and keep a serving path in front of it. That is a deployment question rather than an architectural one, but a diagram that omits it invites an operator to point an agent at a warehouse and conclude the pattern does not work.

Legacy access changes the answer

An authoritative source reachable only through a nightly file, scheduled extract, licensed user interface or property-local adapter cannot automatically satisfy a real-time workflow. Where a governed conformed copy is necessary, use Pattern B for the affected entities and state its staleness budget. Reuse existing governed storage where suitable; do not create a competing system of record.

Different data services, one logical control contract

The reason several data services are unavoidable is concrete rather than architectural taste. What each one has to be correct about is different:

A pass-through pattern still uses a bounded cache with an expiry and freshness rule. “No persistent foundation” does not mean no stored bytes, no cache invalidation or no synchronization work.

Analytical storage and a low-latency serving path are different responsibilities. Reuse an existing lake for landing and conforming where appropriate, but verify identity resolution, survivorship, quality gates and serving latency rather than assuming a reporting lake is already suitable for operational AI.

Inventory systems and permissions

Inventory systems and permissions

Minimum system interfaces

Every connected system should provide: documented, versioned APIs; scoped credentials below administrator level; structured, specific errors; idempotency or safe duplicate handling for writes; auditability and stable resource identifiers; and a documented integration and exit path. Where state can change, event support is required — and not merely "a webhook exists" but stated delivery guarantees:

• at-least-once delivery with a deduplication key;
• per-resource ordering;
• a correlation identifier on every event;
• versioned event schemas;
• a stated replay window and backfill behavior;
• operator-visible delivery failure.

These realize the event path (Control plane); the check-in fan-out (Worked examples) is not operable without them.

Systems of record and coordinated systems

Agent-facing surfaces (for guest-facing agents)

A system can meet the baseline in full and still be unable to support a conversational agent. These surfaces are the additional requirements; Evaluate readiness restates them as a self-assessment.

Open agent access to operational knowledge

A store readable only by its own vendor’s native agent limits substitution. The adopted operational-knowledge requirement covers the existence of a documented, scoped, versioned and permissioned interface; broader cross-vendor access for operator-authorized agents remains proposed, as described below.

Agent Plugins as a packaging input

Where the layer supports Agent Plugins, it should treat the Agent Plugins Working Draft as a portable packaging input for Agent Skills and MCP configuration — not an authorization or sandboxing standard. The loader validates manifests against the pinned spec version before discovery; enforces plugin-root path containment; isolates failures so one invalid component does not disable others; supports only approved MCP transports; keeps credentials out of packages, with authorization and secret injection owned by the orchestration client; records plugin identity, version, publisher, configuration, approval and revocation in the unified audit; and requires separate process, network, tenant and resource isolation, because path containment does not sandbox a subprocess.

The adopted requirement is a documented, scoped, versioned and permissioned operational-knowledge interface. A broader rule allowing any operator-authorized agent to read that knowledge across vendors is not yet adopted. The proposed direction is SHOULD now and MUST in Phase 2; vendor feasibility and final requirement wording still need confirmation.

Do not interpret “open” as public or unauthenticated. Every retrieval remains deny-by-default and subject to the operator’s explicit grants.

When event schemas are defined, evaluate existing hospitality vocabularies before creating an extension, and document the resulting compatibility decision. [R3] [R4]

Read the complete workbook instructions and code legend →

Read event requirements, envelope, tiers and seven tests →

Plan reliability and assurance

Plan reliability and assurance

What must be true for AI-assisted workflows to fail safely rather than silently. Each workflow needs a correlation ID, an idempotency strategy, an authoritative receipt, a timeout budget, an owner, a recovery path, and a measurable success signal — or an explicit statement that none is available.

No observed cross-segment performance thresholds are supplied. Establish workload-specific freshness, latency, recovery and retention targets with evidence; zero unauthorized cross-tenant disclosure is the security objective, not a claim that a pilot has demonstrated it.

Use the event-delivery checklist →

Set guest and agent authorization

Set guest and agent authorization

This framework defines what an authorized agent must establish; interoperable protocol mechanics remain separate. The guest-verification pattern below covers a human guest, a property and an agent acting for that property. It does not settle autonomous agent-to-agent authentication.

The bar is a human at the front desk, and should not be raised

An agent acting for a property, talking to a guest, should authorize the guest the way a competent front-desk agent does on a phone call — not less, and deliberately not more. A front-desk agent does not ask for a passport number; they ask for a name and arrival date, find the reservation, and check that what the caller says lines up. Asking for a document number is worse practice, not better: it collects an identifier the property should not hold for this purpose, it cannot be verified over the phone so it raises the appearance of assurance without the substance, and it trains guests to recite identity documents to whoever asks — the behavior every phishing campaign depends on. This is the same reasoning that already keeps card numbers out of the channel; the framework should state it for identity data too.

Three steps, in order

• Bind. The conversation is bound to a reservation using facts a legitimate guest already has — name and arrival date, or a reservation reference. This is a lookup, not an authentication event.
• Confirm. The channel identifier the guest is reaching us on must match the one on the reservation. On messaging platforms the identifier is platform-verified and the match is meaningful; on voice the displayed number is a hint, so releasing anything gated requires one further confirming fact or sending the release to the number on record.
• Gate. Release depends on the reservation being in a state where a guest legitimately holds the thing released — active booking, arrival day reached, and whatever settlement or online check-in the property requires.

Keep the light gate restricted

The agent in this restricted pattern cannot cancel, modify, move or refund a booking, change contact details, or create a charge. A mistaken disclosure or access release can still cause serious harm; rotating an access credential does not undo every consequence. Use the light gate only for the non-modifying pattern described here, with delivery to the channel of record and staff suppression. Do not reuse it for cancellation, refund, contact changes or other writes. Those workflows require stronger action-specific authentication, explicit authorization and independent deterministic execution.

Deliver on the day, do not recite on request

The front desk’s real control was never the questions; it was that the guest is standing there. The remote replacement is delivery rather than recitation: the access credential is sent by the access flow, on arrival day, to the channel of record — not read out on request to whoever passed the gate. Three operational requirements follow: never resolve ambiguity by choosing (two matches is not a match — ask one more fact or hand to a human); watch successful binds from a new channel identifier, not only failed lookups, because an attacker working from a real attendee list produces successful lookups; and carry a per-reservation staff suppression flag the agent can honor but cannot clear.

Deliver access credentials through the access workflow to the channel of record on the appropriate arrival day. Do not recite credentials to an arbitrary remote caller. A staff suppression flag cannot be cleared by the agent.

This guest pattern does not solve autonomous agent-to-agent authorization. Registry identity, attestation and delegated scopes are a separate requirement. A universal registry or cross-operator trust mechanism is not supplied as a settled protocol.

Plugin packaging and commerce interfaces are adjacent specifications, not authority grants or a hospitality conformance standard. [R12] [R13] [R14]

Deployment profiles

Deployment profiles

The capability model is topology-independent (Data plane and topology test). The framework specifies outcomes and control boundaries rather than one topology. Self-built: the operator runs routing, policy, identity, telemetry and incident response, maintaining connector contracts, key rotation, runbooks and on-call. Vendor-sourced: the same outcomes remain required, and procurement must obtain evidence for tenant isolation, credential custody, exportable audit, version and incident notice, subcontractors, portability, exit, and hotel-controlled acceptance tests. Enterprise: a portfolio registry, federated identity, shared observability, centralized mandatory controls and property-scoped configuration — with central policy never erasing property-specific capacity and escalation truth. SMB and independent: managed orchestration, a narrow allowlist, one or two bounded workflows, and a clear manual fallback, starting read-only. Corporate owns platform selection, standards, identity, mandatory policy, data classification, payment rules and retention; the property owns current operational facts, capacity constraints, local escalation and the ability to suspend a workflow. Property overrides may tighten but not weaken mandatory security or privacy controls.

Choose physical placement from residency, latency, failure isolation and operations needs. A property-edge runtime is an option, not a universal requirement. Declare what continues, refuses or queues during disconnection and how conflicting state is reconciled on recovery.

Multi-agent coordination

Multi-agent coordination

Defined at the obligation level; detailed cross-vendor schemas are deferred to Phase 2. The first implementation artifact should be the agent registry and attestation model, because precedence, concurrency, shared context and unified audit all depend on knowing which agent is acting, for whom, under which scope and version. The layer — not any one vendor — owns: an agent registry (identity, owner, purpose, capabilities, versions, scopes); precedence rules for conflicting authorized actions; resource locks/idempotency across vendors; shared-context rules and redaction at handoff; a unified audit sequence; halt/defer/continue/compensate decisions after partial failure; and capability exposure to the current channel owner. Within-vendor hierarchy is useful evidence but not proof of cross-vendor interoperability.

The layer maintains an agent registry and attestation model recording identity, owning vendor or operator, authenticated principal, purpose, capabilities, versions and granted scopes. No agent acts unregistered. Attestation makes identity and authority verifiable rather than asserted.

The operational obligation applies whenever several agents share systems, including day one of such a deployment. The interoperable registry/attestation implementation artifact is first in Phase 2. Those are different timelines, not competing requirements. Universal alliance-level versus closed operator-controlled registries remains an open design choice.

Action precedence determines who is authoritative. Locks, idempotency keys and resource versions address concurrency and replay; they do not decide policy precedence.

Positions and tests

Positions and tests

The positions below pair plain-language definitions with a test for each. The first six are adopted; the remainder are proposed for adoption, stated as proposed extensions.

Additional proposed controls

Worked examples

Worked examples

Walk the check-in fan-out, room upgrade, voice booking and verification-gated access examples with the operator and integration partners. For each, record the system owner, interface, permission gate, halt/defer behavior, compensation, evidence and human fallback.

Open all four worked examples →

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.

Evaluate readiness and vendors

Evaluate readiness and vendors

Two instruments for operators assessing whether a system can sit under this layer. The first is the baseline integration and event requirements, restated in procurement terms. The second is a self-assessment for the guarded patterns.

Guarded-pattern self-assessment (companion)

The self-assessment covers guarded conversion, guarded disclosure, and interface fidelity — 30 items in two levels, each with a procedure, what counts as demonstrated, and the evidence to keep. It is explicitly a self-assessment an operator or vendor runs on itself, not a pass/fail verdict on a vendor: outcomes are demonstrated / not demonstrated / not applicable, capability-absent is recorded separately from harness-unavailable, and results are not comparable between vendors. It ships as a companion, not inside this document.

Baseline — any system

A documented, versioned API (read at minimum, write where guests or staff need the system to act); an event or webhook mechanism with the delivery guarantees of Integration inventory; scoped permissions below administrator; structured, specific error responses; and a willingness to be logged. Guest-facing conversational agents additionally need an availability and pricing read that returns inventory counts (not a yes/no flag), card-capture/payment-link issuance via API, submission-time revalidation, agent-scoped internal fields, a reservation-matching lookup on practical keys, a content read API with an enrichment layer, and a documented integration path whose commercial terms are disclosed and evaluable before commitment.

The procurement companion supplies 14 operator-side questions covering need, stack readiness, operating ownership and vendor commitments. It does not fill the remaining quality-evaluation gap: answer quality, escalation judgment, language coverage and cost per resolution still need an agreed method, owner and evidence.

Run the 30-item guarded-pattern self-assessment →

Use the 14 operator-side procurement questions →

Contributors

People whose substantive inputs shaped this guide.

External resources

External resources

• [R1] Model Context Protocol specification ↗Official specification

  Accessed September 8, 2026. Tool and resource protocol; not an authorization policy.

• [R2] Agent2Agent protocol ↗Official specification

  Accessed September 8, 2026. Agent communication; does not grant authority.

• [R3] OpenTravel Alliance ↗Standards organization

  Linked September 8, 2026; access could not be verified. Candidate vocabulary reference, not a selected event schema.

• [R4] Hospitality Technology Next Generation ↗Standards organization

  Accessed September 8, 2026. Hospitality specifications and industry coordination.

• [R5] PCI Security Standards Council document library ↗Official standards and guidance

  Accessed September 8, 2026. Qualified assessment is required for implementation-specific compliance conclusions.

• [R6] OWASP: Prompt injection ↗Security community guidance

  Accessed September 8, 2026. Untrusted content and least-privilege mitigations; not a guarantee of prevention.

• [R7] TM Forum Open Digital Architecture ↗Industry standards perspective

  Accessed September 8, 2026. Adjacent telecom architecture analogy, not a hospitality requirement.

• [R8] HL7 FHIR ↗Official specification

  Accessed September 8, 2026. Healthcare interoperability analogy only.

• [R9] Matter ↗Standards organization

  Accessed September 8, 2026. Connected-device interoperability analogy only.

• [R10] BACnet Committee ↗Official standards body

  Accessed September 8, 2026. Building automation and control-network analogy only.

• [R11] KNX: What is KNX? ↗Standards organization

  Accessed September 8, 2026. Building-control interoperability analogy only.

• [R12] Agent Plugins specification repository ↗Official specification repository

  Accessed September 8, 2026. Packaging reference; not a sandbox or authorization standard. Pin and verify the supported version before use.

• [R13] Agentic commerce documentation ↗Vendor documentation

  Accessed September 8, 2026. Adjacent commerce protocol reference, not an adopted hospitality protocol.

• [R14] Universal Commerce Protocol overview ↗Protocol specification

  Accessed September 8, 2026. Adjacent commerce reference; compatibility is not claimed.

• [R15] Mapping the AI-driven hotel distribution ecosystem ↗Industry perspective

  Accessed September 8, 2026. A public demand–orchestration–supply map; this guide expands the property-side coordination layer.