Dispatch & Routing AI Agent

What this agent does

Builds the plan, not the authority to send it

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

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

Reason

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

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

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

Decide

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

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

Out

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

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

AgentHuman

1Load receivedTMS order, load tender, EDI message or dispatch board entry

2Clock and constraints gatheredStops, appointment windows, equipment, parking and the driver's recorded hours, each with its source

3Plan proposedRoute, sequence, ETA basis and confidence

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▼

6Dispatch systems updatedOnly where write access and approval policy allow it

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 required8 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 boundaryAgent 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 loadIllustrative example

Load

Planned leg

Arrival

Binding constraint

Confidence

ETA basis

Regional dry van

Break lands before the receiver's window opens

Tue 14:20 local

Elapsed on-duty window

88%

Recorded clock, no relief assumed

As receivedTaken 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 bindsThe window is elapsed time — detention spends it, and that moves the arrival.

ActionApproveAdjustSend to planning

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

Value

Where AI adds value

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

Where the value landsValue 01 – 04

Every loadFrom 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.

04Build 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 dispatchMcLeod · MercuryGate
Trimble · Revenova

Hours and telematicsSamsara · Motive
Omnitracs · Platform Science

Routing and mappingPC*MILER · HERE
Trimble Maps · Google Routes

Agent

Dispatch, routing & ETA planning

Reads the clock
Builds the plan
Holds for dispatch

Visibility and appointmentsproject44 · FourKites
Opendock · Terminal49

Observability & evaluationOpenTelemetry · 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 defenceInward → 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 – L2Test whether a plan may stand

L3Puts the send in a dispatcher's hands

L4 – L5Keep the plan and the constraints behind it

L6Drops 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

Depth of coverage ▼

E1Final-output evaluationWas the plan drivable on this driver's actual clock?

E2Step-level evaluationDid the agent use the right hours record, constraints and lane configuration?

E3Tool evaluationDid it read the correct driver and write the correct load?

E4Confidence calibrationDo low-confidence plans actually attract more dispatcher adjustments?

E5Slice evaluationHow does performance change across specific lane types?

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 lifecycleDirection of processing →

01 · Retrieval1 mode

AB-03

Stale hours record

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

Stage gathersStops, windows, equipment, parking and the hours record

02 · Reasoning2 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 proposesRoute, sequence, ETA basis and confidence

03 · Tool / write2 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 writesOnly where write access and approval policy allow it

04 · Output1 mode

AB-04

ETA without its basis

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

Stage returnsThe plan the dispatcher reads and the ETA on it

05 · Change / Version1 mode

AB-07

Silent constraint regression

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

Stage tracksModel, 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 aggregateIllustrative example

Slice	Failure rate	Lift	Status
Long-detention receivers	4.7%	3.6×	Review
Multi-stop regional runs	3.2%	2.5×	Review
Team and split-sleeper runs	2.2%	1.7×	Watch
Single-stop line-haul lanes	1.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 stagesSwitchback — the path turns at Improve and returns at Learn

01Detect

Plan-adjustment rate rises in a lane type.

02Diagnose

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

03Improve

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

04Verify

Release is blocked until the affected regression cases pass again.

05Learn

The case joins the permanent suite and the dispatch playbook.

Learn → DetectThe 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

01Dispatch workflow discovery and automation-boundary definition.

02TMS, ELD and mapping source assessment.

03Hours-limit, parking and lane-constraint rule mapping.

04Load and duty-record ingestion.

05Planning logic and constraint binding.

06Confidence scoring and refusal routing.

07Dispatcher release workflow.

08TMS and dispatch-system integration.

09Hours and constraint cases.

10Guardrails and dispatch controls.

11Plan-trail instrumentation.

12Deployment, documentation and Agent Care handover.

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 tier PilotOne lane set, one terminal ProductionProduction dispatch systems AdvancedMultiple 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 price From $5,000 From $8,000 Custom quote

Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction volume, approval controls and deployment requirements.

Separate from buildBuild 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.

You bringWe build with it

01Your lanes, equipment and dispatch rules → Load and duty-record ingestion and constraint mappingWeek 1

02Representative historical loads → Planning baseline, constraint binding and the ETA basisWeek 2

03Your hours source and lane constraints → Hours-limit, parking and lane-constraint rule mappingWeek 1

04Access to relevant APIs, feeds or exports → TMS, ELD and mapping assessment, then integration setupWeek 2

05Plans you would not want driven → Hours cases and failure-mode testingWeek 4

06What must reach a dispatcher before a driver moves → Confidence scoring, refusal routing, guardrails and dispatch controlsWeek 3

07Named dispatchers to release held plans → Dispatcher release workflow, then pilot and production validationWeeks 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 W1W2W3W4W5W6

Discovery W1

Build W2 – W3

Evaluate W4 – W5

Pilot & Launch W5 – 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 bandEach bar covers only the weeks its work is named in. The week 5 overlap is real, not padding.

At the end of W6Validation closes on live loads, and Agent Care picks up monitoring.

DurationSix-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.

Discuss this agent →

Nestack Agents · Dispatch & routingAGT-TR-01 · Agent Care available after launch