There is an open debate in travel right now, also in tours and activities: When AI agents start booking experiences on behalf of travellers, who will get the agentic booking? The OTA or the operator selling direct?
Nobody knows yet. We don’t know how AI platforms will monetize it, which interfaces travellers will end up adopting, what role will pure agent providers take in customer support, or how quickly they will trust an agent to make a €300 booking without checking the details themselves.
But there is one part of this discussion that gets much less attention.
Can the product actually be bought by a machine?
At Globick, we spend our days with travel experience APIs. And if you look at the problem from that side, rather than from the consumer interface, something becomes quite obvious:
OTAs currently have an advantage.
Not necessarily because they have ad purchasing power, or stronger brands, but because their inventory is generally more ready to be understood, compared and booked by a machine.
Forget discoverability for a minute
Most conversations about agentic commerce focus on discovery.
AEO. Visibility. Reviews. Brand authority. Advertising models. Which sources LLMs will trust and which products they will recommend. All of that matters.
Actually, preliminary data recently shared by Propellic ahead of its upcoming 2026 study points in an interesting direction: AI directed 71% of participants to book directly with operators, while 68% already expressed a preference for booking direct.
That is an encouraging signal for operators. But it also highlights an important distinction: being discoverable by AI is not the same as being bookable by AI.
What happens when the agent doesn’t just recommend where to book, but has to understand the product, select the right option and complete the transaction itself?
That is the layer I’m interested in here.
But imagine discovery has already happened.
A traveller asks:
“Book a guided tour of the Sagrada Família in Spanish for two adults and my 10-year-old, tomorrow morning.”
The agent finds several possible products.
Now comes the difficult part.
It has to understand exactly what each product is, decide which one matches the request, check whether the right option is available, calculate the correct rates, collect whatever passenger information is required and complete the booking.
Without a human filling in the gaps.
And this is where the API matters.
When the buyer has no eyes
A website can hide a surprising amount of bad data.
A good photo helps explain the product. A well-designed page gives context. One FAQ fills in missing information. And ultimately there is a human reading everything and making sense of it.
An agent booking through an API doesn’t have that safety net. Yes, they may crawl the website to get product info and price details, but will it match with what the API is sending as structured data ?
It sees what the API returns. And if the information isn’t there, it has three options: skip the product, look somewhere else for the answer, or infer it.
None is particularly good if you are the operator trying to get the booking.
This changes what matters at the point of sale.
The design of the booking widget becomes irrelevant. The quality and structure of the data behind it become critical.
From what we see, there are three layers that determine whether an experience is really agent-ready.
1. Can the agent understand the product?
Let’s go back to the Sagrada Família example.
The agent needs to know whether the tour is guided. In which language. How long it lasts. Whether children are accepted and under which rate. What is included. Where the customer needs to go.
This sounds obvious. But it isn’t.
Every day at Globick we receive products directly from booking-system APIs with extremely limited content.
Every day at Globick we receive products straight from booking-system APIs that don’t carry that information. No localization. Sometimes no proper description, or just a single line. A title, a price, and little else.
What an agent receives: a title, a price, and not much more.
A human travel agent could call the operator. An AI agent trying to complete a transaction in seconds won’t. And even if it finds the missing information somewhere else, how do we know that information corresponds exactly to the product, option and rate it is about to book?
For agentic commerce, content completeness stops being a merchandising problem.
It becomes transactional infrastructure.
2. Can it understand what to book?
And then things get more complicated.
Many experience APIs expose options and rates that make perfect sense inside the operator’s own booking system but very little sense outside it.
Internal option names that only mean something to the operator.. Rate categories without age ranges. Similar products with unclear differences. Availability structures that require additional context to interpret correctly.
Which one should the agent book?
A human can often guess. A machine shouldn’t.
If the request is:
“Two adults and one child, English tour, with hotel pickup.”
the API needs to make it possible to identify exactly which option matches that request, which rates correspond to those travellers and whether that specific combination is available.
This requires clear options, explicit rate categories, age ranges and an unambiguous relationship between options, rates and availability.
In a human booking flow, bad structure creates friction. In an agentic flow, it can kill the transaction.
Or, potentially worse, create the wrong booking.
3. Can the API keep up?
Even if the product data is perfect, there is another challenge.
The transaction still has to work.
Agents don’t behave like humans browsing a website. Instead, one user request can generate multiple calls across products, dates, options and rates within seconds.
That puts pressure on everything behind the API: Response times matter. Rate limits matter. Availability architecture matters.
If availability takes too long to return, the agent has alternatives.
If the API starts rejecting requests because its rate limiter was designed for human traffic, the agent has alternatives.
If cached availability says a slot exists but the booking request says otherwise, again, the agent has alternatives.
We have already measured how significant that last problem can be in our analysis of availability booking errors.
And then there is the very last step.
What information is actually required to book?
Full name for every passenger? Date of birth? Hotel pickup location? Passport details? Phone number?
If those booking questions are not exposed before the booking request, the agent doesn’t know it needs to ask the traveller.
The result is predictable: the booking reaches the last step and fails.
The last mile: everything the agent needs to know before it clicks “book”.
So why do OTAs start ahead?
This isn’t because operators or booking systems have done something wrong. Simply, most of these APIs were built for a different world, one wherehumans were still somewhere in the process and could compensate for imperfect data.
OTAs had a different problem.
If you want to sell thousands — or millions — of products from thousands of suppliers, you cannot depend on every supplier structuring information in exactly the same way.
So OTAs built the normalization layer themselves: Structured categories, standardized rates. Translated and enriched content, mapped booking questions, availability infrastructure capable of handling large volumes.
They didn’t build this for AI agents. They built it because aggregation doesn’t scale without structure.
It just happens that agents need almost exactly the same thing.
But yet, this does not mean OTAs will win agentic booking.
Operators have important advantages too, particularly around direct commercial relationships, first-party information and control of their product. And the whole discovery layer is still very much up for grabs.
But if we isolate the transaction itself, what we see today is relatively clear:
OTA inventory tends to be more agent-ready than inventory coming directly from operator APIs.
That gap matters.
The API is becoming the storefront
For years, APIs were treated as plumbing, necessary infrastructure sitting somewhere behind the product.
Agentic commerce changes that: If the buyer is a machine, the API is effectively what the buyer sees.
- Your product description is part of the storefront.
- Your rate structure is part of the storefront.
- Your booking questions are part of the storefront.
- Your response time is part of the storefront.
- And your availability accuracy is definitely part of the storefront.
Nobody knows yet whether OTAs, operators, AI platforms or some combination of them will capture most agentic bookings.
But one thing looks increasingly clear from the connectivity layer:
The winners will need inventory that machines can understand, evaluate and book without humans filling in the gaps.
The good news is that this is fixable.
Operators and booking systems can improve content structure, rate definitions, booking requirements, availability accuracy and API performance.
And those that do will be in a much better position regardless of which consumer interface ultimately wins. Because the next customer looking at your inventory might not be looking at it at all.
It will be an agent.
Related reading
1% versus 12% — The Hidden Cost of Availability Booking Errors