Agentic booking, and what actually ships in 2026.

Why the general agent lost the argument

The general, end-to-end agent has to answer three questions the industry has spent forty years building infrastructure to avoid answering casually. Who owns the booking record. Who is liable when the itinerary breaks. Who reprices when a supplier changes inventory mid-transaction. A PNR in a Sabre or Amadeus host is not a JSON blob a model can shape freely; it is a legal and operational artefact with a specific owner and a specific set of downstream systems, from the DCS at the airport to the mid-office accounting run at month end, that all assume the record was created through a defined process. An agent that books outside that process has not innovated. It has created an orphan record nobody's reconciliation job can find.

This is not a model quality problem. Current frontier models are, by any reasonable benchmark, good enough to plan a trip. The problem is the twenty seconds after the plan, when the agent has to call a live fare quote, confirm it has not gone stale, check a fare rule that changes by point of sale, apply a corporate travel policy that varies by cost centre, and write the result into a system half a dozen others expect to behave in a specific way. NDC exists because the industry decided offer and order needed to be explicit, versioned objects rather than something reconstructed from a cached fare. An agent that ignores that discipline is fast in the demo and wrong in production.

There is also a plain commercial reason the general agent stalled. Distribution economics in travel run on contracted terms between suppliers, distributors and intermediaries, and those contracts assume a known channel making the booking, with known obligations around cancellation, servicing and disclosure. A model that books outside those channels, on behalf of a traveller who never explicitly authorised the specific transaction, exposes whoever operates it to chargebacks and, in the European Union, disputes about which party is the ‘organiser’ under package travel regulation. None of that is exotic. It is the same liability question the industry answered for online travel agencies twenty years ago, asked again, faster, with less paper trail.

So the general agent has not disappeared. It has been quietly re-scoped, living on as a discovery tool sitting in front of the booking flow rather than inside it. The moment money moves, a narrower agent with an owned outcome takes over. That handoff, more than any model capability, is the actual architecture decision of 2026, and it is why our approach to agentic work starts with a system-of-record map before a prompt gets written.

The four places agentic actually ships

The first production lane is servicing. A traveller with an existing booking wants to change a date, add a bag, or ask why their seat assignment vanished. The agent already has a booking number, a confirmed fare rule, a live inventory feed, and a bounded outcome: modify this specific record within these specific constraints. This is the least glamorous use case in the category and the one with the clearest return, because contact centre volume in travel is enormous and repetitive. A large hotel group or airline can measure containment rate, the share of contacts resolved without a human, within the first month.

The second is reshopping. A ticket exists. The fare for the same itinerary drops, or a better connection opens up. The agent watches for the delta, checks whether the fare rule and the loyalty re-fare terms allow a change without penalty, and either executes the rebooking inside a pre-authorised band or surfaces a one-tap offer. Airlines have run manual versions of this for years through revenue management desks; the agentic version is an old idea running continuously instead of on a quarterly cadence.

The third is disruption management, where the commercial case is starkest. When a flight cancels, the number of viable rebooking options collapses within minutes, and the gap between an agent that holds the best option and a call centre queue with a forty-minute wait is the gap between a retained customer and a public complaint. Airlines running agentic disruption tools report material reductions in irregular operations cost per passenger, because the agent scans inventory across interline partners and holds a seat faster than a human can.

The fourth is corporate booking inside policy. Not open-ended trip planning, where the general agent keeps failing to earn trust, but a bounded search over a defined universe: preferred carriers, negotiated fares, per diem limits, and an approval workflow already sitting in the travel management company's policy engine, of the kind Sabre's GetThere and Amadeus's cytric already encode. The agent's job is not to invent a trip. It is to search that constrained space faster than a traveller can, and explain, in plain language, why an option is out of policy rather than hiding it.

Why guardrails matter more than model choice

Every serious deployment we have seen starts from the same premise: the model is the least differentiated part of the stack. Foundation model providers ship new frontier models every few months, and the gap between the best three or four is now smaller than the gap between a system that guards its tool calls properly and one that does not. The interesting engineering happens in the guardrail, retrieval and audit layers, none of which show up on a benchmark leaderboard.

