AI agents in the Activity Travel Protocol — how they work

The phrase "AI agent" is used loosely in travel technology discussions. It describes everything from a chatbot that answers FAQ questions to a system that autonomously assembles and books a multi-supplier itinerary. These are not the same thing. The gap between them — in terms of what the AI is actually doing, what authority it holds, and what happens when it gets something wrong — is significant.

The Activity Travel Protocol gives AI agents a precise definition: what they can do, how they identify themselves, what constrains them, and how they interact with the humans they act on behalf of. This post explains the architecture.

When a person books a hotel room through a website, the system knows exactly who is taking the action. The user is authenticated. Their permissions within the system are clear. If they do something unexpected, there is a person who can be contacted.

When an AI agent books a hotel room on behalf of a person, none of those properties hold automatically. The agent is not a person. It may be one of many instances running simultaneously. Its "authority" to act — the scope of what it is permitted to do on the traveller's behalf — is typically implicit, defined by whatever prompt the developer wrote and whatever API keys were configured.

For low-stakes actions, this is manageable. For a multi-supplier travel booking involving payment, supplier commitments, regulatory compliance, and traveller welfare, it is not. An AI agent that can make booking commitments without a machine-verifiable authority scope is, from the perspective of every other party in the booking, an unidentified actor making claims about permissions it may or may not actually hold.

Most current approaches to AI agent access in travel systems use one of two patterns.

The first is API key delegation: the AI agent is given the same API key as the user or application. It has whatever permissions the key has, with no further constraint. There is no machine-readable record of what the agent was permitted to do versus what the application can do. If the agent takes an action that causes a problem, the only audit trail is application logs.

The second is operator-side restriction: the system exposes a limited API surface to the AI agent — read-only endpoints, no write access, no booking state changes. This is safe but makes it impossible to build anything more than a discovery or recommendation tool. The agent cannot actually do the booking; a human has to switch systems and complete it.

Neither pattern supports a fully capable, governed AI travel agent.

The Activity Travel Protocol defines AI agent participation as a first-class architectural concern. Every aspect of how an agent identifies itself, what it can do, and how it is constrained is specified in the protocol.

Identity: the ATP Mandate JWT.

Every AI agent session begins with the issuance of an ATP Mandate JWT — a cryptographically signed token (Ed25519/EdDSA) that declares the agent's identity and permitted authority scope. The mandate is co-issued with the OAuth 2.1 access token at session initialisation. It carries a Cedar policy set that defines exactly which actions the agent can take, on which Booking Object, and under what conditions.

Cedar is an open-source policy language — developed by AWS and used in Amazon Verified Permissions — that expresses authorization rules in a form that is both human-readable and machine-analyzable. A Cedar policy in an ATP mandate might say: "this agent may call atp_invoke_hem, but only on Booking Object 019x-..., and only for the escalation mechanism identified as HEM-12." The granularity is deliberate — an agent cannot use a mandate granted for one situation to authorise a different action.

The mandate is not a capability claim — it is a verifiable cryptographic assertion. The Security Kernel verifies the Ed25519 signature on every action. A forged or altered mandate is rejected.

Scope: eight authority scopes.

Agent permissions are expressed as Cedar action namespaces — eight defined scopes that cover the full range of protocol operations: reading booking context, sending notifications, writing pre-arrangement data, invoking the Human Escalation Manager, recording safety checks, searching the activity catalogue, managing booking lifecycle, and accessing disruption review state.

No agent receives all scopes. A Guest Agent communicating with travellers via WhatsApp needs read access, notification access, pre-arrangement write, and restricted HEM invocation. It does not need safety check recording or disruption management. The mandate carries only what is needed.

The narrowing property: sub-agent delegation.

When an AI agent delegates to a sub-agent, it issues a sub-mandate. The narrowing property is a Security Kernel enforcement rule: a sub-mandate must be a provable subset of the issuing agent's own mandate. An agent cannot delegate authority it does not hold. The delegation chain — from the root mandate issued at operator level to the leaf sub-agents working on specific booking tasks — is cryptographically verifiable at every link.

The Windley Loop: planning within scope.

Before an ATP agent plans any tool call sequence, it performs a mandatory step called the Windley Loop: a query against its own mandate that asks not "can I do this specific thing?" but "what can I do?"

The concept originates in the work of Phil Windley on dynamic authorization (windley.com), who articulated that agents don't just perform isolated actions — they execute plans, and the safety of each step depends on what has already happened. The pattern was developed into a concrete agent architecture by Clawdrey Hepburn and Sarah Cecchetti (clawdrey.com), who built it on Cedar's partial evaluation feature to give agents a map of their permitted action space before they plan.

Cedar's partial evaluation works like this: instead of asking "am I allowed to take action X?" (a yes/no gate), the agent asks "given my mandate and the current Booking Object state, what is the complete set of actions I am permitted to take?" Cedar returns a residual policy set — not a simple yes/no, but a structured map of what is allowed and under what conditions. The agent uses this map to plan its actions before making any tool calls.

The practical result: an agent with the Windley Loop never generates a tool call it cannot execute. It knows its permitted terrain before it starts walking. If a required action falls outside the map, it handles the gap explicitly — requesting exactly the additional authority it needs from its parent, rather than crashing into a 403 error. This "ask precisely for what you need" pattern is what makes mandate gaps actionable rather than opaque.

After each tool call that may have changed the Booking Object state, the agent re-queries — because the permitted action space changes as the booking moves through its lifecycle. An action permitted in PRE_JOURNEY state may not be permitted in JOURNEY state. The loop keeps the agent's map current.

The CONFIRMATION hard cap: the human ceiling.

Regardless of an agent's authority scope, no booking confirmation can be completed without a human approval step. This is a Security Kernel enforcement rule, not a convention. The CONFIRMATION gate is the point at which commercial commitments become binding — and the protocol's position is that a human must be in the loop at that point, every time.

Human Escalation Manager: structured escalation.

When a situation exceeds an agent's authority — a disruption that requires operator judgment, a traveller welfare concern that requires human intervention, a mandate gap that requires scope expansion — the agent escalates via the Human Escalation Manager. The escalation is structured: the agent names the specific action it cannot take, the reason, and its assessment. The operator receives a clear, actionable escalation request, not an undifferentiated alert.

The Activity Travel Protocol defines four named agent personas, each with a specific function, authority scope, and tool surface: the Guest Agent (traveller-facing, WhatsApp and LINE), the Operator Agent (disruption management and HEM review), the Supplier Agent (safety checks and equipment assignment), and the Discovery Agent (pre-booking activity search). Each has a system prompt template in the @atp/llms-tooling Prompt Library that defines its instruction set and behavioural constraints in plain language the LLM can reason about.

The result is an AI agent architecture that is not defined by what a developer remembered to restrict. It is defined by what the protocol specifies, cryptographically enforced at every action, and auditable after the fact from the Booking Object's immutable event log.