I've been building AI systems for a while, but the moment that permanently changed how I think about agentic travel was watching our own demo confirm a hotel that wasn't in inventory. We'd built a LangGraph-based travel agent, it was running beautifully, and it came back with the room, the rate, the check-in instructions. The property had sold out 48 hours earlier. We were sourcing availability from a stale cache. Our agent was generating exactly the shape of failure we'd been hired to prevent — just with better prose than the systems we were replacing.
The hallucinated booking is not a fringe case or a benchmark curiosity. It's what happens when you layer a language model over an inventory system and assume that fluent output means correct output. The Air Canada chatbot — the one ordered to pay Jake Moffatt $812.02 by the British Columbia Civil Resolution Tribunal in February 2024 after it invented a bereavement fare policy that didn't exist — failed the same way. It produced plausible-sounding output. It was wrong. And after that ruling, the liability sits with the deployer, not the model.
The Happy Path We'd Over-Engineered
That stale-cache failure was only the first thing I got wrong. The second came a few weeks into building for a TMC client, when the operations lead asked a question I should have been prepared for: what happens when the flight cancels after the hotel is already booked?
My answer involved several qualifications and a whiteboard. That's when I understood we'd designed an impressive booking system and a completely unspecified unbooking system. The Saga rollback pattern — hold the hotel while you try to resolve the flight, escalate to the human queue if you can't, void or requeue both if the traveler approves — wasn't in the design at all. We'd modeled the sequence that works and ignored the sequence that doesn't. IROPS is when the TMC is most under pressure and when a bad AI failure has the most operational cost. That was the architecture gap, and it was invisible until someone asked about the disruption case.
Building that rollback properly is also where the NDC/GDS binary thinking breaks. The flight was NDC — the Offer came through a carrier's direct connect via Verteil. The cancel and rebook workflow still ran on GDS middleware. An architecture built as "we're doing NDC, not GDS" had no path for that. The agent needs both pipes with explicit routing logic for which queue handles which event. That's not a configuration decision; it's a fundamental architecture requirement, and it's the one most agentic travel pitches I've seen treat as a future concern.
The Math I Should Have Run Before the First Pitch
The look-to-book economics is the number that nobody puts in the vendor pitch, and for a while I was no different.
GDS providers charge per segment for search, not just for completed bookings. Amadeus, Sabre, and Travelport all enforce look-to-book ratios, and Lufthansa Group hiked GDS booking fees again across all three effective January 1, 2026. An agent designed to run exploratory searches — comparing multiple itineraries before presenting results — burns through those ratios at a rate a human agent never would. OTA margins run 3 to 5 percent on a merchant-model booking. At $3.00 to $3.50 per segment plus commission, a chatty agent that runs four searches per user turn converts a margin question into an operating loss inside a quarter.
I ran that math with a client's traffic model partway into a build and had to have a conversation about search discipline that should have happened in the scoping session. Caching results, batching queries, deferring speculative options — these are architecture constraints, not refinements. They change how the state machine routes. Getting them right means you have to think about the GDS commercial structure before you write the first node in your LangGraph graph.
Where the Big Platforms Fit and Where They Don't
My assessment of the platforms, from building alongside them:
Sabre, Mindtrip, and PayPal together represent the first genuinely end-to-end agentic booking at scale — 420+ airlines, 2 million hotels, Mindtrip's 6.5 million POI knowledge base, PayPal checkout, flights going generally available Q2 2026. If you're an OTA already comfortable distributing Sabre inventory on Sabre rails, this is worth a serious evaluation. The constraint is that you're building on Sabre's distribution architecture. Your inventory relationship and your pricing become Sabre's.
Amadeus Cytric Easy running inside Microsoft Teams is real and the Accenture integration is solid for enterprise Microsoft shops already on Cytric. The reference deployment is Microsoft itself. Outside that intersection — TMCs not on Cytric, units not on Teams — it's thin.
Navan's 73% touchless rate and policy violations dropping from 35% to under 5% are genuine, verified numbers from their 2026 benchmarks. If you want to replace your TMC with an AI-native platform, Navan is the answer. If you want to keep your existing GDS relationships and add intelligence to them, it isn't.
The honest Veriprajna caveat: we build, you operate. We're not an IATA or ARC-accredited ticketing agent — your host issues the stock and the agent routes to them. There's a build-phase discovery that catches teams off-guard: Amadeus Self-Service Production keys explicitly exclude the Flight Create Orders endpoint. If your proof-of-concept was on Self-Service, you'll need an Enterprise key for production ticketing, and IATA or ARC accreditation adds at least 25 days beyond that. We tell clients this in the first scoping conversation, because hitting it mid-build is worse.
The Sequence Problem Underneath the Hallucination Problem
What the TravelPlanner benchmark captures — GPT-4 with ReAct completes 0.6% of real multi-city itineraries — is a specific failure shape that I now think of as the compounding-stochastic problem. A realistic flight booking is roughly ten sequential steps: intent extraction, search, filter, price, hold, policy check, passenger details, payment handoff, PNR commit, ticketing. If each step is a probabilistic LLM call running at 90% reliability, the end-to-end success rate is 0.9 to the power of 10, around 34%. The 0.6% figure is even lower because the benchmark is run against real inventory with time-sensitive data, not a static test set.
The solution I keep coming back to is the one that sounds obvious once you've experienced the failure: the LLM doesn't belong in the control flow. It extracts intent, handles clarification dialogue, summarizes results. Every step that requires a correct answer — GDS call, policy check, payment handoff — runs on hard-coded logic with deterministic error recovery. The state machine is code, not a prompt. I've written this more times than I can count in architecture reviews, and it still gets pushback from teams that believe prompt engineering will close the gap. I've stopped arguing about it. The production failure rate makes the argument.
If the state machine is code, the LLM can be wrong about a fact without the wrong fact becoming a confirmed booking.
You can read more about how we built this at Veriprajna — including the dual GDS/NDC pipe, the Saga rollback pattern, and the policy compilation layer.
The Deadline I'm Building Agains
t
My next quarterly plan is organized around a single date: August 2, 2026 — when EU AI Act Article 50 transparency rules go live for AI systems interacting with EU consumers. The disclosure obligations aren't a post-launch wrapper. Users must know they're talking to an AI. Interactions must be logged. The deployer must be able to explain the decision trail to a regulator, to a court, to an insurance carrier asking about AI posture. The high-risk classification guidance published February 2, 2026. For any TMC or OTA with EU customer exposure, that timetable is already an architecture constraint, not a future compliance task.
Those requirements affect how the agent introduces itself, how it logs each booking step, how it surfaces the audit trail for a chargeback dispute. "We'll handle compliance post-launch" is not a defensible posture after August.
What the Air Canada Ruling Actually Says
I read the BC Civil Resolution Tribunal ruling line by line. The paragraph I keep returning to is the one where Air Canada argued its chatbot was a "separate legal entity" — functionally, that the AI's statements weren't the company's statements. The tribunal's response was short: the company is responsible for every statement on its surfaces, whether it comes from a static page or a model.
That's the governing logic for every AI booking interface that states facts about availability, pricing, or policy. The hallucinated hotel, the invented fare exception, the policy the agent generated because it sounded reasonable — each carries the same liability shape. The architecture that closes that exposure is the same architecture that makes the system reliable at production scale. The safety and the reliability are the same thing, not separate concerns.
At Veriprajna, the builds I'm most confident in are the ones where that insight was in the room from the first design session — not retrofitted after a legal review. If you're thinking through what that looks like for your booking stack, I'd genuinely find the conversation useful. We're still learning what production means for this class of system, and so is everyone else.
