This is part of an ongoing series on building ucp.travel — an agentic travel stack that lets AI agents search, book, change, and cancel flights autonomously. Built by Almin Zolotic at Zologic.
Last time I wrote about getting an AI agent to autonomously book a flight: search, revalidate, pay, confirm. That was the exciting part.
This week was the less glamorous, but arguably more important, part: what happens after the booking.
Anyone who has built anything in travel knows the booking is only the beginning. The real complexity shows up afterward. The traveler wants to change their flight. The airline changes it for them. The traveler wants to cancel. Dates shift, prices reprice, confirmation windows expire. A real travel platform has to handle all of this without falling apart — and without making the traveler feel like they are operating blind.
That is what we spent the week building.
The three moments that matter after a booking
There are really three post-booking scenarios that define whether a travel platform feels like a product or a prototype.
Voluntary cancellation — the traveler decides to cancel and needs to understand the consequence before committing.
Airline-initiated change — the carrier reschedules or changes the trip, and the platform has to reflect that clearly instead of pretending the booking is still unchanged.
Voluntary change — the traveler wants a different flight, and the system has to guide them through a preview, a confirmation step, and any additional payment required, without ambiguity about what is final and what is not.
All three are multi-step flows. None should happen in a single call. And none should complete without the traveler knowing exactly what they are confirming.
Making irreversible actions feel safe
The principle we kept coming back to was simple: anything irreversible should be preceded by a preview.
The traveler should see what will happen, have a chance to pause, and only then confirm. If the preview expires before they act, the system should catch that and ask them to start again — rather than proceeding with stale information.
That sounds obvious, but implementing it correctly takes real discipline. There are a surprising number of places where a system can skip the preview, auto-confirm, or fail to communicate that a confirmation window has closed. We closed those gaps and added guards at multiple layers, so that if one check is bypassed, the next one still catches it.
The same principle applies to how the system talks about fare conditions. A fare being labelled refundable is a policy statement — not a guarantee that the system can execute a refund right now. We changed the platform to check live booking state before promising that change or cancellation is available. If a booking cannot be serviced through the current interface, the traveler now hears that clearly instead of getting a confusing error after the fact.
Airline-initiated changes were the hardest part
The scenario that took the most care was airline-initiated change.
When an airline changes a trip, the platform receives an event and has to decide what to do. The wrong answer is to handle it silently. Airline changes can involve new flight times, a different aircraft, or sometimes different routing — none of which the traveler has agreed to.
The right answer is to surface the change clearly, show what was originally booked versus what is now being proposed, and ask the traveler to review before anything is accepted or rejected.
We built that escalation path properly, made sure the platform re-fetches fresh booking state before presenting the change, and validated the full flow end to end against real provider behavior.
Settlement honesty matters too
One smaller change that mattered a lot was how cancellation refunds are communicated.
In many travel products, cancellation language implies the traveler will simply get money back to their card. In our model, the commercial reality is different — settlement happens through the platform's billing arrangement with operators.
Those are not the same thing, and conflating them would be misleading.
So the platform now communicates cancellation in terms of service status: the booking is cancelled, and any applicable credit or adjustment is handled through the billing arrangement. It no longer implies a direct traveler refund where that is not actually the right commercial interpretation.
Small wording change. Matters a lot for trust.
How we know it actually works
The thing I am most satisfied with this week is not just the feature list.
It is that we did not stop at "it works locally."
We exercised the full booking lifecycle — booking, changing, cancelling, and handling airline-driven changes — against live provider responses, step by step, until we had confirmed outcomes for every scenario.
That shifted the project from "we think this works" to "we know these core flows work."
There is a meaningful difference between code that looks correct and a system that has been proven to behave correctly under real conditions. This week we crossed that line for the servicing layer.
What is next
The immediate next track is operator tooling: giving the people running travel programs visibility into booking settlement, billing data, and the ability to manage their travelers' bookings with confidence.
The AI agent layer is now in a healthy place.
Now the work is turning that foundation into a full product for the humans operating on top of it.
More soon.
Almin Zolotic is the founder of Zologic and building ucp.travel — an agentic travel stack that lets AI agents search, book, change, and cancel flights autonomously. Follow the build here on dev.to.
