Main site

Transportation AI agent · Dispatch

Dispatch & Routing AI Agent

Plan loads, routes and ETAs against the driver's recorded hours and configured constraints, name what binds each plan, and hold it for a dispatcher — the driver judges whether it can be driven.

Typical delivery
4–6 weeks
Deployment
Your stack
Dispatcher sends
Pre-dispatch
After launch
Agent Care

What this agent does

Builds the plan, not the authority to send it

In

  1. 01

    Ingest the loads, the equipment and the driver's recorded hours from supported TMS, ELD or dispatch sources.

  2. 02

    Normalise stops, appointment windows and duty status, and carry each value forward with its source.

Reason

  1. 03

    Build the route and the stop sequence against the clock this driver actually has, not a fresh one.

  2. 04

    Apply the hours limits in 49 CFR 395.3, the parking and the lane constraints as hard constraints.

  3. 05

    Model detention as time the elapsed on-duty window keeps spending, and re-test when it overruns.

Decide

  1. 06

    Name the constraint that binds the plan, and return no feasible plan rather than an ETA the clock cannot support.

  2. 07

    Stop when a driver cites hours, fatigue or a defect, and hand the load to a dispatcher.

Out

  1. 08

    Retain the plan, the constraints behind it, the refusal verbatim and the dispatcher's decision.

  2. 09

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

Product statement

The agent plans; a dispatcher sends the load, and the driver's own judgement under 49 CFR 392.3 stays the last word.

Example workflow

One load, board to dispatcher

  1. 1Load receivedTMS order, load tender, EDI message or dispatch board entry
  2. 2Clock and constraints gatheredStops, appointment windows, equipment, parking and the driver's recorded hours, each with its source
  3. 3Plan proposedRoute, sequence, ETA basis and confidence
  4. 4Controls appliedHours-limit checks, parking and appointment constraints, refusal stops and confidence threshold

No human action required

Stages 1 to 4 run unaided and send nothing — a legal clock is not permission to drive, so the dispatcher's lane opens at the confidence gate.

5DecisionBranches at the confidence threshold
High confidence

Goes to the dispatcher to decide.

Low confidence

Adds a planner's read first.

Dispatcher release

The plan is held with its binding constraint, the hours it assumed and the confidence.

Approve · Adjust · Send to planning

Approved — released to dispatch

  1. 6Dispatch systems updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedPlans held, binding constraints, dispatcher adjustments and what happened on the road

Adjustments

Every dispatcher adjustment is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Sending a load to a driver, or tendering it out.
    • Overriding an hours constraint the plan reports.
    • Re-planning around a driver's refusal to drive.
    • Committing a delivery appointment to a customer.

  • Automation boundary

    Agent acts unaided

    • ✓Plan the route and stop sequence against the recorded clock.
    • ✓Show what binds the plan, and where the break must land.
    • ✓Produce an ETA with the hours and the stops behind it.
    • ✓Stop on a constraint or a refusal and hold the load for a dispatcher.

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

    • Invoking adverse-conditions or emergency relief.
    • Proposing or accepting an edit to the hours record.
    • Deciding whether a driver is fit to drive at all.
  • Changes to the constraint set or dispatch thresholds.

Example output

One load plan, annotated

Everything the agent proposes is attached to the clock it was planned against.

Dispatch output · single load

Illustrative example
Load
Regional dry van
Planned leg
Break lands before the receiver's window opens
Arrival
Tue 14:20 local
Binding constraint
Elapsed on-duty window
Confidence
88%
ETA basis
Recorded clock, no relief assumed

As received

Taken from the TMS order and the driver's hours record — nothing on this side is estimated by the agent.

Constraints used

  • Recorded duty status
  • Detention at the shipper
  • Parking at the break point

Why this binds

The window is elapsed time — detention spends it, and that moves the arrival.

What the score decides

Below the configured threshold the plan picks up a planner's read before the dispatcher sees it.

Action

ApproveAdjustSend to planning

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 load

From the board or the TMS

03Planning

Plan against the clock

