Airlines & disruption

A trip is a dozen operations and six companies.

A passenger experiences one trip. The operation experiences a booking, a check-in, a bag, a de-icing slot, a gate, a turn, a connection, a hotel, a transfer and a rebooking — spread across the carrier and the companies it works with. Otonoma’s intelligent network lets them act on each other, so when the day goes wrong the whole trip re-plans and your people take the judgment calls.

Request a Demo

The problem

The systems work. The hand-offs between companies are manual.

A carrier’s own estate is in good order: reservations, departure control, revenue management, loyalty, gate, ramp and baggage are connected and current. But almost nothing that recovers a disrupted trip runs on the carrier’s own systems. Ground handling is contracted. So is the hotel that takes a delayed passenger overnight, the ride that gets them there, the firm that returns a mishandled bag and the regional partner flying the first leg.

On a bad morning the information exists — somebody knows the inbound is in the queue, somebody knows the connection closes in forty minutes, somebody knows the hotel at the far end is now wrong. No system acts on it, so a person has to, on a radio or a phone, one passenger at a time.

A traveler waits at a gate window while a de-icing truck works on a snow-covered apron

The airport de-ices the runways and the airline de-ices the aircraft — one event, two organisations, no shared system.

It isn’t a staffing problem. It’s an integration problem. The people are never the cause; the systems underneath them belong to different companies.

The passenger loses the day

Told at the gate, in a line, long after a system knew — by which time the hotel has let the room go.

The carrier pays twice

Rack rate for rooms already under contract, and agents spending hours rebooking one passenger at a time. And the offer that could have been made never is.

The partner works blind

The hotel held the room until six and then sold it, because nobody told it the flight had moved — and the passenger remembers it as your delay.

A missed connection in a snowstorm

Fixed before the passenger reached the gate.

Nothing was cancelled. The inbound flight is stuck in the de-icing queue and the connection will close before it lands. The network notices before the passenger does: it holds a seat on a later departure and asks one question they can answer with a tap. Doing nothing takes the held seat, so the default is always safe.

Then the part nobody fixes today. The arrival has moved by hours, so the hotel at the far end would have released the room and the ride was timed to a flight the passenger is no longer on. Both belong to other companies. Both are fixed in the same thread — no queue, no call, and no agent had to touch it. The agents were with the passengers who needed a person.

6:525G
‹ OT
Otonoma Travel ✓
Your trip · kept current
Re-accommodated · hotel held · ride moved
Tuesday · 6:52 AM
Snow and ice · inbound in the de-icing queue
Your trip · kept current
Morning. Your first flight is in the de-icing queue and it’s moving slowly. I’m watching your connection rather than waiting for it to fail.
Your trip · kept current
Your connection will close 20 minutes before you land. Nothing has been cancelled.
2:10 PM · seat 14A
Same cabin · your seat carried across
Or try the 11:40 standby. Doing nothing takes the 2:10.
Take the 2:10
Take the 2:10 — can’t risk standby today
Re-checking everything downstream of a later arrival
Your trip · kept current
Done. You now land at 7:40 PM, so your hotel would have released your room at 6 and your ride was booked for a flight you’re not on. Those are two other companies — I’ve sorted both.
2:10 PM · room held · ride re-timed
Three companies · one thread · no phone call
Re-accommodated · hotel held · ride moved
Behind the thread
Airfield & de-icing queueLanding 9:05 AM
Carrier reservations2:10 PM confirmed
Passenger (a person)Chose in one tap
Far-end hotel · another companyRoom held to 11 PM
Ground transfer · another companyPickup 8:05 PM

Illustrative scenario. Three companies, one thread, one tap from the passenger.

One event, many audiences

Same morning. Three more views. One network.

The same bad morning, seen by a delayed passenger, a crew member and a technician. Passengers get the messaging app they already use; crew and technicians get the workplace chat they already use, on their corporate identity. The channel follows the identity — and it is the same network behind both.

A long delay · 9:15 AM

Four hours. Or an offer.

A departure delay crosses the threshold the carrier set. The thread doesn’t apologise — it offers.

  1. Live inventory checked at partners already under contract: a lounge seat, a day room, a later flight with a better seat, a transfer to town and back.
  2. Each option held live for minutes — not a voucher, not a coupon.
  3. The passenger takes the day room: they have a call at eleven and need a desk.
  4. Shuttle booked; boarding alert moved to the hotel.

The offer came because their morning broke, not because it was time to sell them something. If nothing suited, the answer would have been nothing at all.

Revenue on a morning the operation normally only spends money.

Crew · 7:20 AM

The rotation changed.

A first officer’s inbound is cancelled and crew scheduling reassigns them. Crew scheduling makes that call; the network does not. The assignment, the legality check and the rest calculation stay in the system the carrier already runs. We orchestrate on top of it — fixing everything the decision broke.

  1. Old layover room released, and the release confirmed on the thread.
  2. New layover hotel booked for the new rotation.
  3. Crew transport re-timed; parking extended.
  4. One acknowledgement tap from the crew member.

