The connectivity problem
A traveller opens an app and types: I want a ski week in Nagano in February. Four nights, ski school for a beginner, equipment rental, transfer from Nagano station on arrival, a good dinner on the Saturday.
In today's world, that request reaches an AI assistant that can understand it perfectly and book almost none of it. It can find the hotel. It can probably book the transfer. The ski school, the equipment rental, the restaurant reservation — each of those requires a separate platform, a separate account, a separate confirmation. The AI can recommend. It cannot assemble.
This is not a capability problem. The AI is capable enough. It is a connectivity problem. There is no shared language that lets an AI agent read what a ski school offers, confirm availability for a specific date, agree commercial terms, and slot that confirmation into a coherent booking that also includes the hotel, the transfer, and the dinner — as a single package, with a single accountability record, and a single point of contact when something goes wrong.
The 20th-century travel agent solved this problem manually. AI is about to do all of that automatically — at any scale, across any geography, in seconds. The question is not whether this happens. It is happening. The question is what structure it runs on.
What changes — and what does not
| Task | The 20th-century travel agent | The AI-era travel agent |
|---|---|---|
| Assembly | Phone each supplier. Negotiate terms. Check availability manually. Build the itinerary in a spreadsheet. | AI agent reads Capability Declarations from every registered supplier. Feasibility check runs in seconds. Itinerary assembled automatically. |
| Confirmation | Agent reviews and confirms each component individually. Slow. Prone to error at handoff points. | Booking Object reaches CONFIRMATION state. Human review gate: a qualified person checks the assembled package before it is committed. |
| Accountability | Agent holds duty of care informally — through professional knowledge and personal accountability. No machine-readable record. | Booking Object records every duty of care transfer. HEM ensures a human is reachable at every welfare-consequential decision point. |
| Disruption | Agent is called. Agent calls suppliers. Manual coordination. Outcome depends on individual relationships and availability. | TRAVELER_UNREACHABLE and BOOKING_SUSPENDED states trigger defined escalation chains. Human escalation is structured, not ad hoc. |
| Agent's role | Assembly and coordination. | Oversight, exception handling, and accountability. |
How the protocol structures AI agent authority
The Activity Travel Protocol gives AI travel agents a structured language. Every supplier who registers publishes a Capability Declaration: a machine-readable statement of what they offer, when, at what price, under what conditions, and with what duty of care obligations. The AI agent reads these declarations, runs a feasibility check against the traveller's request, and assembles a Booking Object — the live accountability record for the journey.
The AI does not operate in a single mode. The protocol defines four authority levels that determine how much autonomy an AI agent has in a given deployment.
| Level | Name | What the AI agent can do | Human role |
|---|---|---|---|
| L0 | Read-only | Read Capability Declarations. Check availability. Produce itinerary options. No binding commitments. | Reviews options. Selects preferred itinerary. |
| L1 | Confirmed with approval | Assembles itinerary. Reaches CONFIRMATION state. Commits only after explicit human approval at the gate. | Approves or rejects at CONFIRMATION. Retains full authority to modify before commitment. |
| L2 | Delegated authority | Commits bookings within a pre-defined scope declared in the AgentAuthorityDeclaration. Escalates outside scope. | Sets scope via AgentAuthorityDeclaration. Receives escalations. Reviews completed bookings. |
| L3 | Full autonomy | End-to-end booking authority within declared scope. Welfare-affecting decisions trigger HEM escalation regardless of level. | HEM escalation for welfare-consequential decisions. Oversight role, not approval role. |
The workflow in practice
Not displacement — leverage
For traditional travel agents, this is not a displacement story. It is a leverage story. An agent who previously managed fifty complex bookings a year — because assembly took most of their time — can now manage five hundred, because the AI handles assembly. Their value moves up the stack: into the advisory layer, the exception layer, and the accountability layer that no AI agent can hold on its own.
For OTAs, the protocol creates the infrastructure for a product category that does not yet exist at scale: the fully AI-assembled, fully accountable, multi-supplier itinerary. Not a recommendation. Not a list of links. A confirmed booking, with a Booking Object, with structured duty of care, with a human in the loop at CONFIRMATION and available throughout the journey.
For tour operators, the protocol enables a structural change in how packages are assembled. Instead of building fixed packages in advance and selling them from a catalogue, an operator can publish their supplier network as Capability Declarations and let the protocol assemble packages dynamically on demand — at any scale, for any destination they can reach.