AI travel agents have a data problem before they have an AI problem

Consider this request:

“Find a highly rated family activity tomorrow afternoon near my hotel for under €80 that still has availability.”

A modern language model understands the sentence easily.

That is no longer the difficult part.

The harder questions are underneath:

• Which activities actually exist?
• Which listings refer to the same activity?
• What does “near” mean?
• Is €80 the current price?
• Is the price per person or per group?
• Is tomorrow’s 15:00 departure actually available?
• Are children allowed?
• How recent are the reviews?
• When was each fact last updated?
• Which source is authoritative?

Those are data questions.

AI makes incorrect data more dangerous

In a conventional interface, the user often sees individual fields.

Price.

Availability.

Rating.

Cancellation policy.

An AI interface combines those fields into fluent language.

That is powerful, but it can hide uncertainty.

A statement such as:

“This activity is available tomorrow for €64.”

sounds definitive.

If the price was cached several hours ago or the last slot was just sold, a better model does not help.

The system needs better ground truth.

Transactional data is not the same as knowledge

A common AI architecture looks like:

documents → embeddings → vector database → LLM

That works very well for many kinds of knowledge.

Travel contains another class of information:

availability, dates, price, capacity, product IDs, routes, departure times, inventory.

Those values should generally not be approximated through semantic retrieval.

They belong in structured systems or live calls.

Viator’s Partner API illustrates the distinction clearly. Product and availability schedule data can be ingested, but the booking workflow uses a dedicated real-time availability and pricing check for the actual product, option, date, start time and traveler mix.

GetYourGuide’s connectivity model similarly uses reservation-system connections to read availability and prices and send bookings to the correct mapped product or option. See its current guide to reservation-system connectivity.

The lesson is architectural:

The AI layer should not be responsible for inventing transaction truth.

A travel agent needs several retrieval modes

A robust AI travel system usually needs some combination of three.

Semantic retrieval

Useful for:

• descriptions;
• policies;
• destination content;
• long-form reviews;
• supplier documentation;
• qualitative explanations.

Structured retrieval

Useful for:

• products;
• canonical entities;
• routes;
• categories;
• ratings;
• prices;
• coordinates;
• product relationships;
• traveler constraints.

Live retrieval

Useful for:

• current availability;
• current price;
• booking state;
• disruption;
• rapidly changing inventory;
• airline or reservation-system responses.

The agent’s job is to decide which tool answers which question.

The LLM should orchestrate data.

It should not creatively fill gaps in it.

Entity resolution becomes part of AI quality

Suppose the same city tour appears on three marketplaces.

If the system treats all three listings as separate experiences, the AI can produce repetitive recommendations.

If it merges genuinely different variants, it can recommend the wrong product.

This is why activities data becomes an entity-resolution problem before it becomes a recommendation problem.

The AI layer inherits the quality of the canonical model underneath it.

Better ranking cannot fully compensate for broken identity.

Freshness should travel with the fact

A production answer should ideally be able to answer:

Where did this fact come from?

and:

How old is it?

That allows the application to behave differently when confidence differs.

A destination description updated two weeks ago may be perfectly adequate.

A flight status from two weeks ago is useless.

A cancellation policy may remain stable for months.

A ticket price may have changed since the user opened the conversation.

Freshness is contextual.

The system needs more than a global updated_at timestamp.

It needs freshness expectations for the type of data being used.

Provenance is useful to both the model and the user

Provenance can support several behaviours:

• show the user where a claim came from;
• prefer an authoritative source when two values conflict;
• decide whether a live refresh is required;
• avoid answering when the underlying data is too stale;
• make debugging possible when an answer is wrong.

This is especially important in AI interfaces because fluent language tends to flatten uncertainty.

The system should restore that uncertainty where it matters.

Do not use the LLM as a database join

Another architectural smell appears when a model is asked to reconcile identifiers that should have been normalized upstream.

For example:

“These five supplier names probably refer to the same operator. Figure it out in the prompt.”

An LLM can help with entity-resolution candidates.

But persistent identity belongs in the data layer.

If the same mapping matters tomorrow, store the mapping.

If it affects bookings, make it auditable.

If humans need to correct it, give them a workflow.

The model can assist.

It should not become the only place where business identity exists.

AI travel systems need fallback behaviour

What happens when live availability is unavailable?

What happens when a source is stale?

What happens when two sources disagree on price?

What happens when a product exists but cannot be mapped confidently?

A production agent needs explicit fallback rules.

Possible behaviours include:

• ask the user to confirm;
• refresh from a live source;
• show a “price from” value rather than an exact price;
• exclude the option;
• say availability could not be verified;
• route to a booking system;
• surface the source and timestamp.

The worst fallback is an unmarked guess.

Airline AI has the same underlying problem

The same pattern appears in aviation.

A model can understand:

“Find me a morning flight with one stop or fewer and avoid an overnight connection.”

But the answer depends on current schedules, routing, market availability and sometimes airline retail offers.

OAG explicitly positions current aviation schedules, status and related data as infrastructure for travel technology use cases.

Meanwhile, IATA’s Modern Airline Retailing transition is making airline offers richer and more dynamic.

The model does not remove the need to connect to that changing data ecosystem.

It increases the value of doing so well.

Build the data layer and AI layer as one system

This is why Integrality works on both sides.

We build external data pipelines for sources we do not control.

And we build AI agents and applications that operate on structured and proprietary data.

When both layers belong to the same architecture, the system can connect:

source → provenance → normalized record → retrieval/tool → AI answer

instead of hoping the model compensates for weaknesses underneath it.

For the multi-source aviation side of the problem, see Modern aviation data pipelines.

Building a travel AI product?

Before adding another agent framework, identify the questions your product cannot answer reliably today because the underlying data is missing, fragmented or stale.

That is usually the more useful place to start.

If that gap is external travel data, catalog normalization or live tool integration, talk to an Integrality engineer.