Grounding AI in Real-Time Data

An LLM was trained on data from months or years ago. Flight prices change by the minute. If you ask an ungrounded LLM "how much does a flight from SFO to NRT cost in April?", it will give you a confident answer based on its training data. That answer will be wrong.

This is not a minor inaccuracy. In travel booking, wrong prices lead to wrong expectations lead to frustrated users lead to lost trust. An AI travel agent that guesses at prices, availability, or schedules instead of checking live data is worse than useless. It is actively harmful.

Grounding is the practice of ensuring every factual claim the AI makes is backed by real-time data from authoritative sources. It is the single most important technical discipline in building a trustworthy AI travel booking system.

The staleness problem

LLM training data has a cutoff date. Even frequently updated models are trained on data that is weeks to months old. For most applications, this is fine. The capital of France does not change between model updates.

For travel, staleness is disqualifying. Here is a partial list of things that change daily or more frequently:

• Flight prices (multiple times per day based on demand)
• Seat availability (changes with every booking)
• Hotel room rates (dynamic pricing based on occupancy)
• Flight schedules (seasonal changes, operational adjustments)
• Visa requirements (policy changes)
• Travel advisories (safety updates)

An LLM that reports a $450 fare for SFO-NRT because that was the average in its training data might be off by $200 in either direction. The user who trusts that number and then sees $650 at checkout feels misled.

Tool-augmented generation

The architecture that solves staleness is tool-augmented generation. The principle is straightforward: the LLM never states facts from its parametric memory. Instead, it queries live APIs for every factual claim.

When the user asks about flights to Tokyo, the agent does not recall what Tokyo flights cost. It calls the flight search API with the user's parameters and gets current inventory with current prices. The response is constructed entirely from live data.

This inversion is important. Traditional AI systems use the LLM as a knowledge base and occasionally augment with external data. We use the LLM as a reasoning engine that always operates on external data. The LLM's parametric knowledge about travel prices, schedules, and availability is deliberately unused.

Function calling accuracy exceeds 95% for well-defined schemas, which means the tool invocation itself is reliable. The agent correctly identifies when it needs real data (nearly always for factual claims), selects the right tool, and populates parameters correctly.

Designing APIs an LLM can reason about

Not all APIs are equally easy for an LLM to use effectively. We have found that schema design significantly affects tool use accuracy.

Clear parameter names matter. "departure_date" is better than "date1." "origin_airport_iata" is better than "from." The model uses parameter names as semantic cues.

Constrained value spaces reduce errors. An enum of cabin classes (economy, premium_economy, business, first) is better than a free-text field. The model knows exactly what values are acceptable.

Structured error responses help the agent recover. An error that says "no_flights_found: no direct flights available for this route on this date" is actionable. The agent can respond by searching nearby dates or offering connection options. A generic "400 Bad Request" is not actionable.

Consistent response schemas across similar tools reduce confusion. If the flight search returns results in one format and the hotel search returns results in a different format, the model has to learn two schemas. Consistency helps.

Verification loops

Grounding through tool use eliminates most hallucination for factual queries. But there are edge cases where the agent might still make incorrect claims.

The agent searches for flights and gets results. It then narrates: "I found a direct flight at $520." But what if the model misread the API response? What if it confused two flights in the result set? What if it rounded incorrectly?

We implement verification loops where the agent cross-checks its own claims against the source data before presenting. The flow is:

1. Agent receives tool results
2. Agent generates a response incorporating those results
3. Before presenting, a verification step compares key claims (price, time, airline) against the raw API data
4. Mismatches are corrected before the user sees them

This adds a small amount of latency but catches the category of errors where the model has real data but misrepresents it in its narrative.

The confidence gap

There is a qualitative difference between "I think it costs $400" and "Current price: $412, based on live availability checked 30 seconds ago."

The first statement invites doubt. How does the AI think? Based on what? Is it guessing?

The second statement inspires confidence. The price is specific. The source is identified. The freshness is stated. The user knows this is real data, not an estimate.

We always attribute factual claims to their source. Prices come with timestamps. Availability comes with source attribution. Schedules come with confidence indicators. This is not just good UX. It is the transparency that builds trust in AI travel booking.

Trust in AI recommendations jumps from roughly 30% to roughly 65% when the AI explains its reasoning and cites its sources. Grounding provides the citation. Narration provides the reasoning. Together, they close the trust gap.

When grounding is not enough

I want to be honest about the limits. Grounding eliminates hallucination for factual queries that can be answered by a tool call. But not every claim in a travel conversation is a factual query.

"Tokyo is beautiful in cherry blossom season" is an opinion. The LLM states it from training data. It happens to be true, but it is not grounded in a real-time API.

"You'll love the Shibuya neighborhood" is a prediction. It is based on the agent's model of the user's preferences. It might be right or wrong.

"I recommend option B" is a judgment that combines factual data (the flight details) with preference matching (the user's history) with general knowledge (the airline's reputation). The factual data is grounded. The preference matching is based on the memory system. The general knowledge is from training data.

We are careful about which claims need grounding and which do not. Price: always grounded. Availability: always grounded. Schedule: always grounded. Opinions about destinations: clearly framed as opinions. Recommendations: backed by grounded data with transparent reasoning.

The boundary between "must be grounded" and "can come from general knowledge" is defined by consequence. If being wrong costs the user money, it must be grounded. If being wrong means the user visited a neighborhood they did not love, general knowledge is acceptable.

Grounding is not a silver bullet. It is a discipline. And it is the discipline that separates AI travel agents that people trust with their credit card from chatbots they use for inspiration and then verify on their own.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.