The decision that took five minutes
A business traveller is midway through a multi-city trip. The itinerary looks clean on paper: Narita to Istanbul, Istanbul to Dubai, Dubai to Colombo, Colombo back to Narita. Four segments, two weeks, a coherent route through three time zones. Then, midway through the Istanbul meetings, the agenda expands. Two more days are needed. The decision takes five minutes.
What follows takes a full working day.
Two airlines, each with separate booking systems and separate rebooking policies. Hotels in Dubai and Colombo that need their check-in dates shifted. A connecting flight out of Dubai that no longer makes sense given the new Istanbul departure. Every call leads to another call. The airline confirms the flight change but cannot see the hotel. The hotel confirms the date shift but cannot see the connecting flight. By the time the last piece lands, eight hours have passed. The traveller has spent a full working day being the integration layer between systems that cannot see each other.
A structural problem, not a service problem
This is not a story about unhelpful airline agents or unresponsive hotels. Every person in that chain did their job correctly. The problem is structural: each system can see only its own piece of the booking. The airline sees a flight. The hotel sees a reservation. No system has a shared view of the itinerary as a whole.
Which means no system can propagate a change decision across the chain. When the Istanbul extension is decided, there is no mechanism to say: here is what has changed, here is what needs to follow, here is who needs to act and in what order. The traveller becomes the only entity who holds the complete picture — and so the traveller becomes the integration layer, manually phoning, confirming, and reconciling across five cities.
This is not an edge case. Every business traveller who has ever extended a trip, missed a connection, or changed a return flight has been through some version of it. It is the normal case. And current travel infrastructure has no answer to it.
The itinerary as a single object
The Activity Travel Protocol approaches this differently. The entire itinerary — air segments, hotel components, transfers — is represented as a single Booking Object. Each component has its own state and its own Duty of Care assignment, but all are connected under one shared record. When anything changes, the change propagates through the object. The systems do not need to call each other. The protocol handles coordination.
When the Istanbul extension decision is made, an AI agent operating under a declared authority scope — an AgentAuthorityDeclaration that specifies exactly what it can do without human approval — propagates the change. The Dubai and Colombo hotel components are shifted; suppliers notified automatically within the modification window defined when the booking was made. The affected flight segments enter BOOKING_SUSPENDED — a defined protocol state that opens a structured modification window with each airline without cancelling the booking. Downstream suppliers are notified in the correct dependency order. Decisions that exceed the agent's declared authority scope — a rebooking involving a significant fare difference — are escalated to the Human Escalation Manager. The traveller approves that one decision. Everything else resolves automatically.
What makes the protocol different
Two elements make this possible. The first is the Booking Object itself — a shared, structured record of the entire itinerary that every party can read and act on, governed by a defined state machine that specifies exactly what can happen at each point and who needs to authorise it. The second is the AgentAuthorityDeclaration — the credential that defines what the AI agent is permitted to do autonomously, what requires human approval, and what is outside scope entirely. The Security Kernel enforces the declaration at every state transition.
For itineraries that span multiple airlines — each with their own booking systems and rebooking policies — the protocol uses an NDC bridge architecture to represent air components as first-class Booking Object elements. The airlines do not need to see each other's systems. The protocol holds the shared state.
The normal case, finally handled
For corporate travel managers, this means a measurable reduction in the time and cost of itinerary disruption — every extended meeting, every weather delay, every missed connection handled through structured protocol rather than manual coordination. For OTAs building the next generation of AI travel assistants, it is the infrastructure layer that makes autonomous itinerary management possible without creating unverifiable liability chains. For the traveller, it is simpler than all of that: the decision that took five minutes should not take a day to implement.