When a travel agent built on a language model quotes the wrong price, the model is rarely the cause. The number usually arrived wrong from the tool: stale, for the wrong hotel, for the wrong dates, or on a different tax basis from the booking page. Those are fixable in the tool, before the model ever sees them.
Published 18 September 2026
Google checks the prices its hotel partners send against what a user actually sees on the partner's booking page, and scores each partner on how often they match. The mismatch reasons it reports to partners read like a checklist for anyone building a travel agent. They include delayed matches, hotel not listed, room not available, room not available for the requested occupancy, taxes and fees missing, and wrong itinerary.
An agent that passes a price to a user and then hands them a booking link runs the same test Google does, only in front of the customer. Every one of those failure modes shows up as "the agent lied to me".
| Failure | What the user sees | Fix in the tool, not the prompt |
|---|---|---|
| Stale price | Quoted rate is gone when they click through | Return captured_at with every price. Refuse to quote anything older than your freshness limit; fetch again instead. |
| Wrong hotel | Right price, wrong building | Resolve hotels to a deterministic ID before pricing. See matching hotels across OTAs. |
| Wrong itinerary | Price is for different dates, nights or guests | Echo the request parameters back in the response and have the agent assert they match what the user asked for. |
| Tax basis mismatch | Booking page total is higher than the quote | Return whether each price includes taxes and fees. See why two hotel prices aren't comparable. |
| Room unavailable | "Sold out" after the agent said it was available | Return room type and availability with the price, not a single cheapest number for the hotel. |
| Silent scrape failure | A number from the wrong part of a page, or none at all | Return structured errors. A failed fetch must never become an empty result the model reads as "no rooms". |
Language models are good at following a response schema and bad at noticing what a schema leaves out. So the schema is where accuracy is won. At minimum, every price the agent can quote should carry:
Then give the agent one rule it can follow: quote the total, say what it includes, and say when it was checked. "₹17,936 for two nights including taxes, checked at 10:40 IST" survives a click-through. "About ₹7,600 a night" does not.
Live hotel prices take seconds to collect, not milliseconds. A synchronous tool call that blocks for that long is fragile inside an agent loop. A submit-then-poll pattern is easier to handle: the tool returns a job ID at once, and the agent (or your orchestration layer) polls until the job completes or a timeout you chose is reached. Build the timeout path deliberately, so a slow source produces "prices unavailable right now", not a guess.
Full disclosure: this is our product. Our APIs return structured JSON rather than HTML. Hotel lookups by Google Place ID are deterministic, so the agent cannot be handed a different hotel than it asked for. Jobs follow the submit-and-poll pattern: you get a job_id and poll roughly every two seconds until the job completes, and a rate-limited request gets a clear HTTP 429 rather than a silent failure. MCP integration is available on request. See web data for AI agents and the API docs.
Only partly. A prompt can tell the model to state what a price includes and when it was checked, but it cannot correct a stale, mismatched or wrong-hotel number the tool returned. Fix the data contract first.
There is no universal number. Hotel rates change with demand and inventory, so set a freshness limit for your use case, return a capture time with every price, and re-fetch rather than quote past that limit.
The total for the user's exact dates and guests, with a statement of whether taxes and fees are included. Nightly rates invite arithmetic and tax-basis errors on the user's side.
That prices are unavailable right now, and offer to try again. It should never fall back to a remembered or estimated number presented as current.