The agent can read, simulate, and classify​

The agent has access to a small, well-defined toolset:

• searchAlternateHotels(params) — read-only search outside the current policy.
• listContractInventory(airport) — read direct-contract availability.
• computePolicyRelaxationCost(fields, values) — pure simulation, no writes.
• classifyFailureCause(attemptedHotels) — classification only.
• summarizeCase(caseUrn) — structured summary for the agent's own context.

Every tool in the list is read-only. There is no createBooking, no cancelReservation, no sendNotification, no modifyPolicy, no grantRole. The agent literally does not have those tools.

Enforcement at the adapter layer​

We keep this promise by building the agent's tool registry at process start from a static allow-list, not from a prompt-side description. The agent runtime is constructed with exactly the tools we listed; its final message is either a tool call into this finite set or a terminal recommendation envelope.

A prompt-injection attack that tries to convince the model to "now, go book this hotel directly" fails at the first token after the tool name: there's no such tool registered. The model isn't being tricked by a careful prompt — it's physically unable to call a write tool.

Why not a "confirm before doing" checkpoint?​

Tempting, but wrong for this domain. The confirm pattern puts the human in the loop for one action at a time, which looks great in a demo but is terrible at 2 a.m. when an operator is handling 40 cases simultaneously. What they actually want is a curated list of proposals they can scan, triage, and apply in bulk.

So the agent produces ranked recommendations with costs attached. The operator sees three one-line proposals, picks one, confirms, and moves on. The click is a single endpoint — a clean, audited, human-originating HTTP call — not a multi-step negotiation with an LLM.

What ends up in audit​

Every agent run writes:

• Input: the review item, the attempted hotels, the policy version.
• Output: the ranked recommendations with cost estimates.
• Tool trajectory: which tools were called, in what order, with what arguments.
• Meta: model version, token usage, latency.

If a recommendation turned out to be wrong — hotel sold out between recommendation and action — we can replay the trajectory and see whether the agent had stale data or made a bad call. That fidelity is what lets us improve the agent safely across quarters.

Does it work?​

Early numbers from our launch partner:

• ~70% of manual-review items have their rank-1 agent recommendation accepted by the operator.
• Median time-to-resolve dropped from 9 minutes to 3.5 minutes.
• Zero agent-initiated bookings, because the agent cannot initiate bookings.

The third number is the point.

Principle: allow-list over prompt engineering​

The agent is useful because it reasons over the case and proposes high-quality actions. It's safe because it cannot do anything destructive, regardless of what the prompt says. Good prompts are valuable — but for safety, we trust the adapter layer, not the prompt. That's the thing prompt-engineering literature can't give you and code can.

If you're building agents for high-stakes workflows, start by writing down the list of tools the agent can and cannot have. If you find yourself needing a tool your safety story can't support, that's the real discussion — not a prompt tweak.

Why a custom model​

The canonical "predict flight cancellation" demo runs an off-the-shelf tabular AutoML over a flight-ontime CSV. That's a fine starting point, but the real signal isn't in the flight data — it's in the features around the flight: storm pressure, runway NOTAMs, crew labor state, airport traffic density, recent cancel rate, seasonality.

We built a dual-head model — one head for cancel probability, one for delay minutes — because they share features heavily but need different loss functions (logistic vs. regression). Training both heads in a single managed job wins on training simplicity and inference latency.

A clean serving contract​

The Nexa AI Model exposes a small, versioned contract internally:

POST /predict
{
  "instances": [
    {
      "airportIata": "MAD",
      "destinationIata": "JFK",
      "departureScheduledAt": "2026-04-22T16:00:00Z",
      "values": {
        "weatherPressure": 0.42,
        "laborPressure": 0.10,
        "trafficPressure": 0.25,
        "hazardPressure": 0.05,
        "flightOpsPressure": 0.37,
        "destinationPressure": 0.28,
        "recentCancelRate": 0.12,
        "seasonalityWeight": 0.6
      }
    }
  ]
}

Response:

{
  "predictions": [
    { "cancelProbability": 0.072, "predictedDelayMinutes": 23, "confidenceScore": 0.78 }
  ]
}

Clean, minimal, and versioned — the model carries a schema version so we can evolve feature shapes without breaking callers.

The deterministic fallback​

The Nexa API has a deterministic baseline it falls back to if the trained model is unreachable. This matters because disruption events don't wait for your inference service to be healthy. The baseline is a simple linear combination over the same features — accurate enough to be useful, fast enough to always answer.

Does it actually help?​

On our launch partner's history, pre-warming allocation when cancelProbability > 0.6 with confidenceScore >= 0.7 shaves ~8 minutes off the mean "event to voucher" time. The inventory cache is hot, contract rooms are soft-held, and the airport operator has been paged before the airline's disruption system is done with its own state transitions.

Useful number: ~8 minutes × ~200 affected passengers per disruption × disruptions per day = a meaningful reduction in both passenger frustration and overtime cost for the night shift.

What's next​

• Weekly incremental retraining (already in) with a quarterly full retrain + hyperparameter sweep.
• Feature contract unification so the same features used at training are guaranteed at serving.
• Region-specific sub-models for airports with unusual patterns (high-altitude, curfewed, hub-and-spoke).

For the full architectural deep-dive — multi-agent signal layer, the 14-feature snapshot, the deterministic baseline that's currently outperforming the trained head, and the runtime/trainer feature drift we're working off — see Inside the Flight Predictor.

What Nexa does​

Nexa ingests a disruption event, computes the stay plan per passenger group, searches every connected hotel source in parallel, ranks candidates under a policy the airline controls, executes the booking with retries and fallbacks, and sends a voucher — usually in under two minutes.

A few things make it different:

• Policy-driven, not hard-coded. Ops teams edit the rules — per tier, per airport, per airline — without a release cycle. A Nexa AI synthesizer turns English into structured policies for fast drafting.
• Multi-provider, not single-vendor. Amadeus, Hotelbeds, and your in-house contracts compete in the same ranking. Direct contracts usually win — which is how you see 10–20% savings on hotel spend.
• Nexa Trained Models on Google where they buy leverage. A flight-disruption predictor pre-warms contingencies. An exception agent triages stuck cases with read-only tools, proposing actions a human approves. There is no third-party AI API for the customer to provision.
• Auditable, every step. Every decision — automated or manual — writes an immutable audit entry with actor, reason, and before/after snapshot.

Who it's for​

Airline operations centers, station managers, and the irregular-operations teams who've been running this on spreadsheets. Group / alliance deployments with multi-tenant isolation.

Try it​

• Read the docs — start with the overview, then run the quick-start.
• Request a sandbox — we'll set you up with limited sandbox providers so you can drive the pipeline end-to-end in an afternoon.

There's a lot more to share — on the allocation scorer, how we train and deploy the predictor on Google, the exception agent's tool allow-list, the idempotency contract, the multi-tenant model. We'll cover each in the coming weeks.

Welcome to Nexa.