AI agents for airline disruption: re-accommodation that doesn't strand a passenger

A flight cancels at 6 a.m. and 180 people need to be somewhere else. The airline’s operations center already knows which aircraft and crew it’s reassigning — that part is a solved, if painful, optimization problem. The expensive part is everything downstream: 180 passengers who don’t yet know, each needing a new itinerary that respects their fare, their connection, their special-assistance needs, and their legal entitlement to care or a refund. Multiply that by every disrupted flight in a bad-weather morning and you get the scene every airline dreads — hold times in the hours, gate agents overwhelmed, and social media filling with photos of the queue.

That gap between the schedule breaking and the passenger being rebooked is exactly the shape of problem an agent is built for: high-volume, time-critical, rule-bound, and mostly identical case to case. The industry has noticed. A June 2026 report from Amadeus and Microsoft argued that airline operations are shifting from “human-directed with AI assistance” to “AI-directed workflows with human supervision,” and named voice-driven rebooking as one of the fastest paths to value. Finnair has put an Agentforce-built service agent in front of exactly this kind of work, drawing on its loyalty data and booking systems. These are real deployments — and they’re also, importantly, customer-service agents adjacent to the recovery problem, not proof that the whole of irregular-operations recovery is now autonomous. The distinction matters, and getting it right is the difference between an agent that earns trust and one that strands someone.

This post is the honest version: the re-accommodation workflow an agent can genuinely own, the regulated entitlements it has to handle correctly, and the bright line where the airline’s own systems and a human being have to take over.

Why re-accommodation, and not the recovery plan, is the target

IRROPS — irregular operations — is the ops-recovery problem: the published schedule breaks (a cancellation, a long delay, a diversion, an aircraft swap, a crew or maintenance issue, weather, a mass grounding) and passengers already holding tickets have to be moved. Because the change is involuntary — the passenger didn’t ask for it — the airline owns the fix, and re-accommodation onto an alternative comes at no extra charge. This is a different problem from consumer booking. We wrote separately about grounding a booking agent in real fare inventory so it doesn’t invent a price; this is the other side of the trip, when the plan you already sold falls apart.

The instinct is to point AI at the recovery plan — “let the model figure out which flights to cancel and how to re-flow the network.” That’s the wrong target, and it’s not the airline’s bottleneck. Deciding which flights cancel, which aircraft and crew get reassigned, and how the network re-optimizes is the job of Network Operations Control and the airline’s operational systems — a constrained optimization over aircraft, crew legality, and slots that has nothing to do with talking to a customer. That work is already automated inside systems built for it.

The bottleneck is the passenger-facing recovery: taking each disrupted itinerary, finding a valid alternative within fare rules and inventory, telling the passenger before they call, rebooking them, and handling their care and compensation. That’s high-volume, repetitive, and time-critical — and it’s where an agent absorbs the load so human agents can spend their judgment on the hard cases. The same lesson we drew from AML triage and insurance FNOL applies: the agent that clears production first isn’t the glamorous autonomous decision-maker, it’s the one that makes the high-volume, high-frustration work disappear and hands the genuinely hard cases to a human with the context already assembled.

The re-accommodation workflow an agent can own

Here’s the chain when a flight breaks, and who acts at each step. The agent’s lane is the standard, high-volume path; the hard cases route to a human.

1. Detect the disruption and scope the impact. A flight-status or ops feed flags the cancellation or major delay. The agent ingests the event and pulls the list of affected bookings — the passengers, their onward connections, their profiles. It doesn’t decide the cancellation; it reacts to it. This is a textbook case for an event-triggered agent: the signal, not a customer message, wakes it up.

2. Prioritize. Not every passenger is the same urgency — a traveler with a tight international connection, an unaccompanied minor, or a passenger with a mobility device needs handling ahead of a flexible leisure traveler on a long layover. The agent applies a pre-approved prioritization playbook by fare class, loyalty tier, special-service requests, and connection risk. It executes the ranking; a human owns the fairness calls in a genuine mass event.

3. Notify proactively. The agent sends the outbound message — SMS, app push, email, or a voice call — telling the passenger the flight is disrupted and what happens next, ideally before they’ve joined the phone queue. Getting ahead of the call is the single biggest lever on hold-time collapse during a disruption.

4. Search for a valid alternative. The airline’s passenger service system proposes alternates within available inventory, fare rules, and minimum connection times. The agent surfaces the viable single-carrier options and, within tight guardrails, books one. This is the step where the agent is only as good as the system underneath it — more on that boundary below.

5. Rebook and reissue. For standard, single-carrier cases, the agent updates the booking, reissues the ticket, and re-checks the passenger in. Complex reissues and any cross-carrier reroute go to a human.

6. Handle duty of care. Where the passenger is entitled to meals, a hotel, or ground transport, the agent issues the vouchers within policy. Exceptions and edge cases escalate.

7. Trigger the right refund or compensation. Where the entitlement rule is unambiguous, the agent initiates it — a refund when the passenger declines the alternative, or care where it’s owed. Where the entitlement is contested or the rule is fuzzy, a human decides. (This is the part with the most regulatory teeth, so it gets its own section.)

