Irregular operations do not announce themselves cleanly. They arrive as a rolling maintenance delay on an inbound aircraft, a weather event developing three time zones away, a crew member who called in sick at 5am at a base with limited coverage. What starts as one disruption becomes three becomes seven as the effects propagate through a schedule that was built with no slack to absorb them.

The people managing this in real time are working from incomplete information, under time pressure, tracking a mental model of the system that is continuously being invalidated by new developments. They are making consequential decisions - delay, cancel, rebook, ferry, reaccommodate - while simultaneously monitoring duty times, tracking maintenance updates, managing customer communications, and coordinating with stations, crew scheduling, and dispatch.

The bottleneck in IROPS recovery is not information availability. Most of the relevant information exists somewhere in the airline's systems. The bottleneck is the speed at which a human team can synthesize that information, evaluate its implications across all affected flights simultaneously, and produce actionable decisions before the window for each decision closes.

Understanding this distinction - information availability versus information synthesis under time pressure - is essential to understanding where AI actually helps in IROPS and where it does not.

The network carrier and the ULCC face different problems

Before going further, it is worth being direct about something that most discussions of AI in IROPS recovery gloss over: the problem is not the same across airline types, and the solutions are not interchangeable. A large network carrier operating a hub-and-spoke system has a recovery asset that ULCCs do not: flight frequency. When a flight cancels at a hub, there are typically multiple subsequent departures to the same destination that stranded passengers can be reaccommodated on. The recovery is painful and expensive, but the toolkit exists. The optimization problem is finding the least-bad path through a complex network of alternatives.

An ultra-low cost carrier operating a point-to-point network with high aircraft utilization and limited frequency has a fundamentally harder problem. When an aircraft goes out of service, the recovery options are limited. Recovering that aircraft's flying may require pulling another aircraft off its own route - which means that aircraft's passengers also need recovery. A single cancellation can cascade into a ferry flight with a repositioned crew, a second disrupted itinerary, and a recovery operation whose cost rivals or exceeds the revenue of the original flying.

It gets worse. When a ULCC cancels a flight, passengers do not wait passively for the airline to rebook them. Many of them find their own way - on a competitor, by car, by not traveling at all. The airline may recover the aircraft and fly the rescue operation, but capture only half or less of the original passengers. The cost of the recovery is borne fully. The revenue recovery is partial.

This asymmetry matters for how AI gets applied. A network carrier deploying AI in IROPS recovery is solving a combinatorial optimization problem with a rich set of assets. A ULCC deploying the same approach is solving a resource scarcity problem where the primary challenge is not which path to choose but whether any viable path exists - and what it costs relative to the revenue it recovers.

What the operations controller is actually doing

The conventional description of IROPS decision-making focuses on the decision outputs: delay or cancel, which crew to reassign, which passengers to reaccommodate where. What gets less attention is the cognitive load of the process that produces those outputs.

An operations controller managing an active disruption is simultaneously holding in their head: the current duty status of affected crew members and when they will time out under FAR Part 117, the maintenance situation on the affected aircraft and the probability distribution of when - or whether - it will be fixed, the downstream implications of each delay increment on connecting flights and their passengers, the crew legality implications of each potential reassignment across all affected pairings, and the customer communication obligations that are running in parallel with all of the above. "This crew member started their pairing at 4am and they're coming up on their duty limit, so they'll probably time out" - that is a calculation the controller is doing in their head, for multiple crew members, while simultaneously tracking a maintenance update that may or may not change the situation, while a gate agent is calling about a passenger with a connection that is about to close.

Each piece of information arrives with uncertainty attached. The maintenance update says the aircraft will be ready in 45 minutes - but maintenance estimates have a distribution, and the controller has learned from experience that 45 minutes often means 90. The crew member who is approaching their duty limit might be fine if the delay resolves quickly, might time out if it does not. Every decision is being made against a future that is probabilistic rather than known.

