Transportation AI agent · Driver support
Driver-Support Copilot AI Agent
Answer the questions drivers actually ask from your own written policies, stop the moment a driver cites hours, fatigue or a defect, and hand that exchange to a named person.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Person takes it
- Never presses
- After launch
- Agent Care
What this agent does
Answers the question, and stops where it must
In
- 01
When a driver asks, the copilot reads your policies, the recorded clock and the load from supported fleet systems.
- 02
When a policy is quoted, the reply carries the document and the section it was read from.
Reason
- 03
Where the recorded clock is the answer, it is shown as recorded — not as permission to drive.
- 04
When hours remain but fatigue is raised, the copilot says the clock is not a fitness judgement (49 CFR 392.3).
- 05
Where a driver cites hours, fatigue, illness or a defect, the exchange stops and routes to a person.
Decide
- 06
When a request has already been refused, it is never put a second way, reframed or re-costed.
- 07
Where pay, ranking, priority or standing would answer, that output is blocked instead (49 CFR 390.6).
Out
- 08
When the vehicle is moving, the copilot will not press for a reply (49 CFR 392.80, 392.82).
- 09
Where a write is needed, it happens only inside the approval boundaries agreed during implementation.
Product statement
The copilot answers; a named manager takes whatever it stops on, and the driver's own judgement under 49 CFR 392.3 stays the last word.
Example workflow
One question, driver to manager
- 1Driver question receivedIn-cab app, phone, message thread or driver portal
- 2Policy and record gatheredYour written policies, the recorded duty status, the load and the unit's open defects, each with its source
- 3Answer draftedAnswer, the policy cited and confidence
- 4Controls appliedCoercion-gate checks, consequence-language blocks, duty-status gate and confidence threshold
No human action required
Stages 1 to 4 run unaided and press nobody — a refusal ends the exchange where it was made, and the manager's lane opens at the confidence gate.
Answers the driver from the policy.
Adds a manager's read first.
Manager hand-off
The exchange is held with the driver's words, the policy read and the confidence.
Acknowledge · Answer · Send to manager
Taken — handed to a person
- 6Fleet systems updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedStops taken, blocked consequence language, manager hand-offs and what the driver did next
Hand-offs
Every manager hand-off is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Telling a driver they are fit or safe to drive.
- Editing, certifying or resubmitting the hours record.
- Re-asking after a driver has refused to drive.
- Raising pay, ranking or standing in an hours exchange.
Automation boundary
Agent acts unaided
- ✓Answer routine questions from your own written policies for the named owner.
- ✓Show the recorded clock, and the section it came from.
- ✓Stop the exchange when a driver cites hours or fatigue.
- ✓Log the driver's words and the copilot's reply verbatim into the review queue.
Any write happens inside the boundaries agreed at implementation, never ahead of approval.
- Clearing a reported defect or releasing the unit.
- Giving a driver legal, medical or compliance advice.
- Deciding whether a driver should be disciplined.
- Changes to the escalation rules or the stop gates.
Example output
One exchange, annotated
Everything the copilot says is attached to the policy it was read from.
Driver-support output · single exchange
Illustrative example- Driver
- Regional line-haul
- What was asked
- “I am out of hours for that delivery window”
- Recorded clock
- 1h 40m on the 14
- Policy read
- Fatigue and hours policy
- Confidence
- 91%
- What happened next
- Stopped, handed to a manager
As received
Taken from the driver's own words and the recorded duty status — nothing on this side is inferred by the copilot.
What was read
- Your fatigue policy
- The recorded duty status
- The unit's open defects
Why it stopped
The driver cited hours — under 49 CFR 390.6 the next sentence is the carrier's.
What the score decides
Below the configured threshold the exchange picks up a manager's read before.
Action
AcknowledgeAnswerSend to managerValue
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 driver question
From the cab or the app
Answer from your policy
Draw on your own written policies, the recorded duty status and the load record for this driver.
Answer without pressing
Routine policy and paperwork questions come back already answered.
Send the rest to a person
Stops, blocked outputs and low-confidence answers are marked, so the manager's read starts where risk concentrates.
Build an evidence trail
The question, the policy it was answered from and the manager who took it stay on the record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Fleet and hours systems
- Samsara
- Motive
- Omnitracs
- Platform Science
Dispatch and TMS
- McLeod
- Trimble
- MercuryGate
- Revenova
Driver channels
- In-cab app
- messaging
- Driver portal
- phone
Agent
Driver-support assistance
- Reads the policy
- Answers the driver
- Stops and escalates
People and settlement
- HR systems
- payroll
- Safety and compliance
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
Every layer wraps the next. What none of them catches is in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a reply may stand
- L3
- Puts the next word in a manager's hands
- L4 – L5
- Hold the answer and the policy behind it
- L6
- Falls back to signposting when signals degrade
How Nestack evaluates it
Evaluate the whole exchange — not only the sentence that answered.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the reply the driver reads
- E1Final-output evaluationDid the reply match the policy section it cited?
- E2Step-level evaluationDid the copilot read the right policy, clock and load for this driver?
- E3Tool evaluationDid it read the correct driver and write the correct record?
- E4Confidence calibrationDo low-confidence replies actually attract more manager hand-offs?
- E5Slice evaluationHow does performance change across specific question types?
- E6Business outcomeHow many exchanges should have stopped, and how many of them did?
Floor — the driver who has to decide
Failure modes
Where each failure originates in the agent
Seven ways an exchange goes wrong, by stage.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- AI-03
Superseded policy read
The reply is drawn from a policy version no longer in force.
Stage gathers
Policies, duty status, load record and open defects
02 · Reasoning
2 modes
- AI-04
Clock read as permission
A legal clock is treated as a judgement about fitness.
- AI-06
Consequence in the reply
Pay, ranking or standing surfaces in an hours exchange.
Stage proposes
The reply, the policy cited and confidence
03 · Tool / write
2 modes
- AI-02
Reply sent without a person
A write answers the driver before a manager has taken it.
- AI-05
Refused request, put again
The same request comes back put a second way.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- AI-01
Answer without its policy
A reply is returned with no policy or section behind it.
Stage returns
The reply the driver reads and may act on
05 · Change / Version
1 mode
- AI-07
Silent gate regression
A model or rule change narrows what the stop gates catch.
Stage tracks
Model, prompt, stop gates and policy sources
- Sev-1 · a driver is pressed after refusing
- Sev-2 · a wrong answer reaches the driver
- Sev-3 · a policy source degrades, reply routes to review
Affected slices
Overall answer quality can hide one question type
The exchanges an average under-counts are the fatigue ones — rare enough to disappear fleet-wide, and the ones where being wrong is a 49 CFR 390.6 problem. Nestack reports the hand-off rate by question type, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Fatigue and fitness to drive | 6.3% | 3.7× | Review | |
| Hours and duty-status questions | 3.9% | 2.3× | Review | |
| Defect and DVIR questions | 2.5% | 1.5× | Watch | |
| Routine paperwork questions | 1.4% | 0.8× | Normal |
Bar: hand-off-rate lift vs. routine-paperwork baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
A person picks it up, then it closes
The loop shuts when the miss is a case in the suite, not when it has been explained. That suite is what the next driver question is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Hand-off rate rises in a question type.
- 02
Diagnose
The manager who took the exchange reads it back against the policy until one cause holds.
- 03
Improve
Whatever changes ships against a version, with the exchanges that prompted it attached.
- 04
Verify
Nothing ships until the affected cases pass a second time.
- 05
Learn
The suite grows by one case; so does the coercion guardrail set.
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, answering workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Driver-support workflow discovery and boundary definition.Week 1
- 02Fleet, ELD and channel source assessment.Week 1, Week 2
- 03Policy, stop-gate and coercion-guardrail rule mapping.Week 1, Week 2
- 04Question and duty-status ingestion.Week 2
- 05Answering logic and policy binding.Week 2, Week 3
- 06Confidence scoring and stop routing.Week 3
- 07Manager hand-off workflow.Week 3, Week 4
- 08Fleet and driver-channel integration.Week 5
- 09Coercion-language cases.Week 4, Week 5
- 10Guardrails and escalation controls.Week 4
- 11Exchange-trail instrumentation.Week 5, Week 6
- 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 tier | PilotOne terminal, one channel | ProductionProduction fleet systems | AdvancedMultiple terminals / channels |
|---|---|---|---|
| Introduced at Pilot | |||
| Answering from your own policies | ✓ | ✓ | ✓ |
| Manager hand-off | ✓ | ✓ | ✓ |
| Answer-quality baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by question type | — | ✓ | ✓ |
| Hand-off workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Fleet-system integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-terminal policy sets | — | — | ✓ |
| Multi-stage escalation paths | — | — | ✓ |
| High question volume | — | — | ✓ |
| Multi-terminal support controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom 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.
You bring
We build with it
01Your driver policies and escalation paths
→Question and duty-status ingestion and policy mapping
Week 102Representative past driver exchanges
→Answering baseline, policy binding and the stop gates
Week 203Your policy source and your stop rules
→Policy, stop-gate and coercion-guardrail rule mapping
Week 104Access to relevant APIs, feeds or exports
→Fleet, ELD and channel assessment, then integration setup
Week 205Answers you would not want a driver to act on
→Coercion cases and failure-mode testing
Week 406Where an answer must stop and wait for a person
→Confidence scoring, stop routing, guardrails and escalation controls
Week 307Named managers to take held exchanges
→Manager hand-off 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 follow real work rather than a plan, so evaluation and pilot genuinely share the fifth week.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Driver-support workflow discovery, policy mapping and the boundary
W2Fleet, ELD and channel integration and the answering baseline
W3Answering workflow, confidence logic and escalation controls
W4Evaluation suite, coercion cases and failure-mode testing
W5Channel integration, a pilot driver queue and targeted corrections
W6A live driver queue answered under supervision, then Agent Care handover
- Reading the band
- Bars are drawn over the weeks the work occupies. The fifth week doubles because evaluation and launch overlap.
- At the end of W6
- Once the queue validates, Agent Care owns the running agent.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Transportation AI agent
Build a driver-support copilot that stops where the rule says stop.
Show us your driver policies, your channels and who takes an escalation. Being wrong here is not a poor answer — it is a written record of a driver pressed after saying no, and 390.6(b) gives that driver somewhere to file it.
- Typical delivery
- 4–6 weeks
- Deployment
- Your fleet systems
- Person takes it
- Never presses
- After launch
- Agent Care available
Nestack Agents · Driver support
AGT-TR-03 · Agent Care available after launch