AeroResolve: policy-governed airline support

When a flight is cancelled or delayed, a passenger does not want a lecture about policy. They need to know what happened, which options apply to their booking, what can be done now, and when a person must step in. The risky shortcut is a fluent chatbot that invents compensation or promises actions it cannot take. For AIONOS.AI Agentic AI Factory Assignment 3, I built AeroResolve as a simulated resolution layer: an agent that explains policy in plain language, takes only authorized simulated actions, and leaves an audit trail for operations.

I started with the passenger's question, not the model: what happened, what am I owed, what can you actually do, and who steps in when the answer is outside policy? The assignment supplied three disruption cases, customer and booking data, and five service rules. I mapped the routine decisions against the authority boundaries before sketching the UI. One idea clicked in the most unglamorous moment possible. I grabbed paper and drew a frustration meter between the customer's words, the agent's context, the policy gate, and the operations desk. The point wasn't to label a person. It was to notice signals in a difficult conversation without letting emotion rewrite an entitlement. That rough sketch became the product's split between an empathetic reply and a deterministic decision. I treated the sample conversations as tone examples, not as policy or facts about these passengers.

The brief I set myself was to compress the support journey from ticket, queue, retelling, policy lookup, and handoff into one conversation: understand the disruption, retrieve this passenger's booking and the relevant clause, decide what is permitted, take a simulated action where authority exists, and show a human where it does not. The passenger surface is a single thread with choices, confirmations, and escalation in context. The separate staff surface is for audit, cases, containment and a live knowledge graph. A new-trip request and a how-to question take different routes from disruption claims, so the agent cannot turn a check-in question into compensation. Booking assist collects origin, destination, date and passenger count before showing a look-only departure; there is no invented fare or ticket purchase.

The hardest decision was where to put authority. I could have asked an LLM to read the full policy and decide everything. That would be fast to prototype and hard to trust. Instead, I scoped the model to intent, orchestration and phrasing. A policy engine returns ALLOW, ASK, DENY, ESCALATE or INFORM from booking facts and clause-level rules. Execution tools run only after an ALLOW with agent authority; every action is marked SIMULATED. Frustration can change tone and the order of already eligible options, never their eligibility or amount. Low-confidence observations wait for staff review before being counted. The tradeoff is more explicit rules and engineering work, but a wrong, confident answer about money is costlier than an extra handoff.

I built a passenger-facing Resolution Agent and a staff-only Operations view. The customer sees the booking and current disruption, a response grounded in the applicable clause, and an inline choice or handoff. The agent asks for one missing detail at a time, cites the relevant policy, and keeps the case open until the passenger says it is resolved; a 1–5 satisfaction popup follows closure, not the issuing of a voucher. Operations can inspect transcripts, decisions, policies and actions, watch open, escalated and resolved cases, review knowledge-base candidates, and inspect graph edges written during the conversation. Under the hood, a FastAPI agent loop narrows context to this passenger and booking, applies the policy handlers, and writes an audit trail. Postgres is the durable store when configured; the documented fallback is Elasticsearch or a JSON pack. Optional LLM providers improve extraction and wording, while the same policy tools and template path work without an API key or when quota fails. The repository contains policy tests and deployment instructions; the live demo is a simulated prototype, not an airline integration.

Priya's Delhi–Goa cancellation offers a free rebooking within 24 hours or a refund to the original payment method; her Gold tier gives priority, not extra compensation. The return leg stays untouched, and an unsupported upgrade request goes to a human. Arvind's four-hour delay permits a meal voucher and lounge access, but not a hotel, which starts only after five hours. His frustration changes the reply, not the rule. Meher's six-hour delay qualifies for a hotel during delayed hours, not a full night; a ₹2,000 fare difference exceeds the ₹1,500 agent waiver limit and becomes a supervisor case with context attached. These are fixtures from the assignment data pack, not real customer outcomes.

The result is a working, clickable prototype with a policy-grounded passenger flow and a distinct operations audit surface. In my Sep 2026 review, the live passenger demo showed Priya's cancelled booking, rebook/refund choices and clause-backed decision context. The operations dashboard was accessible, but its current JSON store showed zero measured turns and no case graph edges. I therefore cannot claim a production containment rate, resolution-time improvement, CSAT lift or number of people served. The presentation names those as KPI categories or design targets, not measured results.

I'd run the three scenarios with fresh sessions and capture a repeatable baseline for correctness and end-to-end time, then test uncertain requests and longer conversations. I'd watch for false frustration signals, missing policy coverage and avoidable handoffs. Before any real deployment, simulated refunds, rebookings and hotels would need airline inventory and payment integrations, consent and identity checks, operational controls, and a review process for policy changes. A strong model with weak context is still a bad support agent. The product has to know what it knows, what it is allowed to do, and when to stop.

Passenger demo · Operations demo · GitHub repository · 10-slide product presentation · Demo video. Screenshots from the video show a historical demo run and are illustrations of the workflow, not current production results.