AI Agents
AI agents for tour operators: dynamic packaging when no single supplier owns the trip
A flight, a hotel, a transfer, and an activity assembled into one trip is a distributed-transaction problem no single API solves, and an agent that books a rate which already moved is a liability, not a feature. Here's the multi-agent architecture that packages across suppliers, revalidates before it commits, and where a human still has to sign.
Selling a package used to mean selling a shelf. A tour operator contracted a hotel block, a charter seat allocation, and a transfer, wrapped them in a brochure price, and sold the same bundle a thousand times. Dynamic packaging tore up the shelf: now the trip is assembled at query time from independently-sourced components (a scheduled flight from a GDS or an airline’s NDC feed, a hotel room from a bedbank at a net rate, a transfer from one API, an activity from another, insurance from a fifth) priced, held, and booked together as if they were one product. They are not one product. They are five suppliers who have never met, don’t share a schema, and won’t commit as a unit.
That gap is where an AI agent looks irresistible and where it gets tour operators into trouble. The consumer booking agent gets the keynote, but the operator’s problem is different and harder: not “book this flight” but “assemble this trip across suppliers that each have their own availability semantics, cancellation rules, and rate volatility, and make it hold together at the moment of payment.” Get the orchestration right and an agent compresses hours of manual coordination into a conversation. Get it wrong and it books a hotel against a flight that already sold out, quotes a net rate that moved between the search and the click, or, the one nobody costs in, turns your company into the legally liable organiser of a trip a machine assembled. Here’s the architecture that does the first and structurally prevents the last three.
Why a package is a distributed-transaction problem, not a booking
Start with the fact that reframes the whole build: there is no two-phase commit across airlines, bedbanks, and activity suppliers. When a human packages a trip, they hold the flight, confirm the hotel, book the transfer, and if the hotel falls through they unwind by hand. An agent has to do the same unwinding, except it’s reasoning probabilistically about a set of irreversible, time-sensitive commitments with no shared transaction to roll back.
Three properties of travel supply make this hard, and none of them are AI problems. They’re the terrain the AI has to run on:
- Prices must never be trusted from cache. You cache static content (hotel descriptions, images, geodata) for speed. You do not trust a cached price. Bedbank net rates move with season, occupancy, and promotion; airfares move constantly. The industry pattern is fixed: shop against warm data for responsiveness, then perform a mandatory rate revalidation immediately before payment. Skipping that revalidation is the direct cause of price-change booking failures, and an autonomous agent with no human watching the delta is exactly the actor most likely to skip it.
- Look-to-book economics punish speculative search. Airline look-to-book ratios that used to sit near 10:1 now routinely run toward 1000:1, and GDS and aggregator pricing is frequently tied to your look-to-book ratio. An agent that fans out dozens of speculative searches per request, which is precisely what “monitor the price and rebook if it drops” means, blows through both cost and rate-limit budgets. Caching hot routes and refusing to make calls you don’t need is a hard requirement, not an optimization.
- The booking is not atomic, so partial states are inevitable. Leg one (flight) books; leg two (hotel) fails or its price moved. You are now holding a non-atomic order and must compensate: rebook, re-price, refund, or escalate. This is a saga, not a transaction. Explicit compensation logic for every partial state, because the database guarantee you’d want does not exist across supplier boundaries.
Any agent design that ignores these lands you in the canonical failure: the agent books at a price that changed, or commits to inventory that’s gone, and in travel those mistakes are often non-refundable, time-boxed, and contractually binding. Unlike a retail cart, you frequently cannot just reverse it.
The multi-agent shape: a supervisor and one specialist per supply domain
The wrong instinct is to build one big agent that “does travel.” Expedia tried the single end-to-end concierge with Romie and found it impractical, pivoting publicly to a multi-agentic architecture of specialized, communicating agents, with the explicit emphasis that the competitive edge is real bookable inventory and safeguards against hallucination, not conversational flair. That’s the lesson to copy.
On Salesforce, the native expression of that shape is Agentforce multi-agent orchestration, which went GA in the Summer ‘26 release. A supervisor agent is the single front door; it routes to specialist agents, and the Atlas Reasoning Engine reads each specialist’s description, instructions, and actions to decide which one handles a given sub-task. Map that directly onto the supply domains:
- A Flight specialist that knows how to shop, price, and revalidate air, and knows it lives in two worlds at once (more on that below).
- A Lodging specialist that shops bedbank and direct rates, applies the markup rule, and revalidates net price before commit.
- An Ancillary specialist for transfers, activities, and insurance.
- A Packaging supervisor that owns the trip-level logic: sequencing, the revalidation gate, partial-booking compensation, and the hand-off to a human.
The reason this decomposition matters isn’t tidiness. It’s that each specialist keeps a smaller, cleaner context and a narrower set of actions, which is the same discipline that keeps any complex agent from degrading, and it means the expensive, chatty air-shopping logic is isolated on the one specialist that needs it, instead of inflating every interaction. The supervisor never books anything itself; it orchestrates specialists that do, and it holds the gate.
Reaching suppliers: the action layer that touches the GDS
An agent’s reasoning is worthless if it can’t call a real supplier API. In Agentforce, an agent’s abilities are actions grouped into topics, and actions are built from Flows, Apex invocable methods, prompt templates, or External Service actions. For reaching an external supplier, three of those matter:
- Flow HTTP Callout connects to a REST endpoint with no code. You point it at the supplier’s API, it generates the external service definition, and the operation becomes a callable action. Good for the well-behaved JSON APIs (many activity and transfer suppliers, some direct hotel connections).
- Apex invocable actions with callouts handle the messy cases (the supplier whose auth, pagination, or response shape needs real code) and expose the result to the agent as a clean action. This is also where you put the deterministic work you never want a model doing: the markup calculation, the revalidation comparison, the partial-booking compensation.
- External Service actions can be invoked directly from an agent since Spring ‘25, without hand-building a wrapper per operation, and Named and External Credentials hold the supplier auth so no secret ever lives in a prompt.
The design rule underneath all three is the one that keeps travel agents safe: the model decides whether and what; deterministic code decides how. An LLM should never be the thing that compares two prices, applies a markup percentage, or judges whether a rate is still valid. It orchestrates a comparison that Apex performs and then reasons about the result. For heavier GDS and NDC orchestration (aggregating EDIFACT, NDC, and direct-connect into one bookable flow) MuleSoft is the sanctioned integration layer to front those suppliers as governed APIs; treat that as a recommended pattern rather than a Salesforce-published travel blueprint, because the reference architecture for it is yours to design. Fronting the callouts through a governed integration tier is the same discipline any production integration that has to survive real volume needs; the agent just becomes another consumer of it.
Grounding the trip in who the traveler is
A package agent that treats every request as anonymous produces generic trips. The differentiator is context: this traveler’s loyalty tier, their aisle-seat preference, the fact that they always add travel insurance, the trip they took last spring. That context can’t live in the prompt as a paragraph someone pasted. It has to be grounded from a governed profile.
This is the job Data 360 (formerly Data Cloud) does: unify fragmented sources (booking history, loyalty, CRM, web behavior) into a resolved individual profile through identity resolution rulesets, and make that profile retrievable at reasoning time so the agent grounds its recommendations in real data instead of guessing. The same foundation drives segmentation, so the “package this by trip purpose” logic, a family beach week versus a solo city break, draws on attributes you hold rather than what the model infers from three sentences of chat. The uncomfortable truth every travel team eventually meets is that the data foundation decides the agent’s quality far more than the prompt does: a beautifully-worded packaging agent grounded on fragmented, duplicated traveler records will still recommend the wrong trip.
The revalidation-and-commit gate, and why a human stands on it
Here is the single most important control in the whole design, and it’s where autonomy has to stop. Before any package is paid for, the packaging supervisor runs a revalidation gate: re-price every component live, confirm availability, recompute the total with markup, and compare it to what the traveler was shown. If nothing moved, present the confirmed package. If anything moved (a fare ticked up, a room went, a transfer window closed) the agent does not silently book the new price. It surfaces the delta.
Whether the final commit is autonomous or human-gated is a business decision sized to blast radius, and travel sits at the unforgiving end of that spectrum. The reversibility-and-blast-radius model that should govern any agent action is stark here: a wrong booking is often irreversible, expensive, and legally binding. Salesforce’s own guidance is to keep a human reviewing agent output for the majority of use cases, and the Einstein Trust Layer’s role (grounding, zero data retention with third-party models, an audit trail of what the agent did) is the substrate that makes a human review meaningful rather than a rubber stamp. In practice, the pattern that ships is: the agent assembles, prices, revalidates, and stages the order; a human (or a hard confirmation step above a price-delta threshold) authorizes the payment. The agent does the hours of coordination; the person owns the irreversible click.
There’s a named example of the assistive half working at scale: the business-travel platform Engine deployed an Agentforce agent, “Eva,” and Salesforce reports it fully handled half of chat cases with no human intervention, cut average handle time, and was first built in under two weeks. Read that the right way: the deflected cases are servicing and coordination, the wrapper around the trip, not the irreversible commit. That’s exactly the boundary to design to.
The liability trap nobody costs in
Now the part that turns a technical decision into a legal one. Under the EU Package Travel Directive ((EU) 2015/2302), the moment you combine two or more travel services for the same trip, you can become the organiser, with full liability for the proper performance of the entire package, even when the fault lies with a supplier, plus obligations for alternative arrangements at no extra cost, insolvency protection, and repatriation. “Linked Travel Arrangements” carry lighter but still-real duties.
Sit with what that means for an autonomous packaging agent. Every bundle it assembles can silently convert your company from a retailer of someone else’s services into the legally liable organiser of a trip a machine designed. The agent isn’t just a technical actor making booking decisions. It’s making liability decisions, and it has no idea it’s doing so. This is the strongest possible argument for two things: hard-coded packaging rules the agent cannot reason around (what may be combined, for which markets, under which terms), and a human in the loop on anything that crosses into organiser territory. You encode the rule as a deterministic guardrail, a structural limit the agent cannot exceed, not a polite instruction in a prompt it might ignore under pressure.
The distribution reality: your agent lives in two worlds
One more thing the demos skip. Air content reaches you through parallel stacks that will coexist for years. Legacy GDS EDIFACT is ticket- and PNR-based and settles through IATA’s BSP. Airline NDC is offer- and order-based, carries richer content and ancillaries, and is growing fast, corporate NDC volumes jumped sharply through late 2025, but full Offer and Order distribution and settlement with orders is widely put at a 2028–2030 horizon, not today. Direct low-cost-carrier APIs are a third model entirely.
So a Flight specialist that pretends there’s one clean “book a flight” abstraction is lying to you. It has to straddle ticket-based EDIFACT and order-based NDC simultaneously, with different content, different servicing, and different settlement behind each. That’s not a reason to wait. It’s a reason to isolate air behind its own specialist and its own integration tier, so the rest of the package logic doesn’t inherit the complexity. It’s also why the “package everything through one shiny NDC pipe” pitch is aspirational: the reality you build for is hybrid, and the agent has to be honest about which world a given segment came from.
What ships
The tour operators getting value from agents in 2026 are not the ones who pointed a chatbot at a booking API. They’re the ones who treated packaging as the distributed-systems-and-governance problem it is and added an AI layer on top: a supervisor delegating to per-supplier specialists; deterministic code for pricing, markup, revalidation, and compensation; a governed integration tier fronting the GDS and bedbanks; a Data 360 profile grounding the recommendations; a hard revalidation gate before payment; and a human on the irreversible commit and anything that trips organiser liability. The agent absorbs the coordination that used to eat an operator’s afternoon. The human keeps the decisions that carry money and law.
That’s the unglamorous shape of an agent that survives contact with real inventory. It won’t assemble a trip end-to-end and press “pay” while you sleep, and in travel, an agent that promises to is telling you it doesn’t understand the terrain. The one that does the assembling, revalidates before it commits, and hands you a staged, priced, legally-clean package to authorize is worth far more, because it’s the one you can put in front of a customer.
Understanding the basics
What is dynamic packaging, and why is it hard for an AI agent?
Dynamic packaging assembles a trip in real time from independently-sourced components (flights, hotels, transfers, activities, insurance) instead of selling a pre-built package. It’s hard because those suppliers share no common schema, prices move constantly and can’t be trusted from cache, and there’s no atomic transaction across them: one component can book while another fails or changes price. An agent has to revalidate every component live before payment and run explicit compensation logic for partial-booking states, because the database-style rollback you’d want doesn’t exist across supplier boundaries.
How would you build a packaging agent on Salesforce Agentforce?
Use multi-agent orchestration (GA in Summer ‘26): a supervisor agent routes to specialist agents (one per supply domain (flight, lodging, ancillaries)) with the Atlas Reasoning Engine selecting the specialist. Reach supplier APIs through Flow HTTP Callout, Apex invocable actions with callouts, or External Service actions, with credentials held in Named/External Credentials and heavier GDS/NDC aggregation fronted by an integration tier such as MuleSoft. Keep pricing, markup, revalidation, and compensation in deterministic Apex (the model decides whether and what, the code decides how) ground recommendations in a Data 360 traveler profile, and gate the payment behind a human or a hard confirmation step.
Where does a human have to stay in the loop?
On anything irreversible or legally significant: authorizing the payment, committing non-refundable inventory, handling a disruption or refund, and, critically, anything that crosses into organiser liability under the EU Package Travel Directive, where combining two or more services for one trip can make your company fully liable for the whole package. Encode what may be packaged as hard guardrails the agent cannot reason around, and keep a person on the commit. The agent does the assembly and coordination; the human owns the click that carries money and law.
Can an AI agent book a whole trip autonomously today?
Technically it can execute the calls; commercially and legally you usually shouldn’t let it press “pay” unsupervised. Consumer trust in fully autonomous booking is still low, travel mistakes are often irreversible and binding, and autonomous packaging can silently trigger organiser liability. The high-value, low-risk deployments today are assistive and servicing (assembling and pricing the package, monitoring, answering trip questions, coordinating changes) with the irreversible commit gated. Build for the coordination first; earn the autonomy on the commit later, if ever.
Working out where an AI agent can take over the assembly of a multi-supplier trip and where a human still has to sign, and how to ground it in a traveler profile you can trust? Talk to us, governed automation that stays auditable is the work we do.