Draw on the driver's recorded hours and the constraints you configured for the lane and the equipment.

01Approved path

Plan it, a dispatcher sends it

Routine lane plans and stop sequences arrive already built.

02Human review

Send review to what binds

Infeasible plans, refusals and low-confidence ETAs are marked, so the dispatcher's read starts where risk concentrates.

04

Build an evidence trail

The plan, the hours and constraints behind it and the dispatcher who released it stay on the load.

Integrations

Typical integrations

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

  • TMS and dispatch

    • McLeod
    • MercuryGate
    • Trimble
    • Revenova

  • Hours and telematics

    • Samsara
    • Motive
    • Omnitracs
    • Platform Science

  • Routing and mapping

    • PC*MILER
    • HERE
    • Trimble Maps
    • Google Routes

Agent

Dispatch, routing & ETA planning

  • Reads the clock
  • Builds the plan
  • Holds for dispatch

  • Visibility and appointments

    • project44
    • FourKites
    • Opendock
    • Terminal49

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

Each control wraps the one inside it. What a layer does not catch is named in the map below it.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeDrop the agent to plain routing when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, constraint-rule and hours-configuration changes.Track
L4TraceabilityRecord the plan, the constraints, the refusal verbatim and the release time.Record
L3Dispatcher releaseHold the plan for a dispatcher; it governs release, not whether the plan can be driven.Gate
L2Constraint guardrailsTest the plan against the hours limits and the configured constraints; a failure returns no feasible plan.Restrict
L1Confidence thresholdsRoute low-confidence plans to a planner's read before the dispatcher sees them.Require review
Model corePlan produced — route, sequence, ETA basis, binding constraint and confidence
L1 – L2
Test whether a plan may stand
L3
Puts the send in a dispatcher's hands
L4 – L5
Keep the plan and the constraints behind it
L6
Drops the agent to plain routing when signals degrade

How Nestack evaluates it

Evaluate the whole planning workflow — not only the ETA at the end.

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

Surface — the plan the dispatcher reads

  1. E1Final-output evaluationWas the plan drivable on this driver's actual clock?
  2. E2Step-level evaluationDid the agent use the right hours record, constraints and lane configuration?
  3. E3Tool evaluationDid it read the correct driver and write the correct load?
  4. E4Confidence calibrationDo low-confidence plans actually attract more dispatcher adjustments?
  5. E5Slice evaluationHow does performance change across specific lane types?
  6. E6Business outcomeHow many plans were adjusted, and how many failed once the truck was rolling?

Floor — the road the driver actually has

Failure modes

Where each failure originates in the agent

Seven ways a plan goes wrong, placed at its own stage.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • AB-03

      Stale hours record

      The clock is read from a cached or partial duty record.

    Stage gathers

    Stops, windows, equipment, parking and the hours record

  2. 02 · Reasoning

    2 modes

    • AB-01

      Plan that cannot be driven

      The route needs hours the driver's clock does not hold.

    • AB-06

      Relief used as planning slack

      Adverse-conditions or emergency relief is consumed in advance.

    Stage proposes

    Route, sequence, ETA basis and confidence

  3. 03 · Tool / write

    2 modes

    • AB-02

      Load sent without a dispatcher

      A write releases the load before a person has taken it.

    • AB-05

      Refusal re-planned around

      The same driver is put back on the load after refusing.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • AB-04

      ETA without its basis

      An arrival time is returned with no constraint named behind it.

    Stage returns

    The plan the dispatcher reads and the ETA on it

  5. 05 · Change / Version

    1 mode

    • AB-07

      Silent constraint regression

      A model or rule change loosens what the planner treats as feasible.

    Stage tracks

    Model, prompt, constraint rules and hours config

  • Sev-1 · a plan that cannot be driven legally
  • Sev-2 · a wrong ETA reaches the customer
  • Sev-3 · hours record degrades, plan routes to review
See the complete Transportation failure-mode catalogue

Affected slices

Overall feasibility can hide one bad lane

