Main site

Transportation AI agent · Track and trace

Track-and-Trace Exception AI Agent

Carry the age and the source of each position, show silence as silence rather than a last-known point, and leave the exception close and the claim to a named person.

Typical delivery
4–6 weeks
Deployment
Your stack
Person decides
Age and source
After launch
Agent Care

What this agent does

Reports what the signal supports, and no more

In

  1. 01

    Ingesting positions, milestones and exceptions from supported ELD, telematics, carrier EDI or visibility sources.

  2. 02

    Carrying the age and the provenance of each position through to the status it produced.

Reason

  1. 03

    Marking a compliant ELD fix for what it is — accurate to about a mile, recorded hourly in motion.

  2. 04

    Treating a personal-conveyance position as deliberately coarse, because the rule degrades it on purpose.

  3. 05

    Separating what was observed from what was inferred, so a geofenced departure is labelled derived.

Decide

  1. 06

    Showing absence of signal as absence, rather than back-filling it or holding the last position forward.

  2. 07

    Labelling an ETA a prediction with its range, and reading any committed date from your own contract.

Out

  1. 08

    Retaining what was detected, when, what was escalated and to whom, against the shipment.

  2. 09

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

Product statement

The agent raises the exception; a named person closes it, turns any report into a claim, and signs any disallowance.

Example workflow

One shipment, signal to escalation

  1. 1Signal receivedELD position, telematics ping, carrier EDI update or a manual check call
  2. 2Provenance gatheredThe source of the signal, its age, the duty status it carried and the shipment it belongs to, each recorded
  3. 3Status preparedStatus, signal age, source and confidence
  4. 4Controls appliedSignal-age checks, provenance checks, observed-versus-inferred marking and the confidence threshold

No human action required

Stages 1 to 4 run unaided and publish nothing outward — the status is prepared, and the person's lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the named person to act on.

Low confidence

Adds a desk read first.

A person decides

The status is held with its signal age, its source and the confidence.

Escalate · Amend · Send to the desk

Escalated — exception raised

  1. 6Shipment records updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedSignal ages at publication, false clearances, escalations raised and what each exception turned out to be

Escalations

Every escalation to a person is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Closing an exception on inferred signal alone.
    • Turning a bad-order report into a cargo claim.
    • Stating a delivery date as a commitment or an SLA.
    • Deciding that a claim is disallowed, in whole or part.

  • Automation boundary

    Agent acts unaided

    • ✓Assemble the position, its age and the source it came from for the named owner.
    • ✓Mark what was observed and what was inferred from a geofence.
    • ✓Show absence of signal as absence, with the time it began.
    • ✓Hold the exception for the named person who decides on it.

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

    • Assuming Carmack governs, or which clock applies.
    • Answering a claimant on liability or on value.
    • Publishing a position outward without its age.
  • Changes to the exception rules or the thresholds.

Example output

One status, annotated

Everything the agent reports is attached to the signal it rested on.

Tracking output · single shipment

Illustrative example
Shipment
Dry van, two-stop
Status reported
No signal since the last intermediate log — not a position held forward
Signal age
2 h 14 m old
Signal source
ELD intermediate log
Confidence
90%
Observed or derived
Observed, not geofence-derived

As received

Taken from the ELD record and the carrier's feed — nothing on this side is extrapolated by the agent.

What the signal supports

  • A fix accurate to a mile
  • A record kept hourly
  • The duty status at the time

Why it is not real-time

The rule sets the floor at an hourly record and about a mile of accuracy.

What the score decides

Below the configured threshold the status picks up a desk read before it goes anywhere at all.

Action

EscalateAmendSend to the 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 shipment

From the visibility feed or the TMS

03Tracking

Report what the signal supports

Draw on the position, its age, its source and the duty status it was recorded under.

01Approved path

Say what the ping supports

Routine milestones come back with their age and source attached.

02Human review

Send the rest to a person

Stale signals, silence and low-confidence statuses are marked, so the desk's read starts where risk concentrates.

04

Build an evidence trail

The status, the source and age of the signal behind it and the person who acted stay on the shipment.

Integrations

Typical integrations

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

  • Visibility platforms

    • project44
    • FourKites
    • Trucker Tools
    • Macropoint

  • ELD and telematics

    • Samsara
    • Motive
    • Omnitracs
    • Platform Science

  • TMS and shipment records

    • McLeod
    • MercuryGate
    • Trimble
    • Revenova

Agent

Track and trace exceptions

  • Reads the signal
  • Ages the position
  • Holds for a person

  • Claims and documents

    • Claims systems
    • POD archives
    • Document management

  • 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 status

The layers nest, and each says what it does not catch. The map below carries the rest.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeRevert to last-known position when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, threshold and source-configuration changes.Track
L4TraceabilityRecord the signal, its age, its source and the status it produced.Record
L3Escalation heldHold the exception for the named person; it governs who acts, not whether the signal was right.Gate
L2Signal-age limitsTest each status against the age and provenance rules you set; a stale signal returns it.Restrict
L1Confidence thresholdsRoute low-confidence statuses to a desk read before they go anywhere.Require review
Model coreStatus prepared — the position, its age, its source and confidence
L1 – L2
Test whether a status may stand
L3
Puts the exception in a person's hands
L4 – L5
Hold the signal the status rested on
L6
Reverts to last-known position when signals degrade

How Nestack evaluates it

Evaluate the whole exception path — not only the status that was published.

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

