What Now?

Inspiration

What Now? started with a recent airline disruption I read about.

Bad weather forced an AirAsia aircraft to divert to an airport the airline did not normally operate from. Passengers were assisted, given food, and eventually brought back to their original destination. But what stayed with me was everything that happened in between.

Because the aircraft was now somewhere outside the airline's normal operation, recovery was not immediate. Passengers initially understood that a replacement crew would be sent because the original crew needed to rest. Hours later, the original crew ultimately operated the flight back.

Passengers were also given the option to remain at the diversion airport instead of continuing to the original destination. But from the passenger's account, it was not clear what the complete set of recovery options actually was. Could ground transportation have been arranged? Were there other flights? What alternatives were operationally possible? How quickly could those possibilities have been evaluated?

The problem did not seem to be simply poor communication. The harder issue was that good information depends on operational decisions being made first.

A disruption immediately creates a chain of questions: Where can passengers go now? Which alternatives are feasible? What constraints apply? Who can be recovered automatically, and which cases need human judgment? What should passengers be told while the situation is still changing?

That made me wonder whether an agentic system could help shorten that decision-making cycle.

That became What Now? — an airline disruption recovery layer designed to turn an operational disruption into structured, feasible recovery options while keeping consequential decisions under human control.

What it does

What Now? helps airline operations teams respond to:

cancellations; major delays and missed connections; and capacity reductions or equipment downgrades.

When a disruption occurs, the system can:

assess the affected operation; identify feasible direct and connecting alternatives; validate schedule, connection, itinerary, transit, capacity, and policy constraints; optimize recovery across affected passengers; classify cases as RECOVERABLE, APPROVAL_REQUIRED, or HUMAN_REVIEW; present a structured recovery plan to airline staff; support manual route overrides and what-if reoptimization; preserve plan versions and audit operator actions; revalidate authoritative information before execution; preserve human approval for consequential booking changes; and use Gemini through Google ADK to produce grounded operational briefings based on validated recovery state.

What Now? is not intended to replace an airline reservation system or operations control center. It is designed as an orchestration layer between disruption detection and the airline systems that ultimately perform servicing.

Its core principle is:

Real operations, fake people.

For testing, What Now? uses real historical flight operations while keeping passengers, bookings, inventory, airline policy, and execution adapters synthetic.

How we built it

What Now? is built primarily in Python with FastAPI and a lightweight airline operations console.

The deployed application runs on Google Cloud Run.

The agent layer uses Google Agent Development Kit (ADK) with Gemini 3.7 Flash through Vertex AI. The deployed Recovery Supervisor uses authoritative recovery-state tools before generating an operational briefing.

Gemini does not determine operational truth. It does not invent:

seat inventory; whether a flight exists; minimum connection time; itinerary continuity; transit eligibility; passenger capacity; or whether an airline action has been approved.

Those decisions remain deterministic.

The recovery engine combines deterministic validation with Google OR-Tools CP-SAT optimization.

Airport reference metadata, including time-zone information used during normalization, is supplemented using the MIT-licensed airportsdata Python package.

Together, those datasets contain more than 1.2 million real historical flight records.

We built a normalization layer that handles:

airport-local time to UTC conversion; overnight flights; time-zone boundaries; International Date Line cases; BTS 2400 time semantics; cancellations and diversions; authoritative dated flight-instance identities; and quarantine of malformed or internally inconsistent source records instead of silently guessing.

June is used as the primary development corpus, while May provides an out-of-sample validation dataset.

The deployed MVP currently uses local SQLite-backed runtime state inside Cloud Run. Because Cloud Run instances are ephemeral, demo state may reset when an instance is recycled; judges can simply relaunch a scenario from the demo page.

This limitation is intentional and disclosed rather than presenting the MVP as a production airline persistence layer.

Challenges we ran into

The biggest challenge was making sure an impressive-looking recovery plan was actually correct.

Airline disruption recovery contains many edge cases that simple demo fixtures can hide. During development, we repeatedly subjected the application to adversarial review rather than relying only on passing happy-path tests.

Those reviews uncovered issues including:

