Main site

Travel & Hospitality AI agent · Baggage claims

Baggage & Claims-Status AI Agent

Report the status recorded on the claim, surface the notice window before it closes rather than after, and hold anything that would settle or value the claim for the baggage desk.

Typical delivery
4–6 weeks
Deployment
Your stack
Desk answers
Clock surfaced
After launch
Agent Care

What this agent does

Reports the status, never settles the claim

In

  1. 01

    Ingesting the claim file, the mishandling report, the scan history and the carrier's published terms.

  2. 02

    Normalising the times recorded on the file, so a clock runs from the event and not from the enquiry.

Reason

  1. 03

    Establishing whether the itinerary is domestic or international, because that selects the whole regime.

  2. 04

    Surfacing the notice window that applies to this claim, unprompted, whenever the passenger is answered.

  3. 05

    Naming the fee-refund trigger for this itinerary type rather than quoting one threshold for all of them.

Decide

  1. 06

    Flagging any question of value, coverage or liability the agent must not answer on its own.

  2. 07

    Routing the claim to the named baggage desk, which decides anything the passenger is owed.

Out

  1. 08

    Retaining the file, the times, the flags, the desk's amendments and the answer given to the passenger.

  2. 09

    Executing write actions only inside the approval boundaries agreed during implementation.

Product statement

The agent reports status and watches the clock; the baggage desk decides what a claim is worth, and the treaty and the carrier's terms set the limit.

Example workflow

One claim, report to answer

  1. 1Claim openedMishandling report, desk enquiry, call, chat or tracing update
  2. 2File assembledScans, recorded times, itinerary sectors, fees paid and the regime the journey sits under
  3. 3Status readStatus, the window that applies, confidence
  4. 4Controls appliedRegime selection, window tracking, fee-refund trigger checks and confidence threshold

No human action required

Stages 1 to 4 run unaided, and nothing is settled at any of them — the agent is reporting, and the claims desk's lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the claims desk to release.

Low confidence

Adds a baggage-manager read first.

Claims desk answer

The answer is held with the times on the file, its flagged lines and the confidence.

Release · Amend · Send to the claims desk

Released — the answer goes back

  1. 6Claim systems updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedAnswer corrections, flagged-line outcomes, missed windows and post-answer amendments

Amendments

Every desk amendment is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Settling a claim, or agreeing what it is worth.
    • Stating that a claim is approved or is covered.
    • Telling a passenger a bag is found or en route.
    • Filing the mishandling report for the passenger.

  • Automation boundary

    Agent acts unaided

    • ✓Report the status recorded against the file, and its time for the named owner.
    • ✓Surface the notice window that applies, before it closes.
    • ✓Name the fee-refund trigger that fits this itinerary type into the review queue.
    • ✓Route the claim to the baggage desk, and log the answer.

    Any write happens inside the boundaries agreed at implementation, never ahead of approval.

    • Extending, tolling or waiving a filing deadline.
    • Valuing contents, or accepting a proof of loss.
    • Making a delivery commitment from a scan alone.
  • Changes to window, threshold or answer rules.

Example output

One claim, annotated

Everything the agent reports is attached to the claim file it was read from.

Claims-status output · single file

Illustrative example
Claim
Delayed checked bag
Reported line
Checked-bag charge refunded — this is not payment for the loss
Fee refunded
$40.00
Source of record
Mishandling report
Confidence
90%
Attribution
Carrier terms and the treaty

As received

Taken from the claim file and the scan history on record — nothing on this side is written by the agent.

Source records used

  • Mishandling report
  • Handler scan history
  • Carrier published terms

Why this wording

It refunds the bag charge and says so and a person still decides.

What the score decides

Below the configured threshold the answer picks up a baggage-manager read.

Action

ReleaseAmendSend to the claims desk

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every claim

From the claim file

03Reporting

Report from the file

Draw on the recorded scans and times and the regime rules configured for that itinerary.

01Approved path

Watch the clock for them

Routine status questions arrive already answered with the window on them.

02Human review

Send review to the contested claims

Flagged value questions and low-confidence readings are marked, so the desk's read starts where risk concentrates.

04

Build an evidence trail

The claim, the times recorded against it and the person who answered stay on the file.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Baggage systems

    • SITA BagJourney
    • BagManager
    • WorldTracer
    • Type B messaging

  • Reservation systems

    • Amadeus Altéa
    • Sabre
    • Navitaire
    • Radixx

  • Ground and handling

    • Handler systems
    • scanners
    • Sorter and load feeds

Agent

Baggage and claims status

  • Reads the file
  • Watches the window
  • Holds for the desk

  • Claims and payments

    • Claims platform
    • CRM
    • Refund engine
    • ARC

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the passenger

Every control encloses the next. What survives the set is named in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeFall back to tracing status when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, window-rule and regime-configuration changes.Track
L4TraceabilityRecord the claim file, the reading, the times, the flags and the answer time.Record
L3Claims desk answerHold answers for the named claims desk; it governs release, not whether a released answer is right.Gate
L2Policy guardrailsTest readings against configured regime, window and fee-refund rules; a failure returns the reading.Restrict
L1Confidence thresholdsRoute low-confidence readings to a baggage-manager read before release.Require review
Model coreReading produced — status, the window that applies, flagged lines and confidence
L1 – L2
Test whether an answer may stand
L3
Puts the release in the claims desk's hands
L4 – L5
Hold the claim and the times recorded on it
L6
Falls back to tracing status when signals degrade

How Nestack evaluates it

