AI agent workflows for Aviation & airlines

Build spec

1 agent — 1 rebooking agent runs inside the Loop; the notify, routing, PSS write and refund approval are workflow nodes.

System prompt (paste-ready)

You are a flight-disruption assistant for {{airline}}. For each affected passenger {pnr, name, flight, disruption_type, language, alternatives[]}, write a clear, calm notice in the passenger's language explaining what happened and listing ONLY the alternatives supplied in the input — never invent a flight, time, or upgrade. State refund/compensation eligibility only as it appears in the rebooking policy from Knowledge; never promise a payout. If the passenger asks for a refund or compensation, output intent=REFUND for the workflow to route to a human — do not confirm any refund yourself.

Guardrails

• Grounded-only: alternatives and eligibility come from the input + policy Knowledge — the agent never invents a flight, time, or payout
• Every refund or compensation is Approval-gated — the agent may state eligibility but never confirms money; only a human approves the payout
• Idempotent per PNR (keyed by pnr + disruption id) so a re-run never double-notifies or double-rebooks a passenger

Cost strategy

The notify agent runs once per affected PNR, so on a mass disruption its model choice dominates total cost — keep it on the economy tier; the task is grounded templating, not reasoning, so premium buys nothing. Sarvam/ElevenLabs synthesis is billed only on the Voice legs, not for WhatsApp/SMS passengers. Run the Loop in Parallel batches for wall-clock speed without changing per-passenger cost.

Output & delivery

The Loop maps the agent over every affected PNR → the notice + policy-valid alternatives are sent on WhatsApp/SMS or spoken via Sarvam/ElevenLabs → the Condition routes accepted rebookings to a Tool node that writes them to the PSS, and any refund/compensation to a human Approval before it's issued.

Build spec

1 agent — 1 intake agent handles the conversation; the baggage lookup, routing and compensation approval are workflow nodes.

System prompt (paste-ready)

You are a baggage-claim intake assistant for {{airline}}. From the passenger's message, capture strict JSON {pnr, bag_tag, issue_type: DELAYED|DAMAGED|LOST, description, contact, language}. Confirm the captured details back before filing. Call the tracing tool and relay the status exactly as returned — never guess a location, ETA, or that a bag is found. State compensation or interim-expense eligibility only as the baggage policy in Knowledge allows, and never confirm a payout — output issue_type so the workflow can route compensable cases to a human.

Guardrails

• Status and ETAs are read from the DCS only — the agent never guesses a bag's location or that it has been found
• Every interim-expense or compensation payout is Approval-gated — the agent states policy eligibility but never confirms money
• Scope-locked to the reporting passenger's own PNR + bag tag — the tool can't read other travellers' records

Cost strategy

One intake agent per conversation on the economy/standard tier — capturing a claim and reading a tracing record is not reasoning-heavy, so no premium tier is needed. Sarvam/ElevenLabs synthesis is billed only when the passenger is on a Voice call or an Indian-language leg, not for text chat. A per-conversation tool-call cap keeps a stuck tracing lookup from racking up API cost.

Output & delivery

The agent files a clean PIR from the captured JSON → a Tool node reads live tracing status from the DCS → the Condition gives a located bag a delivery ETA and routes lost/damaged cases to a human Approval for any compensation, confirmed back to the passenger on their channel.