Airline commerce for AI agents

Core scope and current sandbox

Shopping, booking, ancillaries, upgrades and servicing are core product scope. Disruption is one use case. A traveler request or an airline event can initiate a workflow; neither determines which workflow a customer should start with.

Swipe the table to compare scope with current sandbox support.

The demonstration uses fictional Halcyon Air, simulated identity and events, and a test backend. It demonstrates part of the execution foundation, not production airline coverage. A combined flight change, preserved seats and bags, and optional upgrade remains a product target.

How AFCI fits with NDC and PSS systems

AFCI means Agent-Facing Commerce Interface. It is the open specification Aviark stewards; Aviark’s maintained implementation and operating support are separate from the specification. Interface definitions describe possible capabilities. They do not establish that a particular airline adapter implements them.

Aviark’s integration approach connects an airline-controlled agent endpoint to supported backends, including New Distribution Capability (NDC) implementations, passenger service systems (PSS), order systems and ancillary services. It complements those systems: the authoritative backend must supply the offers, eligibility, prices and order state needed for each action.

Customer discovery must establish the specific system version, booking authority, reachable orders and supported products. Identity, payment, deployment, data flows and recovery ownership also require agreement and validation. Agent channels need their own authentication and integration testing. An MCP server, REST interface or discovery record alone does not prove production support for any named personal-agent platform.

What governed execution requires

1. Retrieve and quote. Read current order and service state. Check eligibility and quote the selected action, including price, conditions and expiry. An event is a prompt to check, not permission to act.
2. Separate permissions. For servicing, obtain traveler consent to the exact quoted action and separate airline authorization. Airline policy may allow a routine case without an operator; it does not replace traveler consent. Material changes require fresh approval.
3. Execute and reconcile. Submit the approved action through a supported adapter. Retries must avoid duplicate execution. An uncertain backend outcome requires reconciliation before another attempt.
4. Verify the whole result. Read authoritative state again and identify completed, pending and failed components. A changed flight alone does not prove that purchased seats or bags were preserved.

Choose a bounded first workflow

Start with a customer problem, a real caller, accessible orders and a measurable gap. The first workflow may be a purchase, upgrade or change. Agree the supported population, exception path, acceptance criteria and operating owner before rollout.

Evaluate fulfilled purchases and incremental contribution against a baseline. For servicing, examine verified resolution, preserved entitlements, repeat contacts and total operating cost. These are evaluation measures, not established Aviark revenue uplift or savings claims.

Scope implementation separately from annual workflow coverage, capacity and support. A proof of value should establish backend behavior, failure handling and operational readiness before a limited production rollout is agreed.

Put the workflow to the test

Use these resources to examine execution controls and qualify a first commercial workflow. Each distinguishes evaluation requirements from current Aviark evidence.