This is what makes IROPS hard. Not the individual decisions - each one, evaluated in isolation, is tractable. It is the simultaneous tracking of all of them, under continuous information updates, with a clock running on each decision window, for every affected flight in the system.

Where AI fits - and how the architecture has changed

The historical AI pitch for IROPS was optimization: give the system the constraints and it will find the optimal crew reassignment. This framing was partially correct and significantly oversold. Constraint satisfaction algorithms can evaluate legal crew reassignment combinations faster than humans. They cannot evaluate the full context of a developing disruption - the maintenance uncertainty, the passenger implications, the cascade effects - in a way that produces recommendations a controller can act on without substantial manual verification.

The more useful framing, and the one that reflects where AI architecture has actually evolved, is coordination rather than optimization. A team of specialized AI agents - each focused on a specific information stream - can synthesize and surface the relevant information for human decision-makers faster and more completely than a human team tracking the same streams manually.

One agent monitors crew duty times across all affected pairings in real time, flagging crew members approaching legal limits and surfacing the remaining duty windows without the controller having to calculate them manually. Another tracks maintenance updates, builds a probability model of resolution timing based on the type of issue and historical resolution patterns for similar events, and updates that estimate continuously as new information arrives. Another evaluates the passenger implications of each potential delay increment - which connections close, how many passengers are affected, what reaccommodation options exist on subsequent flights. Another manages the external communication obligations - what notifications are required, when, to which passengers, through which channels - and executes them within the parameters the controller sets.

The human controller is not removed from the process. They are freed from the information management burden that currently consumes most of their cognitive capacity, so that the judgment calls - the decisions that require contextual understanding, operational experience, and accountability - can receive the attention they deserve.

This is a materially different value proposition from "the AI finds the optimal solution." It is: the AI handles the information synthesis so the human can make better decisions faster.

The uncertainty problem

There is an aspect of IROPS that optimization frameworks handle poorly and that the coordination framing handles better: the decisions are being made under genuine uncertainty about how the situation will develop. A rolling maintenance delay is not a fixed constraint. It is a probability distribution. The aircraft might be ready in 30 minutes, 90 minutes, or not at all tonight. Each of those scenarios implies a different set of optimal decisions. A system that assumes the maintenance estimate is accurate and optimizes against it will produce recommendations that are correct given that assumption and potentially very wrong if the assumption is wrong.

Experienced controllers do not optimize against a single scenario. They maintain multiple contingency plans simultaneously, updating them as new information resolves the uncertainty. If the maintenance fix looks likely, they hold the crew. If the fix starts looking uncertain, they begin identifying backup crew options before the original crew times out. If the situation deteriorates further, they move to cancel and reaccommodation.

An AI system that supports this kind of parallel contingency planning - that can model multiple scenarios simultaneously and surface the implications of each as the uncertainty resolves - is more useful than one that produces a single recommended solution. The value is not the answer. It is the ability to see the decision landscape more completely than any human team can track manually.

What this means in practice

The airlines that will get the most out of AI in IROPS are not the ones looking for the system to make decisions. They are the ones looking to change the information environment in which their controllers make decisions.

The goal is a controller who, at any point during an active disruption, can see the duty status of every affected crew member without calculating it, the probability distribution of the maintenance resolution without estimating it, the passenger impact of each available decision without modeling it, and the communication obligations already being handled without managing them. A controller who can focus entirely on the judgment calls because the information management is handled.

That is a different product than IROPS optimization software. It is closer to an operational intelligence platform - one that is continuously synthesizing the information the controller needs, in the format they need it, at the speed the situation requires.

The disruption will still be hard. The decisions will still require experience and judgment. But the cognitive load that currently makes IROPS management so taxing - the simultaneous tracking of multiple uncertain situations across an entire disrupted operation - is exactly the kind of problem that AI handles well.

Taking that burden off the controller does not make the decisions for them. It makes them better at making the decisions themselves.