AI agents and airline retailing: selling offers and orders an agent can trust

Two shifts are colliding in air travel, and most of the agent conversations only notice one of them. The visible one is the shopping agent: a traveler tells an assistant “get me to Lisbon next Thursday, aisle seat, I have status,” and the agent searches, ranks, pays, and confirms. We’ve written about building that booking agent so it doesn’t quote a fare it invented, the buyer’s side of the counter.

The shift underneath it is bigger and less discussed: the airlines are rebuilding what’s being bought. The fare, the e-ticket, and the Passenger Name Record, the three separate records that have run airline retailing for decades, are being torn out and replaced with two concepts: the offer and the order. This is the airline’s side of the counter, and it’s where an AI agent’s usefulness is decided long before any shopping bot shows up. Point an agent at a modern airline retailing stack and it can do real work. Point one at the legacy fare filing and it can only lie fluently about what’s for sale. This post is about that stack: what NDC and ONE Order change, where an agent belongs in it, and the boundary that keeps the agent honest.

What NDC and ONE Order are

Strip the acronyms and there are two IATA-led programs doing two jobs.

NDC, New Distribution Capability, is the distribution standard. It’s an XML-based messaging schema built around offers and orders that lets an airline construct and distribute rich, personalized offers through any channel, not just the fare-and-availability abstraction the old GDS pipes could carry. The point of NDC is that the airline, not the intermediary, assembles the offer, flight plus bags plus seat plus lounge plus whatever else, and controls how it’s priced and presented. Adoption is no longer fringe: NDC accounted for roughly a quarter of indirect airline ticket sales globally in early 2026, up from about 11% in 2023. It’s mainstream now, and still climbing.

ONE Order is the fulfillment and accounting standard that finishes the job NDC starts. Today an airline juggles three records for one trip: the PNR (the booking), the e-ticket (the flight document), and the EMD, the Electronic Miscellaneous Document that records ancillaries like a checked bag or a paid seat. ONE Order collapses those three into a single order record that holds the whole trip and every service on it, the way any other retailer has a single order for a cart of items. That single record is what finally lets an airline account for a lounge pass, airport parking, or fast-track security the same way it accounts for the flight: one order, one source of truth, one lifecycle.

The transition is gradual and airline-specific. There is no industry-wide date when PNRs and e-tickets switch off; each airline runs its own migration, which is exactly why “does this carrier have an order-based backend yet” is the first question that decides what an agent can do.

An offer is what the airline is willing to sell you, constructed and priced in the moment. An order is the record of what you bought. Everything an agent can safely do in airline retailing is downstream of whether those two exist as real, queryable objects, or whether they’re still faked on top of fare classes and ticket numbers.

Why this is the thing that makes an agent useful

Here’s the connection the shopping-bot hype skips. An AI agent, whether it’s the airline’s own servicing agent or a third-party assistant shopping on the traveler’s behalf, needs to reason about what’s for sale, right now, for this specific person. In the legacy world, that meant filed fares, booking classes, availability, and a tangle of fare rules that even humans get wrong. An agent trying to construct a personalized bundle out of that is guessing, and a guessed fare is a liability the moment the airline has to honor it or explain why it won’t.

In an offers-and-orders world, the airline’s retailing engine has already done the hard part: it constructs a priced, personalized, purchasable offer and exposes it as structured data. The agent’s job shrinks to what agents are good at (understanding the traveler’s intent, ranking real offers against it, and orchestrating the purchase) instead of reverse-engineering a price from fare filings. An offer looks, in shape, like this (illustrative, not a specific carrier’s schema):

{
  "offer_id": "OF-7731-AA",
  "expires": "2026-09-01T18:42:00Z",
  "passenger": { "loyalty_tier": "Gold", "preferences": ["aisle", "extra_legroom"] },
  "items": [
    { "type": "flight", "segment": "LIS-JFK", "cabin": "Y",
      "price": 612.00, "currency": "USD" },
    { "type": "seat", "code": "14C", "attr": "extra_legroom", "price": 48.00 },
    { "type": "bag", "code": "BAG1", "price": 0.00, "note": "waived_gold" },
    { "type": "lounge", "code": "LNG", "price": 35.00 }
  ],
  "total": 695.00,
  "fulfillment": "order"
}

Every price in there came from the airline’s offer engine, with an expiry and a loyalty context baked in. The agent didn’t compute the $48 seat or decide the bag was free for a Gold member. It retrieved an offer the airline stands behind, exactly the way a well-grounded agent should. This is the same principle as grounding a booking agent in real inventory instead of letting it invent a fare: the difference is that ONE Order gives the agent a real object to ground on, where the legacy stack gave it fare rules to hallucinate around.

The retailing stack, and where the agent sits in it

An airline retailing architecture in an offers-and-orders world has layers, and it matters which one you’re putting an agent in:

The Offer Management System constructs and prices offers: continuous pricing, dynamic bundling, personalization. This is the domain of the offer-and-order platforms carriers buy: PROS, and the offer-order stacks from the big PSS and GDS vendors like Amadeus and Sabre. It is not a place you put a generative agent to decide prices.
The Order Management System creates, holds, changes, and fulfills the order across its lifecycle: the ONE Order record and everything that happens to it.
The servicing and relationship layer (the CRM, loyalty, care, and marketing systems) is where the airline knows who the customer is across every trip, not just this booking.
The agent layer sits across the servicing and shopping surfaces: answering, changing, re-shopping, resolving.

