Transportation AI agent · Carrier vetting

Carrier-Onboarding & Fraud-Vetting AI Agent

Pull the authority, insurance and registration facts, run the out-of-band callback a spoofed email thread cannot survive, and assemble an evidence pack — a named person at the brokerage selects the carrier.

Typical delivery
4–6 weeks
Deployment
Your stack
Broker approval
Pre-selection
After launch
Agent Care

What this agent does

Assembles the evidence, not the decision to load

In

  1. 01

    Ingest the carrier identifiers, the tender and your qualification standard from supported onboarding or TMS sources.

  2. 02

    Normalise names, addresses and identifiers, and carry each fact forward with the source it came from.

Reason

  1. 03

    Pull operating authority and insurance filings from the FMCSA record at tender, not only at onboarding.

  2. 04

    Apply the written carrier-qualification standard the brokerage configured, and log every input used.

  3. 05

    Run the configured out-of-band callback on a number taken from the FMCSA record, never from the email thread.

Decide

  1. 06

    Mark each item as verified or as a signal, naming the source and the channel that produced it.

  2. 07

    Stop on a mismatch between the callback, the filing and the tender, and name what disagreed.

Out

  1. 08

    Route the pack to the named person who approves the carrier, and retain it against the carrier file.

  2. 09

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

Product statement

The agent gathers evidence; a named person selects the carrier, and the brokerage stays the broker of record.

Example workflow

One carrier, tender to approval

  1. 1Carrier put forwardOnboarding packet, load-board profile, tender or carrier email
  2. 2Facts pulledAuthority status, insurance filings, registration details and address, each with its source
  3. 3Checks runCallback outcome, mismatches and confidence
  4. 4Controls appliedQualification-standard checks, verified-versus-signal marking, mismatch stops and confidence threshold

No human action required

Stages 1 to 4 run unaided and select nobody — selection is an unpreempted state-law act after Montgomery, so automating it concentrates the exposure.

5DecisionBranches at the confidence threshold
High confidence

Goes to the named approver to decide.

Low confidence

Adds a compliance read first.

Broker approval

The pack is held with its checks, its mismatches and the confidence.

Approve · Reject · Send to compliance

Approved — carrier eligible

  1. 6Onboarding systems updatedOnly where write access and approval policy allow it
  2. 7Outcome evaluatedMismatch outcomes, callback results, overrides and what surfaced after the load moved

Overrides

Every override at approval is counted in the evaluation.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Approving a carrier onto the brokerage's list.
    • Selecting the carrier a particular load goes to.
    • Clearing a mismatch that the checks have raised.
    • Treating a reconstructed score as a safety rating.
  • Automation boundary

    Agent acts unaided

    • ✓Pull authority, insurance and registration facts at tender.
    • ✓Run the configured out-of-band callback and record the number.
    • ✓Mark each item as verified or as a signal, with its source.
    • ✓Stop on a mismatch and hold the pack for the named approver.

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

    • Deciding what your qualification standard requires.
    • Accepting an insurance certificate the carrier supplied.
    • Judging whether an unrated carrier is acceptable.
  • Changes to the vetting rules or approval thresholds.

Example output

One carrier file, annotated

Everything the agent reports is attached to the check that produced it.

Vetting output · single carrier

Illustrative example
Carrier
Small dry-van carrier
Checked item
Callback answered on the FMCSA-listed number
Value found
18:02 UTC
Source
FMCSA record, not the email
Confidence
91%
Verified or signal
Verified — channel the carrier did not supply

As received

Taken from the FMCSA record and the call the agent placed — nothing here came from the carrier's email.

Checks behind it

  • Authority active at tender
  • Insurer-confirmed cover
  • Address on the record

Why this is a verification

The number came from the registry, not the thread the carrier controls.

What the score decides

Below the configured threshold the pack picks up a compliance read before.

Action

ApproveRejectSend to compliance

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 carrier

From the tender or onboarding packet

03Evidence gathering

Check against the standard

Draw on the FMCSA record and your written standard. Property-carrier percentiles are not public, and none is a rating.

01Approved path

Gather it, a person selects

Routine authority and insurance checks arrive already pulled and timestamped.

02Human review

Send review to what is not verified

Unverified items, mismatch stops and any reconstructed score are marked, so the approver's read starts where risk concentrates.

04

Build an evidence trail

The evidence pack, the checks that produced it and the person who approved the carrier 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.

  • Registration and safety data

    • FMCSA registry
    • SAFER
    • Licensing and insurance filings
  • Load boards

    • DAT
    • Truckstop
    • Parade
    • Trucker Tools
  • Onboarding platforms

    • RMIS
    • MyCarrierPackets
    • Highway
    • Carrier Assure

Agent

Carrier onboarding & fraud vetting

  • Reads the record
  • Runs the checks
  • Holds for approval
  • TMS and workflow

    • McLeod
    • MercuryGate
    • Revenova
    • Turvo
  • 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 carrier file

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 modePull the agent back to authority lookup when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt, standard-rule and channel-configuration changes.Track
L4TraceabilityRecord the checks, the channel each one used, the mismatches and the approval time.Record
L3Broker approvalHold the pack for the named approver; it governs release, not whether the pack is complete.Gate
L2Policy guardrailsTest the pack against the written qualification standard; a failing or unverified item returns the pack.Restrict
L1Confidence thresholdsRoute low-confidence packs to a compliance read before the approver sees them.Require review
Model corePack assembled — checks, channels, mismatches and confidence
L1 – L2
Test whether a pack may stand
L3
Puts the selection in a person's hands
L4 – L5
Keep the pack and the checks behind it
L6
Falls back to authority lookup when signals degrade

How Nestack evaluates it