8. Hand off with context. Anything out of policy — an interline reroute, an accessibility accommodation, a distressed passenger — routes to a human agent through Omni-Channel with the full context attached, so the person starts from a complete picture instead of “tell me what happened.”

The entitlements the agent has to get exactly right

Re-accommodation is one of the most regulated moments in the customer relationship, and it differs by jurisdiction. An agent that mishandles an entitlement doesn’t just annoy a passenger — it creates a compliance exposure. Three regimes matter most:

• EU261 (Regulation (EC) No 261/2004). For flights within its scope, EU261 splits into two very different obligations. Care — meals and refreshments once the wait passes a set threshold, plus hotel and transport for an overnight — is owed regardless of the cause, including weather. Cash compensation — tiered at €250, €400, or €600 by flight distance — is owed only when the airline is at fault, not for “extraordinary circumstances” like weather, air-traffic control, or security. That distinction is load-bearing: an agent that offers cash compensation for a weather cancellation is giving away money that isn’t owed, and one that denies care because the delay was weather-related is breaking the rule. Whether the passenger takes a refund or a later re-routing also changes the entitlement.
• US DOT automatic refunds. Under the DOT rule finalized in 2024, when a flight is cancelled or significantly changed and the passenger declines the alternative offered, the airline must issue a refund automatically — in cash or the original form of payment, not a voucher the passenger didn’t choose. “Significant change” turns on defined thresholds (large schedule shifts, an airport change, an added connection, a downgrade, or a switch to a less-accessible aircraft). The precise contours of the “cancelled flight” definition have been the subject of ongoing DOT rulemaking, so an agent’s entitlement logic should read from a maintained policy source and be re-verified against current DOT rules rather than hard-coded once. Separately, the US has no EU261-style cash-compensation statute — its dashboard commitments cover rebooking, meal vouchers, and hotels for controllable disruptions, which is a different thing from a legislated cash payout. Don’t let an agent conflate the two.
• Accessibility (Air Carrier Access Act). A passenger traveling with a wheelchair or scooter can’t simply be rebooked onto any aircraft or route — the replacement has to be able to carry the equipment, and recent DOT rulemaking tightened the obligation to rebook at no cost and provide accessible ground transport when a device can’t be accommodated. This is precisely why accessibility cases are a human-owned lane: the cost of getting it wrong is both a stranded passenger and a regulatory violation.

The design implication is the same across all three: entitlement rules are policy the agent applies, not judgment it invents, and the consequential or ambiguous entitlement decision belongs to a human. This is the human-in-the-loop discipline in a regulated setting — decide which decisions require a person, when they enter, and what they see.

The line you never cross

Beyond the entitlement calls, three parts of re-accommodation stay firmly human, and designing the agent around them is what keeps it safe:

• Interline and codeshare rebooking. Placing a passenger on a partner carrier’s flight isn’t a software toggle — it depends on commercial interline agreements and revenue-settlement mechanisms between airlines that a servicing layer can’t substitute for. An agent can rebook confidently within a single carrier’s own inventory; the moment the only good option is another airline’s seat, that’s a human’s call.
• Accessibility and special assistance. As above — device compatibility, medical needs, and unaccompanied minors carry duty-of-care obligations that don’t reduce to a rules table.
• The recovery plan itself. The agent does not decide which flights cancel or how the network re-flows. It rebooks passengers against the inventory and options the airline’s own systems expose, nothing more.

That last point is the honest architecture note that a lot of vendor enthusiasm skips.

Where Salesforce fits — and where it doesn’t

Be clear-eyed about the stack, because this is where the pitch tends to over-reach. Salesforce is not your passenger service system, and it is not your recovery optimizer. The authoritative inventory, the fares, the PNRs, and the re-flow computation live in the airline’s PSS — Amadeus Altéa, Sabre, or Navitaire, depending on the carrier — and in Network Operations Control. An agent built on Salesforce can only rebook against the inventory and fares the PSS exposes; it does not compute the recovery. Pretend otherwise and you’ve built an agent that confidently offers seats the system of record doesn’t have.

Where Salesforce genuinely earns its place is the passenger-facing servicing, communication, and case layer around those systems:

• Agentforce hosts the service and voice agents that notify passengers, run the rebooking dialogue, and act within guardrails.
• Service Cloud models each disruption interaction as a case and routes the human handoffs through Omni-Channel with context intact.
• Data 360 (renamed from Data Cloud in October 2025) unifies the passenger profile, itinerary, and loyalty data into the single record the agent reasons over — the difference between an agent that knows this is a top-tier flyer mid-connection and one that treats every ticket the same.
• MuleSoft is the integration layer that lets the agent read the flight-status and inventory feeds and write rebookings back into the PSS through governed APIs, rather than screen-scraping.

