How to verify a booking made by an AI agent (claim vs. proof)

BookingTruth — Sun, 27 Sep 2026 23:06:59 +0000

When an AI agent says "your flight is booked," that sentence is a claim. The agent's tool returned something that looked like success, and the agent relayed it. Whether a reservation actually exists in the supplier's system of record is a different question - and nobody in the loop asks it by default.

This post is about the gap between the two, and how to close it.

Confirmation numbers are claims, not proof

A booking flow usually ends with the agent holding a confirmation number or PNR from a tool call. That string proves a tool returned a string. It does not prove:

the PNR exists in the supplier's system
the ticket was actually issued (confirmation != ticket)
the reservation wasn't cancelled or dropped after issuance
the seats, rooms, or dates match what was paid for

Production failure modes we've seen: booking APIs that return 200 while the supplier never creates a record; tickets stuck in "pending issuance" that silently fail hours later; OTA confirmations that reference reservations the hotel can't see.

What proof looks like

The only evidence that settles it is supplier-authoritative: the airline's own record, the hotel chain's central reservation system, the GDS. Anything else is a copy of a copy.

A rough evidence ladder, weakest to strongest:

The agent's own summary (worthless as evidence)
The booking tool's response body
A confirmation email (often sent before ticketing completes, and stale the moment anything changes)
The OTA or aggregator's itinerary page
Supplier-authoritative record: the PNR or ticket status read from the airline, hotel chain, or GDS directly

If your agent hasn't checked #5, the honest status is UNKNOWN, not CONFIRMED.

A practical verification loop

For an agent that just made a booking:

Capture the claim: PNR or confirmation number, supplier, dates, traveler.
Wait out the supplier's latency window (30-180 seconds is normal; ticket issuance can lag longer).
Query the supplier-authoritative source for the record.
Only then mark the booking confirmed. If the record isn't there, retry with backoff, then fail loudly - never silently downgrade to "probably fine."

This is also the right gate before anything irreversible downstream: releasing escrowed funds, reporting the trip as booked to a user, or making the next booking that depends on the first one.

We built an API for the check

We run BookingTruth, an evidence-gated booking verification API. You POST the booking details and get back a verdict: CONFIRMED only on supplier-authoritative evidence (#5 on the ladder), otherwise UNKNOWN with an indicated_state so the agent can decide what to do next instead of guessing. There's a REST API and an MCP server; the sandbox is free with any sb_ key and there's an llms.txt for agent consumption: https://bookingtruth.com/llms.txt

Why we built it this way: an agent that can't tell claim from proof will eventually book a phantom trip and learn nothing from it. Verification has to be a first-class step in the loop, not a log line.

What's your agent's bar for calling a booking "confirmed"? Would you gate it on a supplier-authoritative check - why or why not? We're collecting builder answers, and they directly shape the API.

Your agent's "booking confirmed" is probably a guess. We built an evidence gate.

BookingTruth — Sun, 27 Sep 2026 14:42:41 +0000

Ask an AI agent to check whether a flight is actually ticketed and it will happily read the OTA email, see "You're all set!", and tell you you're confirmed. Sometimes that's true. Sometimes the airline never ticketed anything. The agent can't tell the difference, because an email that says confirmed is not evidence that a supplier recorded confirmed.

We kept hitting this building travel agents, so we built BookingTruth: a booking-assurance API (and remote MCP server) that parses booking confirmation emails and receipts, grades what each document actually proves, reconciles contradictions across documents, and returns a verdict with a citable proof packet.

The rule that does the work

Every claim a parser extracts carries an evidence tier (0-6) - a measure of how authoritative the signal is, not how confident a model feels:

Tier 5-6: supplier-authoritative. An authenticated supplier lookup, or a supplier-issued receipt carrying an issuance artifact - a 13-digit eTicket number is the classic example.
Tier 3: OTA confirmation. Expedia says your rental car is confirmed. Useful, but it's the middleman's word.
Tier 0: LLM output. It can never decide a verdict. Ever.

CONFIRMED only comes back on tier 5-6. Everything below returns an honest UNKNOWN with an indicated_state (what the documents suggest) and needs_primary_check: true. An OTA "confirmed" email is not ticketing. "We're processing your request" is not ticketing. An issued eTicket number is.

Dogfooding it on real receipts

We ran the live API against actual booking receipts this morning:

United, booking confirmation + eTicket receipt (a real pair): CONFIRMED, tier 5, via the rule united.eticket_implies_ticketed. The engine even logged the confirmation email's "processing" prose as a first-class conflict against the issued eTicket - then higher-class evidence won. Exactly the contradiction that fools a chat agent.

Expedia car rental confirmation: UNKNOWN with indicated_state: confirmed, tier 3, needs_primary_check: true. Expedia said "confirmed", but Expedia isn't the supplier, so the API refused to rubber-stamp it. This case is also the roadmap: tier-6 authenticated supplier lookups (PNR pulls) will let these resolve to real verdicts.

A hotel stay reminder from a chain we don't cover: clean UNKNOWN, supplier: unknown. No invented answer.

Try it - free sandbox, no signup

The round trip is two curls. Demo fixtures (synthetic) included:

# list the demo documents
curl https://api.bookingtruth.com/v1/demo/fixtures

# run a check - any Bearer key starting with sb_ works
curl -X POST https://api.bookingtruth.com/v1/check \
  -H "Authorization: Bearer sb_demo" \
  -H "Content-Type: application/json" \
  -d '{"documents": [{"filename": "doc.txt", "content": "<raw email text>"}]}'

Every verdict links a proof packet: the claims, their tiers, the rule trace, and source hashes behind the decision.

Use it from your agent (MCP)

It's a remote streamable-HTTP MCP server - no install:

{
  "mcpServers": {
    "bookingtruth": {
      "type": "url",
      "url": "https://api.bookingtruth.com/mcp"
    }
  }
}

Two tools: booking_check (documents in, verdicts + proof packets out) and supplier_coverage (live seeded/planned parser matrix). Seeded today: United, Expedia, Disney.

What's next

Tier-6 live supplier lookups - authenticated PNR retrieval so OTA UNKNOWNs become real verdicts. That's the North Star.
More parsers. Which suppliers should we add? Comments welcome.

Source (MIT, stdlib-only Python): https://github.com/bookingtruth/bookingtruth-mcp - the repo has the full architecture docs, the API spec, and the test suite over the contradiction cases.

DEV Community: BookingTruth