An AI agent received a natural language instruction, searched for flights, selected an offer, passed authorization checks, and created a confirmed booking — autonomously, without human input after initial setup.
Today that went from architecture spec to production reality.
What actually happened
At 15:33 CET, on UCPPlayground, we ran the following prompt against our live stack:
"Use search_flights for ZAG to AMS tomorrow. Then immediately call complete_checkout on the first direct offer. Do not explain first."
Two tool calls. Eight seconds.
The agent searched. The agent booked. A confirmed booking reference came back. We opened the travel provider dashboard and the order was sitting there — confirmed, with a PNR, an e-ticket, passenger details, everything.
No human touched the booking flow after the initial traveler setup.
Why this is harder than it sounds
Anyone can wrap a travel search API in an MCP tool and call it "AI travel booking." That part is easy.
The hard part is everything that happens between search and confirmed booking:
Offers expire. Flight fares are perishable inventory. An offer returned from search may be gone in 15–30 minutes. No LLM checks this unprompted — it will try to book an expired offer and get a rejection it doesn't know how to recover from.
Prices change silently. A fare can reprice between the moment the agent sees it and the moment it tries to book. Without a revalidation gate, the agent books at the new price without telling anyone.
Bookings can partially confirm. A travel provider can return an async response — booking accepted, outcome pending. An agent that doesn't understand this state will retry, and retrying a booking call risks a double charge.
Identity and authorization matter. Who is this booking for? What are they allowed to spend? What cabin class? Are they direct-only? Without a mandate layer, an agent has no constraints. It will spend whatever inventory is available.
Document requirements gate certain routes. Some routes require passport details to be validated before an order is created. An agent that doesn't check this wastes a booking attempt and confuses the traveler.
These aren't edge cases. Every one of them will happen in production. None of them are solved by the travel API or the LLM — they have to be solved by the layer in between.
That's what we built.
The stack
We built UCP Travel — a travel transaction layer that sits between AI agents and travel inventory.
It implements:
- UCP (Universal Commerce Protocol) — the open standard for agentic commerce, including the full checkout lifecycle
- MCP (Model Context Protocol) — so any MCP-compatible agent can discover and call our tools
- AP2 (Agent Payments Protocol) — cryptographically signed traveler mandates that enforce spending limits, cabin class ceilings, and booking constraints before any transaction The traveler sets up once: connects their AI assistant via OAuth, signs a mandate defining their booking constraints, stores their travel preferences. After that, every booking is autonomous within those constraints.
Our capability declarations are public at ucp.travel/.well-known/ucp and verified by UCPChecker — currently the only verified implementation of travel.ucp.mandate in the world.
UCPPlayground now recognizes ucp.travel as the reference pattern for travel-as-shopping — the travel.ucp.* namespace layered over dev.ucp.shopping is the model the ecosystem is converging on.
The UCPPlayground integration
The booking today happened through UCPPlayground — a live testing environment for the UCP ecosystem built by Ben Fisher. It connects real AI models to real UCP endpoints and runs end-to-end agent sessions.
Gemini 2.5 Flash connected to our MCP endpoint, discovered three tools (search_flights, complete_checkout, get_booking), and completed the booking in 3 turns:
Turn 1: search_flights(origin: ZAG, destination: AMS, departure_date: 2026-06-02, max_connections: 0)
Turn 2: complete_checkout(offer_id: off_..., checkout_id: chk_live_1)
Turn 3: [confirmed — PNR returned]
Outcome: purchase_completed. PNR confirmed in the provider dashboard.
What "traveler setup once" actually means
The autonomous booking only works because we solved the identity problem first.
During onboarding, a traveler:
- Creates a profile with travel documents and preferences
- Signs an AP2 Intent Mandate — their authorized booking constraints, cryptographically signed
- Links their AI assistant via OAuth 2.0 Authorization Code flow From that point, every MCP tool call the agent makes carries a bearer token that resolves server-side to the traveler's identity, mandate, and payment profile. The agent never sees raw credentials, card numbers, or passport data. It just calls tools and gets results.
This is the architecture that makes autonomous booking trustworthy — not just technically possible.
What's live now
The multi-tenant operator platform is running. Operators onboard, configure traveler mandates, and connect AI assistants today. Flight booking is live.
Expanding next:
- Stay (hotel) booking alongside flights
- Post-booking servicing — changes, cancellations, ancillaries
- Complete audit trail UI for operators and compliance teams If you're building an AI travel assistant, a travel management platform, or anything that needs to turn travel intent into confirmed bookings — we'd like to talk.
ucp.travel · contact@zologic.nl
Built by Zologic — zologic.nl
UCP spec: ucp.dev · MCP spec: modelcontextprotocol.io · AP2: ap2-protocol.org
Top comments (0)