Evaluate the whole vetting workflow — not only the finished pack.

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

Surface — the pack the approver reads

  1. E1Final-output evaluationDid each item in the pack match the source it names?
  2. E2Step-level evaluationDid the agent use the right record, standard and callback channel?
  3. E3Tool evaluationDid it read the correct carrier and write the correct file?
  4. E4Confidence calibrationDo low-confidence packs actually attract more approver overrides?
  5. E5Slice evaluationHow does performance change across specific carrier segments?
  6. E6Business outcomeHow many carriers needed rework, or turned out wrong after the load moved?

Floor — the selection the brokerage answers for

Failure modes

Where each failure originates in the agent

Seven failure modes, placed at the stage each one originates.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • AX-03

      Stale registry read

      Authority or insurance status read from a cached record.

    Stage gathers

    Authority, insurance, address and the written standard

  2. 02 · Reasoning

    2 modes

    • AX-04

      Signal read as verification

      A correlated indicator is reported as an established fact.

    • AX-06

      Reconstruction read as a rating

      A third-party percentile is reported as an FMCSA score.

    Stage proposes

    The pack, the channels it used and the confidence

  3. 03 · Tool / write

    2 modes

    • AX-02

      Callback to a supplied number

      The check runs on a number the counterparty provided.

    • AX-05

      Onboarding check not repeated

      Authority is verified once and never re-checked at tender.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • AX-01

      Captured identity passes clean

      A fraudster on a real carrier's clean authority passes every database check.

    Stage returns

    The pack the approver reads and the selection made

  5. 05 · Change / Version

    1 mode

    • AX-07

      Silent standard regression

      A model or rule change widens what the agent treats as verified.

    Stage tracks

    Model, prompt, standard rules and channel config

  • Sev-1 · approval outside the boundary
  • Sev-2 · a signal reaches the pack as a fact
  • Sev-3 · source degrades, pack routes to review
See the complete Transportation failure-mode catalogue

Affected slices

One segment can carry most of the misses

Do not read the aggregate. Break the mismatch rate down by carrier segment before deciding the programme is working — a few segments carry most of what the checks catch.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
New authorities under a year8.8%3.6×Review
Recent contact-detail changes5.1%2.1×Review
Unrated small fleets4.2%1.7×Watch
Long-standing contracted carriers1.7%0.7×Normal

Bar: mismatch-rate lift vs. contracted-carrier 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 the regression suite

The loop closes on a case the next release must pass, not on an explanation. That suite is what the next carrier put forward is measured against.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Mismatch rate rises in a carrier segment.

  2. 02

    Diagnose

    Which check moved — the pull, the callback or the standard? Packs are read until one answer holds.

  3. 03

    Improve

    The fix is versioned with the packs 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 vetting rules change.

  6. Learn → Detect

    The return edge. The next detection runs against a longer suite than this one.

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, vetting workflow, evaluation, integration, then production validation and handover.

Workstream

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

  1. 01Vetting workflow discovery and boundary definition.Week 1
  2. 02Registry and load-board source assessment.Week 1, Week 2
  3. 03Carrier-qualification standard and callback-rule mapping.Week 1, Week 2
  4. 04Carrier-record ingestion and normalisation.Week 2
  5. 05Check logic and evidence binding.Week 2, Week 3
  6. 06Confidence scoring and mismatch routing.Week 3
  7. 07Broker approval workflow.Week 3, Week 4
  8. 08Onboarding- and TMS-system integration.Week 5
  9. 09Identity-verification cases.Week 4, Week 5
  10. 10Guardrails and approval controls.Week 4
  11. 11Pack-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 office, one carrier listProductionProduction onboarding systemsAdvancedMultiple entities / brands
Introduced at Pilot
Checks against your standard✓✓✓
Broker approval✓✓✓
Evidence-quality baseline✓✓✓
Introduced at Production
Reporting by carrier segment—✓✓
Approval workflow in your systems—✓✓
Approved write-back—✓✓
Onboarding-system integration—✓✓
Introduced at Advanced
Multi-entity vetting standards——✓
Multi-stage compliance approvals——✓
High onboarding volume——✓
Multi-entity vetting 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 carrier intake paths and file structure

    Carrier-record ingestion and fact mapping

    Week 1
  2. 02Representative onboarded carriers

    Check baseline, source binding and callback configuration

    Week 2
  3. 03Your written carrier-qualification standard

    Qualification-standard and callback-rule mapping

    Week 1
  4. 04Access to relevant APIs, feeds or exports

    Registry, load-board and onboarding assessment, then integration setup

    Week 2
  5. 05Carriers you would not want loaded

    Identity cases and the evaluation suite

    Week 4
  6. 06What a pack may never certify

    Confidence scoring, mismatch routing, guardrails and approval controls

    Week 3
  7. 07Named approvers to decide held carriers

    Broker approval 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

W1Vetting workflow discovery, standard mapping and the automation boundary

W2Registry and onboarding-source integration and the check baseline

W3Vetting workflow, confidence logic and approval controls

W4Evaluation suite, identity cases and failure-mode testing

W5Onboarding and TMS integration, pilot carriers and targeted corrections

W6One onboarding cycle worked under compliance, 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 assumes monitoring.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Transportation AI agent

Build a carrier-vetting agent around your onboarding chain.

Show us your qualification standard and your onboarding sources. A named person signs every approval, and after Montgomery that signature is the act state law reaches.

Typical delivery
4–6 weeks
Deployment
Your onboarding stack
Broker approval
Pre-selection
After launch
Agent Care available

Nestack Agents · Carrier onboarding & fraud vetting

AGT-TR-10 · Agent Care available after launch

Build a carrier-vetting agent

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

About you
Your carriers

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