non-atomic inventory updates; stale-plan execution races; unsafe passenger confirmation paths; caller-controlled booking references; provisional-hold concurrency problems; weak flight identity; incomplete itinerary validation; dependent-family recovery edge cases; plan-version and approval-state safety; manual-override validation and provenance; runtime hardcoded operational assumptions; and subtle timezone and date-rollover behavior in real BTS data.

Each serious issue was repaired and then re-tested before moving forward.

Real historical data introduced another category of challenges. BTS reports scheduled and actual times as local airport clock values, which meant we had to correctly handle time zones, midnight rollover, Guam/Hawaii Date Line cases, ambiguous timestamps, and inconsistent source rows.

Instead of forcing every row to work, What Now? explicitly quarantines records that cannot be interpreted safely without guessing.

Another challenge was deciding where AI should stop.

Airline recovery contains many decisions where a plausible language-model answer is not good enough. A convincing explanation cannot compensate for a nonexistent seat, an impossible connection, or an invalid itinerary.

That led us toward a deliberately hybrid architecture rather than an AI-only system.

Accomplishments that we're proud of

One accomplishment we are especially proud of is that the project moved well beyond a controlled synthetic schedule.

The BTS normalization pipeline successfully processed more than 1.2 million historical flight records across two months with:

zero unresolved airport time zones; zero duplicate normalized flight-instance IDs; explicit quarantine rather than silent data loss; independently checked month-boundary and Date Line conversions; and the same normalization rules applied to both development and out-of-sample data.

We also completed a full historical disruption replay using a real BTS cancellation combined with synthetic passengers, inventory, and policy.

The system generated schedule-valid recovery candidates, applied deterministic passenger and itinerary constraints, optimized scarce capacity, preserved hard dependent-family constraints, and produced a recovery plan without inventing operational facts.

The deployed system also demonstrates a genuine Google AI execution path:

Cloud Run → Google ADK → Gemini 3.7 Flash on Vertex AI → authoritative recovery-state tool → grounded operational briefing

The resulting audit trail records that the Gemini/ADK step completed successfully without using the deterministic fallback.

At the same time, the recovery allocation itself remains deterministic through validation and OR-Tools.

The project now has 150+ automated tests spanning normalization, schedule validation, optimization, state transitions, plan versioning, stale approvals, override safety, audit behavior, and runtime hardening.

We are also proud of the authority boundary built into the workflow.

A language model can help understand and explain a situation, but it cannot simply decide that a seat exists, ignore an invalid connection, override passenger constraints, or execute a consequential booking change on its own.

What we learned

The biggest lesson was that agentic software becomes more useful when the agent's authority is deliberately constrained.

Gemini is valuable for understanding context, using tools, explaining recovery decisions, and preparing structured operational briefings.

But many operational questions have answers that should come from deterministic systems:

Does this flight actually exist? Is there enough connection time? Is the itinerary continuous? Is inventory still available? Can this group be split? Does this passenger require human review? Has this exact plan version been approved?

For What Now?, the strongest design became:

agentic reasoning + deterministic operational rules + mathematical optimization + explicit human authority.

We also learned how easily synthetic examples can create false confidence.

Feeding the project real historical flight operations exposed assumptions that clean fixtures never would have revealed.

And repeated adversarial testing reinforced another lesson: passing tests are useful, but deliberately trying to break your own system often teaches you more.

What's next for What Now?

The current MVP demonstrates the full recovery loop from disruption intake through recovery planning, optimization, human review, plan versioning, and mock servicing.

The next step is not to add more intelligence for its own sake, but to make the system more production-ready.

That includes:

persistent cloud state instead of ephemeral demo storage; authenticated airline operator identity instead of user-entered demo IDs; production integrations with airline reservation, inventory, and servicing systems; event-driven disruption ingestion; richer policy and passenger-rights integration; stronger strategy-comparison analytics; additional disruption types and operational edge cases; and production observability, security, and governance.

Longer term, What Now? could become an airline-agnostic API layer connecting reservation, inventory, operations, airport, and servicing systems through adapters.

The goal is not to remove people from disruption management.

It is to help them reach a feasible decision faster when passengers and operations teams are all asking the same question:

What now?