Beyond Booking Automation: How AI Agents Handle Schedule Changes, Refunds, and Ancillary Sales
The operational follow-up to “HaloSync Open Sources an AI Stack” — booking is the cheap part; this is about everything that happens after.
Most “an AI booked my flight” demos end at checkout. A prompt goes in, a confirmation comes out, and the video stops.
But anyone who actually runs a travel business knows the booking is the cheap part. The expensive part starts after the ticket is issued — the schedule change two days before departure, the refund request with a penalty calculation, the seat and bag added at the last minute. That long tail of servicing is where operational headcount quietly goes.
This post is about that tail, and how far an AI agent can take it today with HaloSync’s open-source polarhub-mcp-client.
The real cost is post-booking, not booking
A booking is a single, clean transaction. Post-booking is a stream of exceptions:
- A traveler moves their trip, and someone has to read the fare rules, find the new availability, compute the fare difference, and reissue.
- A refund comes in, and someone has to determine eligibility, apply the right penalty, and process it through the carrier’s servicing flow.
- An ancillary — a bag, a seat, a meal — gets added after the fact, which means another servicing call and another EMD.
NDC was supposed to make all of this programmatic. In practice, every carrier exposes servicing a little differently, so teams either build per-carrier glue or fall back to a human in a portal. The booking got automated; the servicing didn’t.
That gap is the point of this post.
What polarhub-mcp-client actually does
polarhub-mcp-client exposes PolarHub — HaloSync’s unified NDC/GDS backend — as an MCP (Model Context Protocol) server. Once it’s connected, an AI agent can drive the full lifecycle in natural language: not only search → price → book, but the retrieve, change, refund, and ancillary flows that come afterward.
The agent isn’t reimplementing servicing logic. PolarHub absorbs the per-carrier complexity — authentication, request signing, field transformation, carrier-specific exceptions — and the MCP layer hands the agent a clean, conversational interface on top of it.
A walkthrough: retrieve a booking, then change the seat
polarhub-mcp-client — retrieve → select seat → confirm.
Here is the flow shown in the demo above — a paid seat change on an existing booking, driven entirely in natural language:
- Retrieve. The agent pulls up an existing booking by order ID — itinerary, fare rules and penalties, and the ancillaries already attached.
- Select a seat. “I’d like 24A.” The agent reads the seat map, surfaces availability and the additional cost, and prepares the change.
- Confirm. On “yes, confirm the change,” the agent calls the order-change tool and returns the updated booking — new seat, fare difference, and a fresh PNR and transaction reference.
What’s shown here is one concrete example — a paid seat change, i.e. an ancillary servicing flow. The same agent path covers schedule changes and refunds against the same backend; where automation stops and a human takes over is spelled out in the box below. The point to notice: this is the work that normally consumes an ops agent’s afternoon, happening in a single natural-language exchange.
What’s live today, and what isn’t
We are deliberately precise about this, because “an AI handles your refunds” is easy to say and easy to overstate.
Today
- Runs against the HaloSync Sandbox environment (
albus.sandbox.halo-platform.net/sign-up), not production. - Sandbox authentication uses a fixed header key.
- Search, price, book, retrieve, paid seat selection, and the core change and refund tools are live and callable by an agent.
- Some servicing edge cases — complex involuntary reissues, partial refunds with penalty waivers, and certain carrier-specific exceptions — still need a human in the loop.
Roadmap
- Production environment: timing to be announced.
- Per-tenant credential-based authentication.
- Widening the automated envelope so fewer cases require manual intervention.
If a flow isn’t in the “today” list, treat it as roadmap. We would rather you find the boundary in this paragraph than in production.
Why this matters — depending on who you are
If you run an OTA engineering team: you can evaluate servicing automation without building per-carrier change/refund logic yourself. The abstraction lives in PolarHub and is exposed through MCP and a plain REST API, so your team’s job is integration, not NDC archaeology.
If you run a mid-size agency: the point isn’t that NDC is cheaper. It’s that NDC competitiveness reaches your sales and operations without a dedicated engineering build — the servicing your staff does by hand can move into an agent-driven flow.
None of this is a lab prototype. The change, refund, and ancillary flows above have been running in commercial production for seven years — on the same backend, handling this traffic stably, day in and day out.
Try it
- Sign up for the Sandbox:
albus.sandbox.halo-platform.net/sign-up - Connect the MCP client to your AI agent and run the retrieve → select seat → confirm flow yourself.
- Watch the demo to see the agent handle a post-booking seat change in natural language, end to end.
Related reading: for booking automation and the open-source AI stack, see “HaloSync Open Sources an AI Stack.” For route intelligence, see “Albus L2B Management Suite.” This post picks up where booking ends.
Beyond API · Travel Infrastructure as a Service.