Done before they reach the crew room — and the acknowledgement trail wrote itself.

Maintenance · 8:05 AM

A part at the gate.

A licensed engineer at a spoke station has raised a deferred item. The airworthiness call is theirs, already made, and both the call and the ticket stay in the maintenance system. We start at the part.

  1. Part found in stores, and space found on the next flight to the station.
  2. A second licensed technician on shift is asked to help with the fit.
  3. Departure re-timed, the gate told, and the contracted handler’s turn re-cut rather than stood down.
  4. Downstream connections re-checked — and the passenger from the first scene told that their departure moved.

One event, two audiences, one network. Nobody had to remember to tell anyone.

Illustrative scenarios. Times are examples.

Mass disruption

Hundreds of itineraries break at once. They re-plan in parallel.

An ice storm, or a failure in infrastructure nobody in the operation controls. On 21 September 2026 an air-traffic-control failure delayed about 4,000 flights across the United States and cancelled 500 (CNN, NBC News). No carrier could have prevented it. The only variable is how fast each carrier’s own recovery reaches the passenger.

The network re-plans every dependent branch at the same time, not through a queue of staff working a phone list. Only the handful of genuine judgment calls go to a human desk, with the options already worked out: the passenger travelling with a medical need, the hotel that can’t take forty, the passenger already disrupted twice this month. The machine takes the volume. Your people take the judgment.

Illustrative: one storm, 120 itineraries. Six judgment calls reach a person; the rest re-plan automatically.

Guardrails

Models predict; the network executes.

Guardrails for agentic artificial intelligence (AI) — a complement, not a critique. The models are good and getting better. What a regulated operation needs is what goes around them, and that is three things.

Determinism at the commitment

A model can propose. What actually gets committed — a seat held, a room booked, a part moved — runs as a compiled goal tree. Deterministic execution: it runs the same way every time.

A cost that doesn’t scale with the bad day

The volume is executed rather than inferred, at a small fraction of the cost of asking a language model to reason from scratch. Inference is spent where judgment is actually needed.

A record, not a plausible story

Every conversation is kept in the node’s ledger, so “why was this passenger re-accommodated that way?” has an answer a regulator and a contract dispute can both use.

Use whichever models you have already bought, for forecasting demand or flagging a component. The network makes their predictions actionable.

Works with what you run

We overlay. We don’t replace.

The Passenger Service System (PSS), revenue management, loyalty, the customer record, gate, ramp and baggage all stay exactly where they are. What changes is that they can act on each other — and on the systems of the companies you work with. A node runs wherever the work is: in your cloud, at the station, and with each partner.

  • No system in the middle. No central workflow server and no shared database. Each node owns its own actors and its own state.
  • Federation is directional. A hotel can be asked for rooms without being able to reach back, and each side exposes exactly the skills it chooses.
  • Negative trust. Every actor carries a certificate, only registered skills can be requested, and access is checked at every request, not just at the perimeter.
  • Flight operations stay where they are. Dispatch, maintenance and crew legality are regulated by the Federal Aviation Administration (FAA) and stay in the systems that already run them. We orchestrate on top of them, never through them.

Where the value is

Crawl, walk, run.

Be suspicious of anyone who claims the whole value pool on day one. The pools sit at different depths and need different permissions.

Crawl · ground and guest operations

Disruption care executed rather than queued for, the turn coordinated across the companies doing it, and options offered while a delay is still happening. The data is already in systems you own, and a win is measurable inside one disruption.

Walk · revenue and workforce

Partner supply negotiated on what was actually used, agent minutes returned to the passengers who need a person, and customer value across trips rather than within one.

Run · later, together

The far side of the regulatory line: network and schedule planning, crew, fleet. We don’t start there and we don’t claim it today. Our role there now is to make someone else’s decision actionable.

Getting started

A proof of concept that pays for itself inside one disruption.

One hub, one season, one quarter, baselined against the prior equivalent period — and nothing needed from flight operations. Two candidates, one for cost and one for the top line. Both use data you already have.

Disrupted-passenger care

Lodging, ground transport and meals from suppliers you already contract, confirmed in the thread the passenger is already reading — instead of a queue at a podium and a voucher. Measured as agent minutes per passenger, spend against the contracted rate, and calls avoided.

Day-of-travel options

A delay past a threshold becomes offers the passenger can take, sourced live from partners you already contract. Measured as take-up, revenue per disruption, and how much of the cost of care it offsets.

If the numbers aren’t there, you’ve lost a quarter and learned something real — which is more than most pilots give you.

A trip where everything is seamlessly connected.

Your passenger, your data, your standards — on the systems you already run. We are working with a small number of operators in each market, and several prototypes are in operation today.

Request a Demo How the network stays in bounds →