When I started working on travel infrastructure, I thought hotel aggregation was mainly a connectivity problem.
Find enough suppliers, connect their APIs, normalize the responses, and you’re done.
I was wrong.
The real challenge isn’t connecting suppliers. It’s making ten, twenty, or fifty completely different suppliers behave like one predictable system. And once AI agents enter the picture, this problem gets even more interesting.
Every Supplier Has Its Own Version of “Normal”
A hotel supplier might return an available field. Another might return a room object. Another might give you a rate plan and expect you to figure out the actual availability somewhere else.
The same thing happens with hotel names, room types, amenities, cancellation policies, taxes, currencies, and occupancy rules.
At first, these look like annoying data-cleaning problems. But they quickly become product problems.
If an AI agent thinks two rooms are equivalent when they actually have different cancellation policies, that’s no longer just a normalization bug. It’s a trust issue.
The API response is not the product.
The meaning behind the response is the product.
“Same Hotel” Is Surprisingly Hard
Hotel mapping is another rabbit hole.
In theory, you map Supplier A’s hotel ID to Supplier B’s hotel ID.
In reality, hotel names change, properties get rebranded, addresses are formatted differently, and different suppliers may have completely different IDs for the same property.
Sometimes two properties look different but are actually the same hotel. Sometimes two hotels have almost identical names and are definitely not the same place.
This becomes especially important for AI agents.
If your mapping is wrong, the agent might show five hotels when there are actually only two. Or worse, it might merge two different properties and recommend the wrong one.
So aggregation isn’t really about putting more inventory behind one API.
It’s about creating a reliable translation layer between different versions of the same travel ecosystem.
Normalization Is Only the Beginning
A clean schema doesn’t automatically mean clean data.
Take cancellation policies.
One supplier might say “free cancellation until 48 hours before check-in.” Another gives you a timestamp. A third returns a complicated nested policy with multiple penalty periods.
You can normalize all three into the same JSON structure, but that doesn’t necessarily mean you preserved what they actually mean.
Travel is full of these edge cases.
Taxes may be included in one price and excluded in another. Breakfast might be included for some guests but not others. A refundable rate might still have partial penalties.
For an AI agent, losing these details can be dangerous because the model may make a perfectly reasonable decision based on incomplete information.
That’s why I’ve started thinking about normalization differently.
We don’t just need consistent schemas.
We need consistent semantics.
Travel Inventory Isn’t a Database
Then there’s the part that makes everything more annoying: inventory changes.
A room can be available when you search and disappear thirty seconds later. The price can change. A supplier can timeout. Another supplier can return stale inventory.
AI models are naturally good at reasoning over information.
They are not the source of truth for real-time inventory.
So I think the architecture needs to be very clear:
Let the model reason about choices. Let the infrastructure verify reality.
The agent can decide which hotel looks best.
But the system should verify the current price.
The agent can understand the user’s preferences.
But the booking layer should confirm that the room is actually available.
The agent can explain a cancellation policy.
But the underlying supplier data should remain the source of truth.
This separation becomes critical once an agent moves from recommending something to actually booking it.
More Suppliers ≠ Automatically Better
There’s also a strange paradox with aggregation.
Adding more suppliers gives you more inventory, but it also gives you more duplicates, more inconsistent data, more latency, more mapping problems, and more failure modes.
If two suppliers each claim to have millions of hotels, you don’t necessarily have twice as much useful inventory.
You might just have twice as much data to reconcile.
So I no longer think the value of aggregation is simply the number of suppliers connected.
The real value is how well you can make those suppliers disappear behind the interface.
The developer shouldn’t need to understand five different schemas.
The AI agent shouldn’t need to know which supplier returned which hotel.
The user definitely shouldn’t care.
This Is Where MCP Gets Interesting
This is also why I don’t see Travel MCP as simply “a way to expose hotel APIs to an LLM.”
That’s the easy part.
The harder problem is turning a fragmented travel supply chain into something an agent can reliably reason about.
MCP can provide the interface. But underneath it, you still need hotel identity resolution, supplier routing, normalization, availability checks, pricing logic, policy handling, and eventually transaction orchestration.
The interface should look simple.
The infrastructure underneath it probably shouldn’t.
And honestly, I think that’s what good infrastructure is supposed to do.
When an AI developer can call one hotel search tool and get reliable, comparable, up-to-date inventory without knowing which supplier is behind each result, the complexity hasn’t disappeared.
We’ve just put it where it belongs.