Evaluate the claims workflow — not only the sentence at the end.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the answer the passenger hears

  1. E1Final-output evaluationDid the answer carry the notice window that applies to this claim?
  2. E2Step-level evaluationDid the agent use the right regime, scan history and recorded times?
  3. E3Tool evaluationDid it read and write the correct claim file and the correct sector?
  4. E4Confidence calibrationDo low-confidence readings actually attract more desk amendments?
  5. E5Slice evaluationHow does performance change across specific claim types?
  6. E6Business outcomeHow many answers needed a desk amendment or a correction afterwards?

Floor — the answer the carrier is held to

Failure modes

Where each failure originates in the agent

Seven ways a claim goes wrong, at the stage it starts.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • CW-03

      Stale tracing signal

      A scan is read as a place the bag has already moved on from.

    Stage gathers

    Claim file, scans, recorded times and regime rules

  2. 02 · Reasoning

    2 modes

    • CW-04

      Clock read from the enquiry

      The window is counted from the question, not from the event.

    • CW-06

      One threshold for all

      A single delay threshold is applied across every itinerary type.

    Stage proposes

    Status, the window that applies and confidence

  3. 03 · Tool / write

    2 modes

    • CW-02

      Reassurance late in the window

      A soothing update goes out with the window about to close.

    • CW-05

      Fee refund read as settlement

      A refund of the bag charge is described as payment for the loss.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • CW-01

      Delivery implied from a scan

      A positional read is stated to the passenger as an arrival.

    Stage returns

    The answer the desk releases and the carrier is held to

  5. 05 · Change / Version

    1 mode

    • CW-07

      Silent window-rule regression

      A model or rule change widens what the agent will assert.

    Stage tracks

    Model, prompt, window rules and regime config

  • Sev-1 · a claim answered off-boundary
  • Sev-2 · a window passes unstated
  • Sev-3 · source degrades, claim routes to review
See the complete Travel & Hospitality failure-mode catalogue

Affected slices

One claim type can carry the whole rate

Read every row against the base rate underneath it. Domestic single-carrier claims are the floor here and each other cohort is a multiple of that floor The cohorts that carry it are named, not averaged away..

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
International itineraries8.3%3.4×Review
Damage claims6.4%2.6×Review
Interline journeys4.4%1.8×Watch
Domestic single-carrier1.5%0.6×Normal

Bar: desk-amendment-rate lift vs. domestic single-carrier baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

Every cycle ends by adding a test

The loop closes on a case the next release must pass, not on an explanation. That suite is what the next claim answered at the desk is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Desk-amendment rate rises in a claim slice.

  2. 02

    Diagnose

    Within the same week the claims and the times recorded on them are read together, until the cause narrows to one.

  3. 03

    Improve

    The fix is versioned with the claims that motivated it.

  4. 04

    Verify

    Nothing ships while an affected case is failing.

  5. 05

    Learn

    The case is added for good, and the claim rules change.

  6. Learn → Detect

    The return edge. Detection next time runs against a suite one case longer.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, claims workflow, evaluation, integration, then production validation and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Claims workflow discovery and boundary definition.Week 1
  2. 02Baggage and tracing source assessment.Week 1, Week 2
  3. 03Notice-window and fee-refund rule mapping by regime.Week 1, Week 2
  4. 04Claim-file ingestion and normalisation.Week 2
  5. 05Window tracking and status binding.Week 2, Week 3
  6. 06Confidence scoring and claim routing.Week 3
  7. 07Claims desk answer workflow.Week 3, Week 4
  8. 08Baggage-system integration.Week 5
  9. 09Notice-window regression cases.Week 4, Week 5
  10. 10Guardrails and answer controls.Week 4
  11. 11Claim-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne carrier, one stationProductionProduction baggage systemsAdvancedMultiple carriers / stations
Introduced at Pilot
Reporting to your files and regimes✓✓✓
Claims desk answer✓✓✓
Answer-accuracy baseline✓✓✓
Introduced at Production
Reporting by claim type—✓✓
Approval workflow in your systems—✓✓
Approved write-back—✓✓
Baggage-system integration—✓✓
Introduced at Advanced
Multi-regime window rules——✓
Multi-stage claims approvals——✓
High claim volume——✓
Multi-carrier claim controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, claim volume, approval controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01Your claim files and the times you record

    Claim-file ingestion and time mapping

    Week 1

  2. 02Claims you have already answered

    Reporting baseline, window tracking and status binding

    Week 2

  3. 03Your regime scope and carrier terms

    Notice-window and fee-refund rule mapping

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Baggage, tracing and claims assessment, then integration setup

    Week 2

  5. 05Answers you would not want relied on

    Window cases and the evaluation suite

    Week 4

  6. 06What no answer may settle

    Confidence scoring, flag routing, guardrails and answer controls

    Week 3

  7. 07Named baggage staff to release answers

    Claims desk answer workflow, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Each phase occupies the weeks it needs, so the fifth week carries two kinds of work.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Claims workflow discovery, window mapping and the automation boundary

W2Source integration and the reporting baseline

W3Claims workflow, confidence logic and answer controls

W4Notice-window cases, held-act guardrails and failure-mode testing

W5Baggage-system integration, pilot claims and targeted corrections

W6One claim cycle answered under the baggage desk, then handover

Reading the band
A bar covers the weeks its work is named in, and nothing else. The week 5 overlap is real, not padding.
At the end of W6
The cycle closes validation and Agent Care assumes monitoring.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Travel & Hospitality AI agent

Build a claims-status agent that watches the clock for the passenger.

Miss the window for damage, or the separate window for delay, and no action lies against the carrier at all — which makes a soothing update late in the window the harm rather than the help. Bring your claim files, your tracing feed and the carrier terms you answer under, and we will map where each clock starts and who answers.

Typical delivery
4–6 weeks
Deployment
Your claims
Desk answers
No settlement
After launch
Agent Care available

Nestack Agents · Baggage and claims status

AGT-TH-10 · Agent Care available after launch

Build a claims-status agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your claims

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.