Production workflows / Guide 03
A Flight Disruption Agent That Does Not Lose the Original Ticket
Build a flight disruption agent that compares viable itineraries, confirms passenger consent, and reconciles ticket exchanges without duplicate bookings.
Illustrative engineering guide. Examples are not client deployments, production-ready integrations, or evidence of measured results. Validate the design with your domain and security owners.
Imagine a hypothetical traveler whose delayed first flight makes an onward connection impossible. A support assistant finds an earlier arrival through another airport and announces that the problem is solved. But the new route changes terminals overnight, separates a child from the accompanying adult, and leaves the original ticket untouched. Finding flights is not the same as recovering a journey.
A flight disruption agent should construct a feasible recovery proposal and coordinate authorized execution. The hard engineering problem is preserving the passenger’s existing rights and booking state while inventory, prices, and operational conditions change. The conversational layer should make those tradeoffs visible, not conceal them behind a confident itinerary.
Model the Journey, Not a Single Flight
Begin with booking ownership, operating and marketing carriers, ticket references, passenger associations, segment status, and available disruption evidence. Keep the reservation record separate from ticket issuance and ancillary services. A reservation change alone is insufficient evidence that the traveler has a usable replacement ticket.
Feasibility rules need connection constraints, airport changes, local dates, baggage assumptions, assistance requirements, and group integrity. Use verified carrier or reservation-system rules rather than asking the LLM to estimate minimum connection times. Where transit eligibility is uncertain, request review through an appropriate travel specialist rather than predicting immigration admissibility.
Passenger preferences are also constraints. “Arrive before the meeting” does not authorize an additional charge or an overnight ground transfer. Record maximum accepted cost, acceptable arrival window, cabin restrictions, and whether splitting a party is permitted. A preference inferred from an old trip should be confirmed before affecting this one.
Separate Candidate Generation From Execution
Use a booking lookup adapter, disruption feed, itinerary search adapter, deterministic feasibility filter, and exchange coordinator. The LLM turns the surviving candidates into understandable alternatives: earliest arrival, least disruption, or lowest additional cost. It should not invent inventory, construct fare rules, or select a paid alternative without consent.
This illustrative internal proposal contract is not an airline API. Production adapters must map it to supported reservation and ticketing operations, with provider-specific authorization and error handling.
{
"proposal_id": "proposal_demo_41",
"booking_version": "v12",
"passenger_refs": ["adult_demo", "child_demo"],
"candidate_ref": "offer_demo_73",
"expires_at": "2026-09-07T11:05:00Z",
"additional_cost_minor": 0,
"currency": "USD",
"party_must_stay_together": true,
"requires_human_exchange": true,
"execution_state": "awaiting_consent"
}Bind consent to the proposal identifier, passenger set, price, and booking version. If any material field changes, invalidate consent and present the revised proposal. An expired offer must be repriced or researched; it must not be treated as a reservation merely because its identifier still exists in conversation history.
A specialist fare-analysis component can earn its complexity when carrier-specific exchange rules differ enough to need separate evaluation and ownership. It still returns a recommendation with source evidence. Search and ticket retrieval are tools. Adding independent conversational agents for each flight leg can actually weaken consistency by losing party-level constraints.
Keep the Original Until the Replacement Is Real
The execution sequence depends on the ticketing provider. Prefer its supported atomic exchange workflow. If exchange requires multiple steps, represent them durably: authorized, submitted, outcome unknown, ticket verified, ancillary review, complete. Never assume that issuing a cancellation followed by an unrelated purchase is an equivalent operation.
When a ticketing call times out, freeze additional writes for that booking and reconcile using the provider’s operation reference. RFC 9110 defines HTTP retry semantics, but it does not promise business-level idempotency for a ticket exchange. The adapter needs a documented provider guarantee or a read-before-retry recovery procedure.
Verify ticket status and segment associations after execution. Then reconcile seats, baggage purchases, assistance requests, and notifications. If a seat assignment fails after successful ticketing, retry or escalate the seat operation rather than buying another ticket. Tell the traveler precisely which parts are confirmed and which need attention.
Do not encode universal compensation or refund entitlements from memory. Rules depend on itinerary, jurisdiction, carrier obligations, and circumstances. Maintain reviewed policy content with effective dates and route uncertain cases to authorized staff. This reference design is an engineering workflow, not a legal determination of passenger rights.
Booking References Are Not Authentication
A booking locator and surname may be widely shared. Establish identity and delegation through the travel platform’s authenticated workflow, then enforce organization and passenger scope on every tool call. OWASP authorization guidance supports server-side checks and least privilege rather than trusting interface restrictions.
Corporate travel coordinators may see only assigned employees, while family bookings can require different consent relationships. Keep those rules explicit. MCP is an integration protocol, not permission to alter reservations. Payment credentials remain in the approved payment system, outside model context.
Treat airline emails, itinerary notes, and disruption messages as untrusted content. An embedded instruction to send passport details to a new address must not become a tool command. OWASP’s injection guidance motivates constrained actions and independent validation; text filtering alone is not a sufficient boundary.
Acceptance Tests Across the Journey
- Search returns one seat for a two-person party that must stay together. The candidate is rejected before presentation, regardless of its attractive arrival time.
- A fare changes after consent. Execution stops and requests new consent with the revised total rather than treating the old approval as unlimited.
- Ticket exchange succeeds but the HTTP response is lost. Reconciliation confirms one replacement ticket and performs no second purchase.
- A malicious itinerary note requests passport export. The export is denied and no passenger data reaches an unapproved destination.
- Ticketing succeeds but baggage reassociation fails. The journey remains partially complete, with a named operator task and an accurate traveler notification.
Measure a Usable Recovery
Baseline manually handled disruptions by carrier, connection count, and party size. Define recovery success as eligible disrupted bookings with verified usable replacement tickets and resolved critical ancillary requirements divided by all eligible disrupted bookings. Track cases still waiting for inventory or human review separately, without removing them to improve the ratio.
Guardrails include duplicate tickets, unauthorized charges, broken party associations, and missed assistance requirements per executed recovery. Measure time from disruption detection to verified recovery, including reconciliation. Start with read-only recommendations for one carrier, then staff-approved exchanges in a bounded booking segment. These are proposed rollout stages, not claims of operational results.
The first implementation task is a booking-state reconciler, not a more persuasive chat prompt. Pair it with the corporate travel guide for policy controls and the executive calendar guide for downstream meeting changes. Backend and API engineering is the relevant foundation for durable exchanges and provider-specific recovery.