Tool calling is where most of the actual risk sits. An agent that can call a ‘hold_fare’ function or a ‘cancel_booking’ function is only as safe as the constraints wrapped around that call. The working pattern is to make every state-changing call require a signed, structured payload with a confirmed price, availability token, and policy match, rejecting anything the model constructs without all three. The model plans and reasons in natural language. It never writes to the PNR, folio, or CRS directly, only calling a function a deterministic service validates and executes, the same discipline CQRS enforces in event-sourced systems: separate the intent from the write, audit the write independently.

Hallucination in a booking agent does not usually look like a fabricated city or a made-up airline. It looks like a stale price stated with total confidence, a fare rule paraphrased slightly wrong, or a cancellation policy inferred from a similar but different fare class. This is why retrieval matters more than prompt engineering. A retrieval-augmented generation layer that returns the exact fare rule text, inventory snapshot, and loyalty tier terms, timestamped, and refuses to let the model answer from memory when live data exists, closes off the most expensive failure mode. The model should never answer a pricing question from what it learned in training. It should quote a document it was just handed.

The last discipline is the one boards ask about after something goes wrong rather than before: audit. Every decision an agent makes, every tool call, every retrieved document, every guardrail that fired or didn't, needs to be reconstructable after the fact, not as a log line buried in an application server but as a structured, queryable record a regulator or a customer's lawyer can be shown. Firms that treat this as an afterthought discover the cost the first time a passenger rights claim lands and nobody can show which system quoted which price to which traveller, at which second.

The bar the agent has to clear

The bar for shipping an agent into production is not accuracy on a benchmark. It is behaviour under a bad input, because bad inputs are the normal condition of travel data, not the exception. Inventory feeds go stale during peak load. GDS sessions time out. A supplier's availability cache disagrees with its own booking engine for the ninety seconds a batch job takes to reconcile. An agent's design has to assume all of this will happen on a Tuesday afternoon, not treat it as an edge case to patch later.

The test that separates a demo from a system is simple to describe and hard to pass: when the inventory feed is stale, does the agent hold and say so, or does it invent an answer with the same confidence it uses for a fresh quote. When a fare changes mid-transaction, does the agent surface the delta before confirming, or quietly absorb it into a footnote. When a supplier's API goes down, does the agent fail loudly, routing to a human with full context, or fail silently. Every business we have watched succeed with agentic booking spent the first two quarters mapping failure modes, not tuning prompts.

This is also where the containment rate metric gets abused. A team under pressure to show results can inflate containment by letting the agent close conversations it should have escalated, and the number looks good for a quarter until complaint or chargeback volume catches up two quarters later. The metric that actually matters is containment conditioned on a second measure, typically post-interaction satisfaction or no repeat contact within seven days. An agent that closes the ticket but the traveller calls back the next day has contained nothing. It has deferred the cost.

None of this is exotic engineering. It is the discipline that made call centre IVR systems tolerable twenty years ago, applied to a more capable interface. The businesses getting this right are not the ones with the most advanced model. They are the ones who treated the agent as operational infrastructure, with the change management and incident response rigour of a payment system, rather than as a chat feature bolted onto a website, which is broadly how we scope this work across the travel and hospitality industries we operate in.

The stack, in one paragraph

Strip away the vendor decks and the working architecture repeats across every serious deployment we have reviewed. A retrieval layer that returns the exact booking, fare rule and inventory state on request, never a paraphrase, never a cached approximation older than the tolerance the business has set. A guardrail layer that refuses to let the model construct a booking or a cancellation without a confirmed price, availability token and policy match, enforced by code the model cannot argue its way around. A model layer that plans, reasons and calls tools, but is structurally prevented from writing to the PNR, the CRS or the folio without a signed transaction through a deterministic service. An audit layer that reconstructs every decision, retrieved document and guardrail outcome for a regulator or legal review, on demand, not as an emergency recovery exercise.

Bounded outcomes ship. Open-ended trip planners do not. The question is not whether the model is smart; it is whether the outcome is small.

