AI travel agents: what agentic booking means and what it needs from your travel systems.

What is an AI travel agent?

An AI travel agent is software, usually built on a large language model, that takes a travel request in plain language and carries out some or all of the work a human agent would do. The term covers a wide range of products, so it helps to separate three levels.

• Assistants answer questions, suggest destinations and draft itineraries. They may show prices, but a person clicks through to book elsewhere.
• Shopping agents search live inventory, compare options and prepare a booking, then stop for the traveller to confirm and pay.
• Autonomous (agentic) agents complete the transaction: they hold the offer, take payment within limits the traveller set, create the booking and can later change or cancel it.

The word "agentic" refers to that last step: software taking actions, not just giving advice. In 2026 most consumer products sit at the first two levels, and fully autonomous booking is still limited to a few supply partnerships.

The same technology also works inside agencies. An AI agent can read an emailed request, run searches across the agency's suppliers and return a shortlist for a consultant to approve. That is less visible than a chatbot, but it is where many travel companies start.

What AI agents need from travel systems

An AI agent is only as reliable as the systems it calls. A language model can phrase a request well, but it cannot invent a valid fare, a seat or a refund rule. It needs five things from the booking platform underneath it.

1. Structured offers and orders

Agents work best with content that arrives as clearly labelled data: a priced offer with its fare brand, baggage, change conditions and expiry time, and an order that can be retrieved and changed later. This is the direction of IATA's airline retailing programme, built on NDC for offers and ONE Order for fulfilment. Traditional GDS content can be used too, but fare rules often come back as free text that an agent must interpret. For how the two channels differ, see NDC vs GDS.

2. Reliable availability and pricing

An agent that quotes a price must be able to confirm it before payment. That means a pricing or offer-confirmation call immediately before booking, and clear handling when the price has changed or the seat has gone.

3. Servicing

Travellers do not stop at booking. They change dates, add bags, cancel and ask for refunds. An agent that can book but not service hands the hardest part back to people, so servicing APIs (retrieve, reprice, reissue, refund) matter as much as shopping.

4. Payments and authorisation

The agent needs a way to pay that the card schemes and the traveller both accept, with spending limits and proof of what the traveller approved. This is covered in more detail under risks below.

5. A clear split between cached and live data

Many travel platforms answer searches from cached fares to protect suppliers from search load. AI agents can generate far more searches per booking than a human, which pushes up the look-to-book ratio and supplier costs. A sound design lets the agent browse cached results, then forces a live price check before it shows a final price or takes payment.

Model Context Protocol: the plumbing behind many launches

The Model Context Protocol (MCP) is an open-source standard for connecting AI applications to outside tools and data. A travel company that publishes an MCP server describes its functions (search flights, get hotel offers, create booking) in a format AI clients such as ChatGPT and Claude can call directly.

MCP does not replace a travel API. It is a layer on top of one: the MCP server translates the agent's tool calls into the supplier's own API requests and returns structured results. If the underlying API is slow, incomplete or unable to service bookings, the MCP layer inherits those limits.

OpenAI's apps in ChatGPT, announced on 6 October 2025, are built on MCP, which is one reason travel companies began publishing MCP servers through 2026.

Real examples from 2025 and 2026

The table lists announcements we verified against the company's own release or reputable trade press. Note the last column: in most cases, the final booking or payment still happens with the supplier.

Two patterns stand out. First, the large AI platforms prefer not to become the seller: Google says the hotel or booking platform remains merchant of record. Second, fully in-chat flight booking so far relies on a GDS doing the heavy lifting, which shows how much of the work sits in the travel API rather than the model.

Risks and open questions

The main risks are not about whether the model can hold a conversation. They are about money, accuracy and responsibility.

• Hallucinated prices and rules. A language model can state a fare or a refund policy that does not exist. In Moffatt v. Air Canada (2024), a Canadian tribunal held the airline liable when its website chatbot gave wrong information about a bereavement fare, and rejected the argument that the chatbot was responsible for its own words. Prices and rules shown by an agent should come from the API response, not from the model's text.
• Payments and PCI DSS. PCI DSS applies to any entity that stores, processes or transmits cardholder data. An AI agent that handles card numbers brings its whole pipeline into scope. Most launches avoid this by using wallets (Google Pay, PayPal) or tokens. Visa and Mastercard announced agent payment programmes in April 2025, and Google published the Agent Payments Protocol (AP2) in September 2025, which records the traveller's instructions as signed mandates.
• Liability and consent. If an agent books the wrong date or a non-refundable fare, someone pays. Agencies need a record of what the traveller approved, and terms that say who is responsible for errors.
• Airline distribution rules. Airlines decide who may sell their content and how. Screen-scraping airline websites is contested: Ryanair won a 2024 US jury verdict against Booking.com, which the court overturned in January 2025 on the damages threshold. An agent that books through approved channels (GDS, NDC, airline APIs) avoids that fight.
• Search load. Agents can multiply searches per booking. Expect suppliers to tighten look-to-book limits and to charge for excess shopping.

What travel agencies should do now

Agencies do not need to build their own model to benefit. The useful steps are mostly about data and process.

1. Clean up your content sources. Know which suppliers return structured fare rules, baggage and change conditions, and which return free text.
2. Put a live price check before every payment. Whether a human or an agent books, never charge on a cached price.
3. Start internally. Use AI to triage email requests, draft itineraries and pre-fill searches, with a consultant approving each booking.
4. Keep payment out of the model. Use tokenised payment, wallets or deposit balances, and keep card data in your PCI-compliant payment flow.
5. Log approvals. Store what was offered, what the traveller accepted and when, so disputes can be settled from facts.
6. Watch the channels. If your customers start arriving from AI platforms, decide whether to publish your own MCP server or work through partners that already have one.

Where ReservationHub fits

An AI agent needs a travel API with content and servicing behind it. The TripGic Travel API is a REST/JSON API that gives developers access to the same content as the ReservationHub platform: Amadeus, Sabre and Travelport, NDC through aggregators such as Verteil, Duffel, Travel NDC and Babylon NDC, and low-cost carriers through Travel Fusion. The full list of 110+ integrations is on the partners page.

Agencies that want a ready platform rather than an API can use the Subscription Cloud Edition, and enterprises that want to own the code can take the Source Code Edition. On payments, ReservationHub's security credential is PCI DSS through the IATA PCI DSS programme.