Read-only assistants
A model with a knowledge base can describe your refund policy. It cannot check whether this specific ticket is refundable, and it certainly cannot process it.
SE-FLYAZA · Release 2026.1
A travel agent that finishes the job.
Most travel chatbots answer a question and then hand you a link. Flyaza.ai searches live inventory, compares fare families, holds the seat, takes the payment and services the ticket afterwards — every claim backed by a tool call into a real system, never by the model's recollection.
0Channels, one session
0Answers backed by a tool call
0Coverage with human handover
0Prices quoted from memory
84 s median time to ticket
The problem
Travel chatbots stop exactly where the value starts.
They handle "what is my baggage allowance" and then collapse at "change my return to Thursday". The traveller ends up in the contact centre anyway, having wasted four minutes first — which is worse than no bot at all.
Confident wrong answers
An ungrounded model will state a fare, a rule or an allowance that sounds right. In travel, a plausible wrong number is a refund request and a regulator's letter.
Handover that loses everything
When the bot gives up, the human agent starts from zero — no constraints, no history, no held seat. The traveller repeats themselves and the containment metric quietly lies.
What it does
Six capabilities that separate an agent from a chatbot.
01 · Grounding
No tool call, no claim
Every price, seat, rule and allowance comes from a typed tool call into your GDS, NDC aggregator or PSS, executed at the moment of asking. The system prompt does not contain fares, and the model is not permitted to state one that did not come back in a tool response. If the tool fails, the agent says the tool failed.
- Typed tool schemas with strict argument validation
- Retrieval over your own fare rules and policy documents
- Every assertion traceable to a specific tool response
- Graceful, honest failure instead of improvisation
02 · Planning
It remembers what you told it
Constraints stated once — a budget, an aisle seat, no red-eyes, a loyalty programme, a child travelling — persist for the session and are re-applied to every subsequent search. When two options genuinely conflict with a stated constraint, the agent asks rather than silently picking one.
- Multi-city and open-jaw itinerary construction
- Constraint memory with explicit re-confirmation on conflict
- Disambiguation instead of guessing at ambiguous cities or dates
- Comparison of fare families side by side, not just price
03 · Fare rules
Penalties in plain language, with the source attached
Fare rule text is close to unreadable by design. The agent renders the parts that matter — change fee, refundability, baggage, no-show treatment — into a sentence, and attaches the underlying rule paragraph so a human agent can verify the summary rather than trust it.
- Change, cancel and no-show penalties explained
- Baggage and cabin allowance by fare family
- Source rule text attached to every summary
- Visa and transit guidance flagged as advisory, never definitive
Deliberate limit: the agent gives visa and entry guidance as advisory only, with a link to the authoritative source. Immigration rules change without notice and getting one wrong strands a passenger — that is not a risk we automate.
04 · Servicing
The ticket is the beginning, not the end
Most of the cost in a travel contact centre is post-ticket: changes, reissues, refund eligibility, seat swaps, special assistance. The agent handles these within limits you set, and hands off to the disruption agents when an operational event — not a customer request — is what changed the itinerary.
- Voluntary changes and reissue with fare-difference collection
- Refund eligibility checked against the actual ticket, not the policy page
- Seat, meal and baggage changes post-issue
- Handover to IROPS agents on operational disruption
05 · Channels
One session that follows the traveller
Web, mobile, WhatsApp, voice and email reach the same agent core and share one session. A conversation that starts in the app at breakfast can finish on the phone at the airport with the held seat intact. When it escalates, the human receives the transcript, the tool history and a suggested next action — not a ticket that says "customer needs help".
- Web widget, mobile SDK, WhatsApp Business, voice, email
- Continuous session state across channel switches
- Agent-assist console with full context on handover
- Language detection with per-market tone configuration
06 · Safety
Bounded, observable, and tested before release
Spend and refund ceilings are enforced in the tool layer, not requested in the prompt. Retrieved content is treated as untrusted and filtered for injection attempts. Personal data is redacted before anything is written to a log. Every prompt or model change runs against a regression suite of real transcripts before it reaches a traveller.
- Hard spend and refund limits enforced outside the model
- Prompt-injection filtering on all retrieved content
- PII redaction in logs and traces
- Regression evaluations gate every release
Walk through it
Watch one booking complete.
Six steps from a vague request to an issued ticket. Click a step, or let it run.
Turn 1 · extraction
Window seat to Singapore Friday, under ₹40k, back Monday night.
dest SINbudget 40000seat windowdates inferred
Tool calls · 1.9 s wall clock
search_fares(gds)search_fares(ndc)dedupe_offers()
GDS41
NDC direct18
After dedupe11
Within budget3
Recommendation with reasoning
SQ 509 Value at ₹37,420. Lite is ₹3,320 cheaper but has no checked bag and no changes; you mentioned a Monday return that might move.
get_fare_rules()compare_families()
Seat map · 12A held
11A11C12A window · held12C14A14C
12A is held for 20 minutes. Nothing has been charged yet.
check_seatmap()hold_seat()
Confirmation gate
Total ₹37,420 including taxes and one 25 kg bag. Confirm to charge the card ending 4417.
Confirm.
The agent cannot reach the payment tool without an affirmative turn immediately following a stated exact total. That constraint lives in the tool layer.
Issued · session stays open
Ticketed. PNR 4FQ2XB, e-ticket sent to your email and added to your wallet. Ask me any time to change the seat or the return.
issue_pnr()send_documents()register_watch()
Specifications
The page your distribution and IT teams read.
- Core
- Agent orchestrator, tool layer, session store, retrieval index, policy engine, evaluation harness
- Model layer
- Claude models via the Anthropic API or AWS Bedrock; model version pinned per release
- Session state
- Constraints, entities and tool history; retention configurable, default 30 days
- Runtime
- Containerised on Kubernetes; horizontal scaling per channel
Architecture & components
- Search
- One-way, return, multi-city and open-jaw; flexible dates; nearby airports
- Comparison
- Fare families by price, change and refund rules, baggage and seat inclusion
- Booking
- Seat selection, ancillaries, payment, ticketing, document delivery
- Servicing
- Voluntary change and reissue, refund eligibility, seat and meal changes, special assistance requests
- Languages
- Detected per turn; tone and formality configurable per market
Conversation capabilities
- GDS
- Amadeus, Sabre, Travelport — search, price, book, ticket, servicing
- NDC
- Aggregator and direct carrier connections where available
- Carrier systems
- PSS and DCS for servicing; loyalty for balance and redemption
- Payments
- Gateway-agnostic; tokenised card handling, no PAN in the agent context
- Latency
- Search results typically within 2–4 s including parallel source calls
Distribution & inventory interfaces
- Web
- Embeddable widget or full-page; optional SSO to identify the traveller
- Mobile
- iOS and Android SDKs sharing the session with web
- Messaging
- WhatsApp Business API; extensible to other messaging platforms
- Voice
- SIP telephony with barge-in; the same tool layer as text
- Human handover
- Agent-assist console with transcript, tool history and suggested action
Channels
- Spend controls
- Per-transaction and per-session ceilings enforced in the tool layer, outside the model
- Approval gates
- Configurable thresholds route an action to a human before execution
- Injection defence
- Retrieved and third-party content treated as untrusted and filtered
- PII
- Redacted before logging; card data never enters the model context
- Tracing
- Per-conversation trace with prompts, tool calls, arguments, responses and token accounting
- Evaluation
- Regression suite over real transcripts gates every prompt or model change
Safety, observability & evaluation
- Deployment
- SaaS on our infrastructure, or in your cloud tenancy; VPC isolation available
- Data residency
- Region-pinned session and log storage; model region selectable via Bedrock
- Air-gapped
- Not possible — the model must be reachable. Stated plainly because it disqualifies some buyers
- Commercial model
- Platform fee plus per-conversation or per-transaction; inference cost passed through with a stated margin
- Support
- Enhanced or Critical recommended for passenger-facing deployments — see support tiers
Deployment & commercial
Interoperability
Systems we already speak to.
Naming a system states interoperability, not partnership or endorsement.
AmadeusGDS
SabreGDS
TravelportGDS
NDCAggregators
PSS / DCSCarrier systems
LoyaltyBalance · burn
WhatsAppBusiness API
SIPVoice telephony
CRMTraveller profile
Payment gatewaysTokenised
Anthropic APIClaude models
AWS BedrockIn-tenancy models
Deployment
Three ways to run it.
Managed SaaS
Fastest to launch. We run it; you configure policy, tone and limits.
- Live in weeks, not quarters
- We hold the model relationship
- Region-pinned data storage
Your cloud tenancy
Deployed into your account, VPC-isolated, models reached through your Bedrock.
- Your security posture and controls
- Your inference contract and billing
- Preferred by carriers and large OTAs
Assist-only
The agent drafts, a human sends. A low-risk way to build confidence before automating.
- No customer-facing autonomy
- Measures quality on real traffic
- Converts to full autonomy per intent
0Median time to ticketTarget for a simple return booking
0Search responseParallel GDS and NDC calls
0Claims backed by a tool callEnforced in the tool layer
0Typical pilot to launchOne channel, one market
Before you ask
The questions that decide the deal.
What stops it inventing a fare?
The tool layer, not the prompt. The agent has no fare data in its context until a search tool returns one, and the response renderer will not emit a price token that does not appear in a tool result from the current turn. If the search fails, the traveller is told the search failed. Prompt instructions alone are not a control we would sell you.
Who is liable if it books the wrong thing?
Commercially that is negotiated, and we do not pretend otherwise. Practically, the controls that matter are the confirmation gate before any charge, per-transaction spend ceilings, and a complete trace of what the traveller asked and what was executed. In pilots we normally start with a low ceiling and an approval gate on anything unusual, then raise the limits as the evidence accumulates.
How is model cost controlled and billed?
Inference is passed through at cost with a stated margin on a monthly statement, and every workflow has a hard token budget with alerting. During the pilot we measure actual cost per conversation on your traffic mix, so the rollout price is based on your data rather than an estimate. Runaway cost is a bug, and we treat it as one.
Can it run air-gapped or fully on-premise?
No. The model has to be reachable, whether through the Anthropic API or Bedrock inside your account. We can isolate everything else in your VPC and pin data residency, but if your requirement is a genuinely disconnected deployment, this product cannot meet it and we would rather say so now than during procurement.
What does the human see when it escalates?
The full transcript, every tool call with its arguments and response, the constraints the agent extracted, anything it holds — a seat, a quote, a pending payment — and a suggested next action with its reasoning. The agent also states plainly, in the conversation, why it is handing over. Escalation is a feature, not a failure metric we optimise away.
What does Flyaza deliberately not do?
It does not give definitive visa or immigration rulings — those are advisory with a link to the authority. It does not process name corrections beyond trivial typos, because a name mismatch has consequences a model should not adjudicate. And it does not handle disruption re-accommodation itself; that hands over to the IROPS agents, which work against operational policy rather than customer requests.
Also in the portfolio
Often deployed together.
Start in assist-only mode.
The agent drafts, your agents send. You get quality evidence on real traffic before a single traveller talks to it directly — and the switch to autonomy is per intent, not all at once.