Surface — the status the customer reads

  1. E1Final-output evaluationDid each status carry the age and source of the signal behind it?
  2. E2Step-level evaluationDid the agent use the right shipment, feed and duty-status record?
  3. E3Tool evaluationDid it read the correct feed and write the correct shipment?
  4. E4Confidence calibrationDo low-confidence statuses actually attract more desk reads?
  5. E5Slice evaluationHow does performance change across specific lanes and modes?
  6. E6Business outcomeHow many exceptions were escalated, and how many should have been?

Floor — the claim clock a wrong status can start

Failure modes

Where each failure originates in the agent

Seven ways a status goes wrong, set at its own stage.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • AY-03

      Stale ping read as current

      An hours-old fix is surfaced as where the truck is.

    Stage gathers

    Position, its age, its source and duty status

  2. 02 · Reasoning

    2 modes

    • AY-04

      Inference read as fact

      A geofenced departure is reported as a witnessed one.

    • AY-06

      Silence filled in

      A gap is closed with the last position rather than shown.

    Stage proposes

    The status, its signal age and confidence

  3. 03 · Tool / write

    2 modes

    • AY-02

      Status out without a person

      An exception clears before anyone has read it.

    • AY-05

      Duplicate exception

      One shipment raises the same exception twice.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • AY-01

      Personal conveyance misread

      A deliberately coarse position is treated as precise.

    Stage returns

    The status the customer and the desk read

  5. 05 · Change / Version

    1 mode

    • AY-07

      Silent threshold regression

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

    Stage tracks

    Model, prompt, age thresholds and source rules

  • Sev-1 · closed with no person
  • Sev-2 · a position published unaged
  • Sev-3 · signal degrades, status routes to review
See the complete Transportation failure-mode catalogue

Affected slices

Read each slice against the rate it starts from

A multiple means nothing without the rate underneath it, so the table carries the escalation rate each slice starts from alongside its lift over the contracted-lane baseline. Nestack reports both, because the multiple alone is easy to misread.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Shipments on carrier EDI only6.5%3.5×Review
Legs run in personal conveyance5.4%2.9×Review
Lanes with thin telematics cover3.7%2.0×Watch
Single-stop contracted lanes1.5%0.8×Normal

Bar: escalation-rate lift vs. contracted-lane baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

Which case does this failure become?

Nothing closes on a review meeting. It closes on a case the next release has to pass, and that suite is what the next exception raised is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Escalation rate rises in a lane or mode.

  2. 02

    Diagnose

    Was the fix wrong, or was it simply older than the answer it was used to give?

  3. 03

    Improve

    Every change ships against a version with the shipments attached.

  4. 04

    Verify

    The release is blocked while an affected case fails.

  5. 05

    Learn

    The case becomes permanent, and the exception rules are re-tested.

  6. Learn → Detect

    The return edge. Detection is re-run 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, exception workflow, evaluation, integration, then production validation and handover.

Workstream

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

  1. 01Tracking and exception workflow discovery and boundaries.Week 1
  2. 02Visibility and ELD source assessment.Week 1, Week 2
  3. 03Signal-age, provenance and escalation rule mapping.Week 1, Week 2
  4. 04Position and shipment ingestion.Week 2
  5. 05Status logic and signal binding.Week 2, Week 3
  6. 06Confidence scoring and desk routing.Week 3
  7. 07Escalation approval workflow.Week 3, Week 4
  8. 08Visibility and TMS integration.Week 5
  9. 09Signal-age and status cases.Week 4, Week 5
  10. 10Guardrails and escalation controls.Week 4
  11. 11Shipment-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 lane set, one feedProductionProduction visibility and TMSAdvancedMultiple partners / regions
Introduced at Pilot
Statuses carrying age and source✓✓✓
Escalation held for a person✓✓✓
Status-accuracy baseline✓✓✓
Introduced at Production
Reporting by lane and mode—✓✓
Escalation workflow in your systems—✓✓
Approved write-back—✓✓
Visibility-platform integration—✓✓
Introduced at Advanced
Multi-partner exception rules——✓
Multi-stage desk approvals——✓
High shipment volume——✓
Multi-partner tracking controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on integrations, workflow complexity, transaction 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 visibility feeds and their coverage

    Position and shipment ingestion and provenance mapping

    Week 1

  2. 02Representative past exceptions

    Status baseline, signal binding and age thresholds

    Week 2

  3. 03Your exception thresholds and escalation routes

    Signal-age, provenance and escalation rule mapping

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Visibility and ELD source assessment, then integration setup

    Week 2

  5. 05Statuses you would not want published

    Signal-age cases and failure-mode testing

    Week 4

  6. 06What a status may never assert on its own

    Confidence scoring, desk routing, guardrails and escalation controls

    Week 3

  7. 07Named people who act on an exception

    Escalation 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

The bands sit on the weeks the work occupies, so the fifth carries evaluation and launch together.

Phase

W1

W2

W3

W4

W5

W6

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

Week focus

W1Tracking workflow discovery, provenance mapping and the boundary

W2Visibility and ELD integration and the status baseline

W3Exception workflow, confidence logic and escalation controls

W4Evaluation suite, signal-age cases and failure-mode testing

W5TMS integration, a pilot lane set and targeted corrections

W6One shipment cycle tracked under the desk, then handover

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

Next step · Transportation AI agent

Build a tracking agent that says only what the ping supports.

Show us your feeds, your lanes and how an exception gets closed today. Then answer one question back — the last time a status was wrong, who found out, and how long after the claim clock had already started?

Typical delivery
4–6 weeks
Deployment
Your visibility stack
Person decides
Age and source
After launch
Agent Care available

Nestack Agents · Track and trace exceptions

AGT-TR-11 · Agent Care available after launch

Build a track-and-trace agent

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

About you
Your shipments

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