For the past year, a lot of conversations around AI travel have focused on one question:
Can an AI agent actually book a hotel?
I think we're starting to move past that question.
The more interesting problem now is:
How does an AI agent actually pay?
A recent integration between Travala and AWS gives us an interesting example.
Travala integrated Amazon Bedrock AgentCore Payments into its Travel MCP, allowing agents to handle hotel bookings with payment infrastructure running in the background. The current setup uses Coinbase Agentic Wallets, USDC, Base, and the x402 payment protocol.
And from a developer perspective, this is more interesting than another hotel MCP announcement.
MCP solved the tool problem
MCP makes it relatively straightforward for an agent to discover and call external capabilities.
For travel, that could look like:
User
↓
AI Agent
↓
Travel MCP
↓
Search hotel
↓
Select room
↓
Book
The agent doesn't need to understand a complicated collection of traditional REST endpoints.
It can work with tools designed around what it actually needs to do.
But there is still a missing piece.
The agent needs to pay.
And that's a very different problem.
An API call and a hotel booking are not the same thing
Calling an API might require an API key.
Booking a hotel involves something much more sensitive:
- money
- authorization
- spending limits
- identity
- payment credentials
- transaction status
- refunds
- cancellations
You don't want to give an AI agent unrestricted access to someone's wallet.
You also don't want every developer building an AI travel agent to implement payment authorization from scratch.
That's where the payment infrastructure becomes important.
The interesting part is the separation of responsibilities
In Travala's current architecture, the agent doesn't simply receive someone's private key and start making blockchain transactions.
The payment infrastructure handles the wallet and authorization layer, while the agent interacts with the booking tools. Travala says the wallet credentials are isolated from the AI runtime, and spending permissions can be time-bound and revoked.
That's an important architectural pattern.
Instead of:
AI Agent → Private Key → Blockchain
you want something closer to:
AI Agent
↓
Booking MCP
↓
Payment Authorization
↓
Agentic Wallet
↓
USDC / Base
The agent gets the ability to execute within defined permissions, rather than simply getting unlimited access to the user's money.
That's a much more realistic model for agentic commerce.
Travel makes this problem harder
There's another reason I'm particularly interested in this as someone working on travel MCP infrastructure.
Travel inventory isn't static.
A hotel room can disappear.
A rate can change.
A cancellation policy can be different between two room packages.
A booking can succeed but return an unexpected state.
And payment doesn't necessarily mean the transaction is finished.
This is why agentic travel isn't simply:
search()
→ book()
→ pay()
The real system looks more like:
Intent
→ Search
→ Compare
→ Select
→ Validate
→ Authorize
→ Pay
→ Confirm
→ Manage
The agent needs to understand what state the transaction is in at every step.
Recent work in the agentic travel ecosystem is already highlighting these issues around expiring offers, price changes and transaction state.
This changes how I think about MCP
MCP started as a way for AI models to interact with tools.
But in travel, I think we're gradually moving toward something bigger:
MCP as an execution interface.
The interesting question isn't only:
Can an AI agent find a hotel?
It's:
Can an AI agent safely execute the entire transaction?
That requires several layers to work together:
Discovery
Can the agent find the right travel capability?
Execution
Can it search, select and book?
Authorization
What is the agent actually allowed to do?
Payment
How does it spend money without exposing sensitive credentials?
Settlement
How does the transaction actually get completed?
Post-booking
What happens when the user wants to cancel, modify or extend the trip?
We're still early.
But the architecture is becoming clearer.
MCP handles the interaction layer.
Payment infrastructure handles authorization and settlement.
Travel systems handle inventory and fulfillment.
And the AI agent sits on top, orchestrating the whole process.
The bigger shift
For years, travel software was built around a human clicking through a checkout flow.
Now we're starting to build infrastructure for something different:
software that can transact on behalf of humans.
That's a much bigger change than simply adding an AI chatbot to a travel website.
And as more payment infrastructure becomes agent-native, the question may stop being:
“Can AI book my hotel?”
and become:
“What should my AI agent be allowed to buy for me?”
That's the engineering problem I think is going to get much more interesting from here.
Top comments (0)