The model is the part that gets the applause on a conference stage. The other three layers are what a chief information officer's team is actually paid to build, and where most of the engineering effort should go. We have watched teams spend nine months evaluating foundation models and three weeks on retrieval and audit, and it is invariably the wrong ratio. Model quality differences close within a generation. Guardrail and audit debt compounds.

This is also where the architecture connects back to systems that predate the current wave of AI entirely. A message bus, whether Kafka or RabbitMQ under the hood, sits naturally underneath the retrieval and audit layers, because booking events, fare changes and disruption alerts are exactly the kind of durable, ordered, replayable stream those systems were built for. An agent that subscribes to the same event stream that already feeds a pricing engine or a loyalty ledger is not bolting AI onto the business. It is adding one more well-behaved consumer to an architecture that a mature operator has probably already invested in for other reasons, a point we return to when discussing how legacy platforms get modernised without a rip and replace.

None of this stack is unique to travel. What is unique to travel is the density of regulation, interline liability, and legacy systems of record sitting underneath it, which is exactly why a general-purpose agent framework lifted from another industry tends to fail quietly here rather than loudly. The firms doing this well have people who understand PNR structures and NDC schemas sitting next to the people who understand transformer architectures, in the same room, from week one.

The four questions to ask before you scope an agent

First, who owns the record the agent will touch. If the answer involves more than one system of record, or a system you do not control, such as a supplier's own inventory platform, the scope is too wide. Narrow it until exactly one owned system sits behind the write path.

Second, what is the bounded outcome. Not ‘help the traveller’, which is not an outcome, but ‘modify this booking within these fare rules’ or ‘hold the next viable option for this cancelled segment’. If you cannot write the outcome in one sentence with a measurable success condition, the agent is not ready to be scoped, let alone built.

Third, what happens on a bad input. Write down, before a line of code is shipped, the specific behaviour for a stale feed, a mid-transaction price change, and a downstream outage. If the answer to any of these is ‘the model will handle it’, stop, because the model handling it is precisely the failure mode that produces confident, wrong answers.

Fourth, can you reconstruct every decision the agent made in the last ninety days, for a specific traveller, in a form a non-engineer can read. If the honest answer is no, the audit layer is not built yet, and nothing else in the stack should ship ahead of it, however good the demo looked in the boardroom.

What this looks like in practice

A mid-sized hotel group with call centre volumes running into six figures a month came to us with a familiar brief: build an AI concierge that could handle anything a guest might ask, from restaurant recommendations to complete rebookings. We pushed back on the scope in the first working session. Instead of one general agent, we mapped the top eleven reasons a guest actually calls, and found that four, date changes, early check-in requests, folio disputes on incidental charges, and loyalty point queries, accounted for sixty-one per cent of call volume and had a single, well-defined outcome apiece.

We shipped an agent that handled exactly those four intents, reading live availability and rate data from the property management system through a wrapped API rather than a direct database connection, and writing back through the same service the human agents used, so nothing about the system of record changed. Every tool call required a confirmed rate and availability token before it could execute; anything else routed to a human with full context attached, not a cold transfer.

In the first ninety days the agent contained forty-four per cent of the four targeted intents without escalation, measured against a stricter definition that counted a callback within seven days as a failed containment. Average handling time on those intents dropped from six minutes to under ninety seconds. The group's board asked, reasonably, why the concierge could not also handle restaurant bookings. We said not yet: every new intent meant another set of failure modes to map, another retrieval source to validate, and another slice of the audit layer to build, and the fastest way to blow the ninety-day result was to double the surface area before the first four intents had been proven under real, seasonal call volume.

Six months on, the group expanded the agent to a fifth intent, itinerary changes involving a rate difference, only after the reshopping logic had been separately tested against three seasons of rate volatility. That sequencing, narrow first, proven, then widened deliberately, is the discipline this piece has argued for, and it is why containment numbers kept climbing rather than plateauing the way most conversational AI projects do once the novelty wears off. Firms considering the same path should also read our view on why the RFP process fails to surface which vendor can operate at this level, because vendor selection for agentic tooling is a different question from vendor selection for a booking engine, and most procurement teams have not noticed the difference yet.