How an airline AI agent completes a transaction
An airline agent transaction is complete when the approved purchase or change is confirmed in the relevant systems, including payment and promised services. Returning an offer, receiving an HTTP success response or changing the itinerary is only part of that work.
Reviewed · Buyer guidance with limited synthetic implementation evidence
Separate the systems from the agent interface
IATA describes NDC as an exchange format built around offers and orders. That standard does not tell a buyer which products, issuing channels or servicing operations a particular connection exposes. Ask for capability evidence from the actual backend and adapter. See IATA’s NDC overview.
- Airline systems
- Supply the available offers, prices, orders, ticket or service records and supported operations. The relevant PSS, order, payment or service system remains authoritative for its part of the result.
- Backend adapter
- Translate the selected workflow into supported calls. Preserve passenger and segment references, status, amounts and limitations. An interface version alone does not establish the adapter’s coverage.
- Agent interface and controls
- Identify the caller, scope access, expose structured actions, evaluate airline policy and bind execution to the approved request. Aviark’s AFCI interface is intended for this layer.
- Agent experience
- Interpret the traveler’s request, explain options and obtain the required decisions. A fluent response cannot substitute for a backend confirmation.
AFCI means Agent-Facing Commerce Interface. Aviark stewards the specification and builds its maintained implementation. A specification’s list of actions is not a list of deployed capabilities. Likewise, MCP transport authorization controls access to a server; it does not by itself establish consent to a particular fare, charge or itinerary. The distinction follows from the scope of the MCP authorization specification, version 2025-06-18.
A transaction needs six explicit checkpoints
The same questions apply to a new booking, an optional bag or upgrade on an unchanged trip, and a supported flight change. A traveler request can start the workflow; an airline event is optional.
Establish access and capability.
Identify the caller and permitted traveler or order population. Confirm the issuing channel, backend operations and products that can actually be changed. Unsupported orders should be identified before a write is attempted.
Retrieve current state and quote the complete plan.
Read itinerary, passenger-level services and relevant restrictions. Present total price, fees, expiry, retained benefits and uncertainties. Distinguish an existing entitlement from a new purchase. An unavailable field is not evidence that a service is absent.
Obtain the traveler’s decision.
Show the exact proposed action and financial effect. For a multi-part request, disclose dependencies and possible partial completion. A materially changed quote or outcome needs a fresh decision; permission to monitor a trip is not permission to spend.
Apply separate airline authorization.
Evaluate policy, caller scope and any operator decision required for that exact action. In Aviark’s tested servicing path, traveler consent and airline authorization are separate gates. A routine policy approval cannot stand in for the traveler’s consent.
Execute a bounded operation.
Use a stable operation identifier and an explicit plan for payment and fulfillment. Record what was submitted and prevent accidental repetition. Do not imply that independent airline, payment and service operations form one atomic transaction.
Verify and explain the result.
Read back the relevant authoritative records. Check flight, cabin, each passenger’s seats and bags, payment status and service fulfillment against the approved plan. Report completed, pending, failed and unknown components separately, with a recovery owner.
A timeout is not a reason to buy twice
A request can commit at the supplier and lose its response on the way back. Repeating it with a new identifier may create another purchase or charge. HTTP guidance limits automatic retries of non-idempotent requests unless the caller knows the operation is safe to repeat or knows the original was not applied. See RFC 9110, section 9.2.2.
In the tested Aviark servicing path, a completed request can return its recorded result. An uncertain backend result instead stops another execution attempt until reconciliation. Returning a saved result does not discover a supplier’s unknown state; those are different recovery cases.
Illustrative partial outcome — not a completed Aviark capability
Suppose an approved itinerary change succeeds but a requested seat purchase fails. The response should identify the changed flight, unresolved seating, payment state and responsible operator. It must not report the whole request as successful or silently buy a replacement. Reversal is itself an operation with eligibility, cost and authorization requirements.
What we checked on 30 September 2026
Aviark ran its existing isolated servicing safety tests with temporary local state, synthetic travelers and orders, and deterministic provider responses. The following checks passed. No airline or payment-network transaction was performed in this run. These are implementation tests, not certification, performance measurements or customer production evidence.
Airline policy permits a routine change
No execution token was issued until the linked traveler consented. Another traveler and a forged consent request were rejected.
Limit: Synthetic identity and consent flow; not a production identity-provider assessment.
The traveler agrees, but airline approval is still required
Traveler consent alone did not issue an execution token. A denied request stayed denied when a later approval was attempted.
Limit: One configured policy path; not proof that every airline policy is implemented.
A completed request is repeated after stored state is reopened
The saved result was returned after closing and reopening the database connection. The mocked backend change ran once; reuse with a different payload was rejected.
Limit: A deterministic replay check; not a distributed-system or load test.
The backend response is uncertain
An injected failure marked the outcome for reconciliation. A subsequent execution attempt with a new option and approval was blocked.
Limit: A simulated ambiguity; not proof of automated supplier reconciliation or refund recovery.
Separately, the current sandbox supports search, booking, paid-seat inclusion at booking, date changes and cancellation. That is not full passenger-level fulfillment proof. Post-booking ancillary purchases, exposed cabin upgrades, service preservation and complete compound-request recovery remain implementation work. Production backends and named agent-platform integrations require their own validation.
Ask for evidence at every boundary
- Which exact orders, products and issuing channels can the adapter read and write?
- What happens when the quote expires, the traveler declines, or airline authorization is withheld?
- Can a restart or repeated request cause a second execution? How is an unknown supplier outcome resolved?
- Which records prove that every promised service and payment outcome was fulfilled?
- Who owns recovery when only part of the approved plan completes?
Use the seats, bags and upgrades readiness checklist to turn those answers into a bounded proof of value. Keep the first workflow small enough to verify, without treating that first workflow as the limit of airline commerce.
Discuss a supported transaction