The slice that hides here is the long-detention receiver — feasible on paper until the dock spends the window. A fleet-wide average never shows it, so Nestack reports the adjustment rate by lane type.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Long-detention receivers4.7%3.6×Review
Multi-stop regional runs3.2%2.5×Review
Team and split-sleeper runs2.2%1.7×Watch
Single-stop line-haul lanes1.2%0.9×Normal

Bar: plan-adjustment-rate lift vs. line-haul baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

A cycle ends in a regression case

A cycle closes when the failure is a regression case the next release has to pass. That suite is what the next plan off the board is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Plan-adjustment rate rises in a lane type.

  2. 02

    Diagnose

    Within the shift it surfaced, the plans and the clocks behind them are read until one cause holds.

  3. 03

    Improve

    The change ships against a version, with the loads that exposed it attached.

  4. 04

    Verify

    Release is blocked until the affected regression cases pass again.

  5. 05

    Learn

    The case joins the permanent suite and the dispatch playbook.

  6. Learn → Detect

    The return edge. The next detection 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, planning workflow, evaluation, integration, then production validation and handover.

Workstream

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

  1. 01Dispatch workflow discovery and automation-boundary definition.Week 1
  2. 02TMS, ELD and mapping source assessment.Week 1, Week 2
  3. 03Hours-limit, parking and lane-constraint rule mapping.Week 1, Week 2
  4. 04Load and duty-record ingestion.Week 2
  5. 05Planning logic and constraint binding.Week 2, Week 3
  6. 06Confidence scoring and refusal routing.Week 3
  7. 07Dispatcher release workflow.Week 3, Week 4
  8. 08TMS and dispatch-system integration.Week 5
  9. 09Hours and constraint cases.Week 4, Week 5
  10. 10Guardrails and dispatch controls.Week 4
  11. 11Plan-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 terminalProductionProduction dispatch systemsAdvancedMultiple terminals / regions
Introduced at Pilot
Planning to your clock and rules✓✓✓
Dispatcher release✓✓✓
Plan-quality baseline✓✓✓
Introduced at Production
Reporting by lane type—✓✓
Release workflow in your systems—✓✓
Approved write-back—✓✓
TMS integration—✓✓
Introduced at Advanced
Multi-region constraint sets——✓
Multi-stage dispatch approvals——✓
High load volume——✓
Multi-region dispatch 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 lanes, equipment and dispatch rules

    Load and duty-record ingestion and constraint mapping

    Week 1

  2. 02Representative historical loads

    Planning baseline, constraint binding and the ETA basis

    Week 2

  3. 03Your hours source and lane constraints

    Hours-limit, parking and lane-constraint rule mapping

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    TMS, ELD and mapping assessment, then integration setup

    Week 2

  5. 05Plans you would not want driven

    Hours cases and failure-mode testing

    Week 4

  6. 06What must reach a dispatcher before a driver moves

    Confidence scoring, refusal routing, guardrails and dispatch controls

    Week 3

  7. 07Named dispatchers to release held plans

    Dispatcher release 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 sits on the weeks it actually occupies, and week 5 carries both evaluation and launch work.

Phase

W1

W2

W3

W4

W5

W6

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

Week focus

W1Dispatch workflow discovery, constraint mapping and the automation boundary

W2TMS, ELD and mapping integration and the planning baseline

W3Planning workflow, confidence logic and release controls

W4Evaluation suite, hours cases and failure-mode testing

W5Dispatch-system integration, pilot lanes and targeted corrections

W6One dispatch cycle planned under the desk, then Agent Care 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
Validation closes on live loads, 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 dispatch agent around the clock your drivers actually have.

Show us your lanes, your hours source and your dispatch board. You bring the constraints you already plan by and the dispatchers who send; we map the workflow and set the boundary.

Typical delivery
4–6 weeks
Deployment
Your dispatch stack
Dispatcher sends
Pre-dispatch
After launch
Agent Care available

Nestack Agents · Dispatch & routing

AGT-TR-01 · Agent Care available after launch

Build a dispatch agent

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

About you
Your fleet

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