Agentic Travel Reference Architecture

In agentic travel, an AI agent does more than call search. The architecture must bind user intent safely to search, offer, reprice, confirmation, payment, booking and servicing lifecycles.

Reference architecture

Agentic travel transaction flow

Mermaid source (.mmd)

Separate intent from transaction

A request to find flights is search intent. Even "buy this" should not automatically collapse into unrestricted payment authorization.

Model SearchIntent, SelectionIntent, PurchaseIntent, PaymentAuthorization, BookingIntent and ServicingIntent separately.

Agent planning boundary

The agent can select tools, compare offers, trigger reprice and request confirmation. Side-effecting booking/payment actions should sit behind explicit policy gates.

Tool layer

Expose travel capabilities through canonical tools such as search, reprice, create booking, retrieve booking, cancel, quote refund and refund. Do not expose raw provider DTOs directly to the agent.

Offer selection evidence

Persist why the agent proposed an offer: user constraints, price, refundability, baggage/ancillaries, timing, provider confidence and freshness. This is audit evidence, not merely ranking metadata.

Reprice is mandatory

Do not book directly from a stale search result. Reprice, confirm availability and surface changed price/policy before transaction.

Confirmation / mandate gate

Before side effects, preserve exactly what the user authorized: product, amount, currency, supplier, cancellation terms, delegated limits and expiration.

Separate payment and booking state

Agentic flows do not remove classic travel distributed-transaction problems. Payment can succeed while booking remains UNKNOWN, and the agent must not summarize that as a completed purchase.

Idempotency

Agent loops and tool retries can duplicate side effects. Use deterministic operation-scoped idempotency keys tied to purchase intent and version.

Human-in-the-loop checkpoints

Useful checkpoints include price changes, non-refundable products, high penalties, delegated-limit breaches, passenger/document requirements and any attempt to create a replacement booking while the first remains UNKNOWN.

Servicing agent

Post-booking agents can retrieve, quote changes, quote cancellations, check refunds and handle schedule changes, but mutations still require authorization and idempotency.

Protocol boundaries

• MCP: tool/resource discovery and invocation.
• A2A: coordination between agents.
• ACP/UCP: commerce interaction and checkout capabilities.
• AP2: payment authorization and evidence for agent transactions.
• MPP/x402: machine-native payment rails/use cases.

These protocols solve different layers of the system.

Failure modes

Stale offer booking, duplicate transactions from retry loops, missing confirmation evidence, delegated-limit breaches, excessive PII exposure, treating UNKNOWN as FAILED and stale servicing state.

Observability

Track agent tool traces, intent-to-confirmation conversion, reprice changes, mandate rejection, booking UNKNOWN, duplicate-prevention hits, delegated-payment use, human intervention and servicing success.

Production checklist

Use explicit intent models, canonical tool contracts, reprice gates, authorization evidence, human-in-loop policy, idempotency, separate payment/booking state, PII boundaries, end-to-end correlation and servicing/reconciliation tools.