Agentic Travel Doesn’t Just Need an Action Layer. It Needs an Authority Layer.

Agentic Travel Doesn’t Just Need an Action Layer. It Needs an Authority Layer.

Why agentic AI in travel booking needs a framework for delegated authority, not just more capability.

By Mary Li, CEO and Founder, Atlas 

The Authority Layer is the missing piece of agentic travel infrastructure: a framework that defines not what an AI agent can technically do, but what a human has actually authorised it to decide. 

The hardest question in transactional AI is no longer “what can an agent do?” 

It’s “what has a human actually authorised it to decide?” 

For most of the history of travel tech, infrastructure has been built around capabilities: search, price, book, pay, change, cancel. APIs turned these into services. Agentic AI is now making them accessible to machines that can reason, choose tools, and execute workflows on a traveller’s behalf. 

That’s an extraordinary shift. 

But I think we’re missing a second layer of infrastructure: Authority. 

  • An agent may be technically capable of completing a transaction. 
  • That doesn’t mean the traveller intended to give it authority over every decision inside that transaction. 

Capability and authority are not the same thing. In travel, confusing the two gets expensive fast. A booking that fails is inconvenient. A booking that succeeds — at a price never approved, with a seat no one wanted, under conditions no one understood — is worse. The technically successful action may be the actual failure. 

From “can the agent do it?” to “should the agent decide it?” 

When we open-sourced the Atlas Flight Booking Skill, most of the capability was predictable — search fares, confirm pricing, execute the booking. But we deliberately built in checkpoints: 

  • Before authorising the booking 
  • Before accepting certain price changes 
  • Before applying a predefined seat fallback 
  • Before applying a predefined seat fallback 
  • Before confirming the final payment summary 

Small checkpoints. Bigger principle: there are decisions an agent can execute, and decisions a human must still authorise — and those boundaries need to live inside the execution flow, not just in documentation. A rule a developer can ignore is guidance. It isn’t control. 

The Authority Layer 

The Action Layer answers: what can this agent do? Search, price, book, pay, refund, modify. 

The Authority Layer answers something different: what is this agent allowed to decide? 

Can it accept a $2 price increase automatically? What about $20? Can it pick another aisle seat if the one requested disappears? Can it accept a non-refundable fare? Charge the card? Cancel something with a penalty? And most importantly — when must it stop and ask? 

These aren’t edge cases. They’re part of the transaction architecture. 

Every travel category will have its own “human yes” moments 

  • Flights: price changes, payment, ancillary decisions. 
  • Hotels: non-refundable rates, deposits, cancellation deadlines, room substitutions. 
  • Cruises: cabin changes, deposits, final payment commitments. 
  • Rail, car rental, tours, insurance will each develop their own version. 

The industry needs more than a common language for actions. We need a common language for delegated authority. 

From binary permission to delegation 

Authority doesn’t have to mean asking the traveller every time — that defeats the point of having an agent. The more useful model is delegation: 

  • “You can accept a fare increase of up to $10.” 
  • “Choose any aisle seat within three rows.” 
  • “Book automatically if the cancellation policy is fully refundable.” 
  • “Never buy a non-refundable hotel without asking me.” 

Now the agent has a mandate, not just a yes/no. A future authority model likely looks like four states: 

  • ✅ Agent may decide autonomously 
  • ⚙️ Agent may decide within predefined limits 
  • 🙋 Human approval required 
  • 🚫 Agent may not perform this action 

Once these rules are machine-readable, agents can become far more autonomous without becoming less accountable. 

That gap between what agents can do and what people are actually ready to hand over is already visible in the data. Accenture’s June 2026 global survey of over 25,000 consumers across 16 countries found that 74% are comfortable delegating research and comparison tasks to an AI agent, but only 9% would let one act fully autonomously and complete a purchase on its own, with just 32% willing to let it decide within pre-set boundaries. Capability has outpaced trust. Closing that gap isn’t a better-model problem, it’s an authority problem. 

Trust will be built at the boundaries 

There’s a lot of excitement about making agents more capable, and I share it. But I suspect the systems people trust most won’t just be the ones that can do the most — they’ll be the ones that understand their boundaries best. 

The next generation of travel infrastructure needs two standards working together: 

  • An Action Standard — what the agent can do. 
  • An Authority Standard — what the agent is allowed to decide. 

We’ve spent decades building APIs that tell software how to execute a transaction. Agentic commerce may require us to spend the next few years defining something equally important: where the human still says yes.

 

Frequently Asked Questions:

The Authority Layer is a framework that defines what an AI travel agent is allowed to decide on a traveller’s behalf, as distinct from the Action Layer, which defines what it’s technically capable of doing (searching, pricing, booking, paying, changing, or cancelling).

Because a technically successful booking can still be the wrong outcome, for example a booking made at an unapproved price or with an unwanted seat. Without a defined authority boundary, an agent can complete a transaction correctly while still acting outside what the traveller intended.

Atlas Flight Booking Skill builds checkpoints directly into the execution flow, for example before authorising a booking, accepting certain price changes, applying a seat fallback, or confirming final payment, so the boundary between what an agent can execute and what a human must approve is enforced in the workflow itself, not left to documentation.

Related Posts