The honest division of labor: the PSS and NOC own the recovery and the inventory of record; Data 360 grounds the passenger context; Agentforce services, notifies, and rebooks within policy; and a human handles interline, accessibility, and the genuinely hard cases. Building it as if Salesforce were the PSS is one more entry in the catalog of reasons agent projects fail: wrong system of record, ungrounded confidence, and a boundary nobody drew.

The failure modes that decide whether this works

Four things bite in production, and they’re worth designing against from day one:

• Stale inventory, confident wrong answer. In a mass disruption, seats move fast and inventory locks expire. An agent working from a slightly stale view can “confirm” a seat that’s already gone — a worse experience than making the passenger wait. The rebooking action has to hold and verify inventory at the moment of commit, not trust a read from thirty seconds ago.
• Scale. A single bad morning can disrupt thousands of bookings simultaneously, and the whole engine is gated by how well the underlying PSS APIs handle concurrent load. An agent that’s brilliant one-to-one and falls over at a thousand concurrent rebookings hasn’t solved the problem that matters.
• Contact-data quality. Proactive notification is only as good as the passenger contact records. Incomplete or stale contact data quietly cripples the highest-value part of the workflow — which is why the data-quality groundwork is a prerequisite, not an afterthought.
• Notification fatigue and premature confirmations. Over-messaging during a volatile ground stop erodes trust; a premature “you’re rebooked” that later reverses is worse than silence. The agent should message on genuine state changes, and never confirm an action the system of record hasn’t actually committed.

Get those wrong and the agent that was supposed to reduce hold times becomes the reason for a complaint.

The takeaway

Airline disruption is one of the clearest agentic use cases in travel, because the passenger-facing recovery work is high-volume, time-critical, rule-bound, and mostly identical case to case — while the genuinely hard parts are few and well-defined. The pattern that works: let the operations systems own the recovery plan, put an agent in front of the passenger to detect the disruption, prioritize, notify proactively, rebook the standard single-carrier cases within fare and inventory rules, and handle clear-cut care and refunds — then route interline, accessibility, and the ambiguous entitlement calls to a human with the case already built. Get the regulated entitlements exactly right by reading them from maintained policy rather than hard-coding them, verify inventory at the moment of commit, ground the agent on real passenger and itinerary data, and never let it claim to be the system of record it’s only reading from. Do that and you close the gap between the schedule breaking and the passenger being taken care of — which was the whole problem to begin with.

Understanding the basics

What is IRROPS re-accommodation?

IRROPS — irregular operations (also written IROPS) — is what happens when an airline’s published schedule breaks: a cancellation, long delay, diversion, aircraft swap, or mass disruption. Re-accommodation is the process of moving already-ticketed passengers onto alternative flights. Because the disruption is involuntary — the passenger didn’t request the change — the airline owns the fix and rebooks at no extra charge, subject to inventory, fare rules, minimum connection times, and the passenger’s entitlements to care, refunds, or compensation. It’s an operations-recovery problem, distinct from ordinary booking.

Can an AI agent rebook passengers during a flight disruption?

Yes, for the standard, high-volume path, and with a human for the hard cases. An agent can detect the disruption, prioritize affected passengers, send proactive notifications, find and book a valid single-carrier alternative within fare and inventory rules, reissue the ticket, and handle clear-cut care and refunds. What stays human: rebooking onto another airline (interline, which depends on commercial agreements), accessibility and special-assistance cases, and any ambiguous or contested entitlement decision. The agent rebooks against the inventory the airline’s passenger service system exposes — it does not compute the recovery plan itself.

What compensation are passengers owed when a flight is disrupted?

It depends on jurisdiction, which is why an agent must read entitlements from a maintained policy source. Under EU261, “care” (meals, and a hotel for overnights) is owed regardless of cause, while tiered cash compensation (€250/€400/€600 by distance) is owed only when the airline is at fault, not for extraordinary circumstances like weather. In the US, DOT rules require automatic refunds when a flight is cancelled or significantly changed and the passenger declines the alternative, but there’s no EU261-style cash-compensation statute — airline dashboard commitments cover rebooking, meals, and hotels for controllable disruptions. Accessibility rules add further obligations. An agent should apply these rules, never invent them, and escalate ambiguous cases to a human.

Does Agentforce replace an airline’s reservation system?

No. The passenger service system — Amadeus Altéa, Sabre, or Navitaire — remains the authoritative source for inventory, fares, and PNRs, and Network Operations Control owns the recovery plan. Agentforce sits in front of those systems as the passenger-facing servicing and communication layer: it notifies, runs the rebooking dialogue, and writes changes back into the PSS through MuleSoft integrations, with Data 360 unifying the passenger and loyalty context and Service Cloud managing the case and the human handoff. An agent can only rebook against inventory the PSS exposes; it doesn’t replace it or compute the recovery.

---

Building the passenger-facing servicing layer around your reservation and operations systems — a governed agent, a unified passenger profile, and a human-in-the-loop for the cases that need one? Talk to us — grounding the agent in the systems of record and drawing the boundary cleanly is exactly the work that makes it trustworthy, not just fast. Our Agentforce practice does this kind of build.