The agent’s home is the servicing and relationship layer, reaching into the offer and order systems through their APIs, never replacing them. A servicing agent can look up an order, explain what’s on it, initiate a change (a paid seat upgrade, an added bag, a voluntary rebook), surface a relevant offer at the right moment, and handle the loyalty questions: all grounded in the real order and the real offers the engine produces. What it must not do is become the offer engine. When a traveler asks to change a flight, the agent doesn’t price the change; it requests a re-shopped offer from the engine and presents it. The price is always the engine’s, never the model’s.

This is also where the airline’s own agent has an advantage a third-party shopping bot never will: it knows the customer. A unified customer profile in Data 360(every past trip, every ancillary bought, every disruption suffered, resolved across loyalty and service and booking sources through identity resolution) is the personalization input that makes an offer feel bespoke instead of generic. The offer engine constructs and prices; the customer profile tells it for whom. That’s the split that makes airline personalization work without the agent touching the price.

Where Salesforce fits, and the line it must not cross

If the airline runs its customer relationship, loyalty, and service on Salesforce, the agent story has a natural home, and a hard boundary. Salesforce is the servicing and relationship layer, not the retailing engine. Concretely:

Data 360 unifies the customer across booking, loyalty, service, and marketing sources into one profile the agent and the offer engine can both reason about.
Agentforce runs the servicing agent (order lookups, change initiation, ancillary offers surfaced in context, loyalty servicing, proactive care) as governed actions grounded in the order.
The offer and order engines stay where they are. Salesforce does not construct offers, does not price fares, does not own inventory, and does not fulfill the order. It calls the systems that do.

Cross that line and you get the airline version of every failed AI project: an agent confidently quoting a price the revenue-management engine never approved, on inventory it can’t hold. It’s the same honest split we draw for supply chain, where Salesforce runs the commercial response but never fakes the planning optimizer, and for tour operators, where no single supplier owns the trip and the agent must revalidate before it commits. The agent orchestrates and communicates; the engine of record owns the number. An agent that respects that boundary is useful. One that doesn’t is a liability wearing a service uniform.

The disruption case is different, and already covered

One servicing scenario deserves its own callout because it’s where airlines feel the most pain: irregular operations. When a flight cancels, the order has to be re-fulfilled fast across every affected passenger, against regulated entitlements. That’s a distinct workflow with its own rules and its own boundary: the airline’s operational systems own the re-accommodation, and the agent owns the speed and the communication. We’ve mapped it in full in AI agents for airline disruption, and everything there compounds with an order-based backend: a single order record makes re-accommodation cleaner than juggling a PNR, an e-ticket, and a fistful of EMDs. Retailing and disruption are two faces of the same order.

The agentic-shopping wildcard

Worth naming, because it’s coming fast: the buyer’s agent. Conversational shopping assistants that search live inventory across airlines, weigh preferences and loyalty, apply payment, and confirm are moving from demo to product, and protocols for machine-to-machine commerce, including the Model Context Protocol showing up in airline distribution, are starting to define how an external agent consumes an airline’s offers. For the airline, this is the strategic reason offers and orders matter beyond internal efficiency: if your inventory is only reachable as legacy fares, the shopping agents of the near future can’t cleanly buy from you, and they’ll rank the carriers whose offers they can parse. An offers-and-orders backend isn’t just a servicing upgrade. It’s how you stay sellable in a world where a lot of the shopping is done by software.

What to build first

The order of operations is unglamorous and correct. First, know your carrier’s retailing maturity. Is there a real order object, or is ONE Order still a roadmap and everything’s faked on ticket numbers? That answer bounds everything. Second, put the agent in the servicing layer, grounded in the order and the offer engine’s output, with the price always coming from the engine. Third, feed it a unified customer profile so the personalization is real. Model the servicing deflection and the ancillary attach the agent can drive, the Agentforce ROI calculator is built for that kind of case math, before you scope the build.

The airlines that win the agent era won’t be the ones with the cleverest chatbot. They’ll be the ones whose retailing stack produces offers and orders an agent can reason about, sell, and service, with the price owned by the engine and the relationship owned by the CRM. Get that architecture right and the agent is a genuine advantage. Get it wrong and you’ve automated the confident invention of fares you’ll have to honor.

Understanding the basics

What is the difference between an offer and an order in airline retailing?

An offer is what the airline is willing to sell: a priced, personalized, time-limited bundle of flight and ancillaries constructed by the offer-management engine in the moment. An order is the record of what the customer bought and the single object the airline fulfills and accounts for across the trip’s lifecycle. NDC standardizes how offers are distributed; ONE Order standardizes the single order record that replaces the legacy PNR, e-ticket, and EMD.

What does ONE Order replace?

ONE Order replaces three separate legacy records that today represent one trip: the PNR (the booking), the e-ticket (the flight document), and the EMD or Electronic Miscellaneous Document (which records ancillaries like bags, seats, and lounge access). It collapses them into a single customer order record, which lets an airline manage and account for flights and ancillaries uniformly. The transition is gradual and each airline runs it on its own timeline.

Should an AI agent set airline prices?

No. Pricing and offer construction belong to the airline’s revenue-management and offer-management engine, which produces priced, personalized offers as structured data. An AI servicing agent should retrieve and present those offers, initiate changes that trigger a re-shopped offer from the engine, and orchestrate the purchase, but the price must always come from the engine, never from the model. An agent that quotes a fare it generated is a liability the airline has to honor or explain.

Figuring out where an agent belongs in your retailing and servicing stack, and where the offer engine has to stay in charge, is a normal first conversation for our team. Talk to us about grounding a travel agent in real offers and a real customer profile instead of a hallucinated fare.