Serialised human judgement
Three controllers work 312 passengers one at a time while the phones ring. The hundredth passenger gets a worse outcome than the tenth, purely because of position in a queue nobody designed.
SE-IROPS · Release 2026.1
The first ninety minutes of a disruption, handled.
When weather closes a runway, the cost is not the delay — it is the two hours before anyone has re-accommodated 312 passengers, told them the truth, and protected the downline rotation. SE-IROPS is a multi-agent system that does that work inside your policy, at the speed the situation actually moves.
0Specialised agents
0Autonomy envelope
0Actions reversible & logged
0Cash paid without approval
4 items awaiting a duty manager
The problem
Disruption cost is mostly a queueing problem.
The controllers know what to do. There are simply more decisions than people, they all arrive at once, and every minute of delay in making them adds another passenger to the queue and another cascade downline.
Communication that lags the decision
The rebooking happens at 19:10 and the passenger hears about it at 20:05, by which time they have already called the contact centre and been told something different.
Policy applied unevenly
Two passengers on the same fare, same disruption, get different entitlements depending on who handled them and how tired that person was. That is the inconsistency a regulator asks about later.
What it does
Six agents, one operation, no freelancing.
Each agent has one job, one set of tools and an explicit boundary. They coordinate through shared state rather than by calling each other, so any one of them can be paused without stopping the rest.
01 · Detection
Notice it before the phones do
The watcher agent runs continuously across operational, weather, NOTAM, slot and crew feeds, maintaining a rolling risk score per flight and per connection. Its output is not "delayed" — it is "this inbound is 40 minutes late, which puts 34 connections at risk and breaks a crew duty limit at 23:10".
- Continuous ingestion from OPS, weather, NOTAM and slot feeds
- Rolling connection-risk scoring per passenger, not per flight
- Crew legality and downline rotation exposure
- Distinguishes a self-resolving delay from a cascading one
02 · Impact
Who is actually affected, and in what order
The assessor resolves the disruption into a ranked list of affected passengers using the priorities you configure — special assistance, unaccompanied minors, medical needs, onward connection value, loyalty tier, fare class. Prioritisation is a policy input. We will help you reason about it; we will not decide it for you.
- Passenger-level impact, not flight-level
- Special assistance and minors surfaced first by default
- Interline and codeshare exposure identified early
- Priority weighting is your configuration, versioned like code
03 · Re-accommodation
Options scored against your rules, not a generic optimiser
The planner generates re-accommodation options per passenger, checked against fare rules, interline agreements, seat availability and cost ceilings. It proposes; the action envelope decides whether the proposal executes immediately, executes with a notification, or waits for a duty manager.
- Own-metal, interline and partner options with cost attached
- Fare rules and interline agreements enforced, not approximated
- Every option carries the reasoning that produced it
- Confidence floor: below it, the agent escalates rather than acts
Where a rules engine wins: if your re-accommodation policy is genuinely deterministic and your fare rules are simple, a rules engine is cheaper, faster and easier to certify. The agents earn their place when the space is too large and too contextual to enumerate — which is most real networks, but not all of them.
04 · Entitlements
Duty of care, applied identically to everyone
Hotel, meal and ground transport issuance runs against your caps and your supplier agreements. Compensation drafting is aware of EU261 and DGCA obligations, but it drafts — a human authorises money leaving the business, every time, without exception.
- Hotel, meal and transport issuance within configured caps
- EU261 and DGCA-aware compensation drafting
- Every monetary action tagged with the policy version applied
- Cash and refunds always require human authorisation
05 · Communications
One narrative, everywhere, at once
Per-passenger messages go out across email, SMS, app push and WhatsApp in the passenger's language, generated from the same decision record that drove the rebooking. The gate agent, the contact centre and the app all see the identical story — which is the single biggest determinant of how a disruption feels to the person living through it.
- Per-passenger, per-channel, per-language messaging
- Contact centre and gate see the same narrative and status
- Suppression rules prevent duplicate or contradictory sends
- Message templates reviewed and versioned by your comms team
06 · Governance
Explain any decision, months later
Every action records the inputs it saw, the policy version in force, the options considered, the option chosen and the reasoning. Any decision can be replayed. Before a policy change goes live it runs against historical disruptions in an evaluation harness, so you can see what would have happened differently.
- Full decision record: inputs, policy version, options, choice
- Every executed action reversible with a compensating action
- Replay a policy change against last quarter's disruptions
- Regulator-ready export for any passenger, any event
Walk through it
One evening, end to end.
A thunderstorm cell over the field at 18:42. Six steps, and where the humans stay in the loop.
Watcher · continuous
METAR TS +RAground stop 45 min2 inbounds holdingslot pressure rising
No flight has been declared delayed yet. The watcher has already flagged that this pattern historically cascades, and started scoring connections at risk.
Assessor · 5 minutes later
Affected pax312
Misconnects231
Priority cases25
Crew breach23:10
Planner · proposals with cost
Own metal, next morning184 pax₹0
Interline, tonight47 pax₹6.1L
Hold and re-time77 pax₹0
Cash compensation4 paxreview
Envelope · what ran without a human
band 1 · 231 rebooks executedband 2 · 96 hotels issued
band 3 · 4 items queued
The duty manager sees four decisions, not three hundred. Each arrives with the options considered and the reasoning, so the review takes under a minute each.
Comms · one narrative
288 SMS312 email204 pushgate briefedcontact centre synced
Morning report
Time to first action5 min
Pax re-accommodated312
Human decisions4
Contact centre calls−63%
Illustrative figures for a single modelled event. Your baseline is measured during the pilot before anything is claimed.
Specifications
The page your operations and compliance teams read.
- Agents
- Watcher, impact assessor, re-accommodation planner, entitlements, communications, escalation manager
- Coordination
- Shared versioned operation state; agents never call each other directly
- Model layer
- Claude models via the Anthropic API or AWS Bedrock; version pinned per release
- Degraded mode
- If the model is unreachable, watcher and assessor continue; the system falls back to advisory output for humans
- Runtime
- Kubernetes in your cloud tenancy; VPC-isolated
Architecture & agents
- Operational
- PSS and DCS, flight movement feeds, slot systems, crew management
- Environmental
- METAR/TAF weather providers, NOTAM feeds, airport ground-stop notices
- Commercial
- Fare rules, interline and codeshare agreements, cost ceilings
- Fulfilment
- Hotel and ground transport booking, voucher and payment issuance
- Customer
- CRM, loyalty, SMS, email, push and WhatsApp gateways
Data interfaces
- Action envelope
- Three bands — auto-execute, execute and notify, requires approval — configurable per station, carrier and time of day
- Always human
- Cash compensation, refunds above threshold, downgrades, involuntary denial of boarding, anything involving an unaccompanied minor
- Confidence floor
- Proposals scoring below a configured threshold escalate rather than execute
- Prioritisation
- Your weighting of assistance needs, minors, connection value, loyalty and fare class; versioned as configuration
- Reversal
- Every executed action has a defined compensating action; bulk reversal supported
Decision scope & policy controls
- Channels
- Email, SMS, app push, WhatsApp; contact centre and gate screens updated from the same record
- Languages
- Per-passenger language from the profile, with fallback to the market default
- Templates
- Authored and versioned by your communications team; the agent fills, it does not freelance tone
- Suppression
- Duplicate, contradictory and out-of-order message prevention
Communications
- Decision record
- Inputs seen, policy version, options generated, option chosen, reasoning, actor
- Replay
- Any decision reconstructable; any policy change testable against historical disruptions
- Regulator export
- Per-passenger, per-event narrative with timestamps and policy references
- Observability
- Per-agent latency, tool success rate, token accounting and outcome quality
- Evaluation
- Historical disruption suite gates every prompt, policy or model change
Governance, audit & evaluation
- Deployment
- Your cloud tenancy, VPC-isolated; model access via your Anthropic account or Bedrock
- Data residency
- Region-pinned state and logs; model region selectable via Bedrock
- Air-gapped
- Not possible — the model must be reachable. Advisory mode continues if it is not
- Commercial model
- Platform fee plus per-disruption-event; pilot pricing credited against rollout
- Support
- Critical tier strongly recommended — see support tiers
Deployment & commercial
Interoperability
Systems we already speak to.
Naming a system states interoperability, not partnership or endorsement.
PSS / DCSPassenger systems
Crew managementDuty legality
Slot systemsAirport slots
NOTAMAirspace notices
METAR / TAFWeather
Hotel bookingDuty of care
Ground transportTransfers
Voucher issuanceMeals · retail
CRMPassenger profile
SMS / WhatsAppMessaging
Anthropic APIClaude models
AWS BedrockIn-tenancy models
Deployment
Start advisory. Earn autonomy.
No airline should switch this on at full autonomy on day one, and we will decline the engagement if you insist.
Stage 1 · Advisory
Agents watch and recommend. Humans execute everything. You measure agreement rate.
- Zero operational risk
- Builds the evidence base
- Typically four to six weeks
Stage 2 · Bounded autonomy
Band 1 actions execute automatically on one station or one disruption class.
- Reversible actions only
- Scoped to a station or fleet
- Expand band by band on evidence
Stage 3 · Network-wide
Full envelope across the network, with duty managers handling only band 3.
- Quarterly policy replay reviews
- Continuous evaluation on live events
- Instant fallback to advisory at any time
0Detection to first actionTarget; measured during pilot
0Decisions reaching a humanAt full envelope, band 3 only
0Actions reversibleCompensating action defined for each
0Advisory pilotBefore any autonomous action
Before you ask
The questions that decide the deal.
What are the agents never allowed to do?
Pay cash compensation, issue a refund above your threshold, downgrade a passenger, deny boarding involuntarily, or take any action involving an unaccompanied minor. These sit in band 3 permanently and cannot be moved into an automatic band through configuration. That is a product constraint, not a default setting.
What happens if the model is unavailable mid-disruption?
The watcher and assessor keep running — they are conventional software over your feeds, not model calls. The planner and communications agents degrade to advisory: they surface the ranked impact and the option set to your duty managers, who execute manually as they do today. You lose the automation, not the situational picture. This is tested as part of commissioning, not assumed.
How do we prove to a regulator why a passenger was treated a given way?
Every action carries a decision record: the inputs the agent saw at that moment, the policy version in force, the options generated with their costs, the option chosen and the reasoning, plus the human who approved it where applicable. The regulator export renders that as a per-passenger narrative with timestamps. If a decision cannot be explained, we treat that as a defect.
Why not just build a rules engine?
If your re-accommodation policy is genuinely deterministic and your fare and interline rules are simple enough to enumerate, a rules engine is cheaper to build, faster to run and far easier to certify — and we will tell you so during scoping rather than sell you this. The agents earn their cost when the option space is large, the trade-offs are contextual, and the passenger mix changes the right answer. In practice most networks are in the second category, but not all, and it is worth twenty minutes to establish which one you are.
How does this relate to Flyaza.ai?
Different jobs. Flyaza serves the customer's intent — they want to change something. IROPS serves the operation's obligation — something changed and the airline must respond. When a Flyaza conversation turns out to concern a disrupted flight, it hands over the context and the IROPS decision record so the traveller hears one consistent story rather than two systems disagreeing.
What does SE-IROPS deliberately not do?
It does not do crew rostering recovery or aircraft rotation optimisation. It reads crew legality and rotation exposure as constraints and escalates when they break, but re-crewing and tail assignment are specialist disciplines with mature vendors, and we would be pretending to a competence we do not have. It also does not set your prioritisation policy — it applies the one you give it.
Also in the portfolio
Often deployed together.
Replay last quarter's worst night.
Give us the data from a disruption you remember badly. We will run the agents against it in advisory mode and show you, decision by decision, what they would have proposed and where they would have escalated.