Skip to main content

Getting started with the AI Tracking Agent

What the AI Tracking Agent does, how to roll it out, and the exceptions it handles. Start here before configuring checkpoints.

Written by Tanuj Gupta

The AI Tracking Agent runs your routine check calls. It reaches out at the right points in a load's life, works out what is actually missing, asks only for that, and escalates when something needs a person.

This article covers what it does and how to roll it out. For how often an individual checkpoint fires, see How often a checkpoint runs.

Proactive checkpoints

A checkpoint is a point in the load's life where the agent wakes up and decides whether to reach out. There are seven:

  • Pre Pickup

  • At Pickup

  • Pickup Number Release

  • In Transit

  • Pre Delivery

  • At Delivery

  • Post Delivery

At each one the agent works out what is missing and asks only for what is needed: whether the driver is empty at the prior stop, an ETA, tracking enablement, unloaded confirmation, a POD, and so on.

Waking up is not the same as messaging. Each checkpoint has conditions that decide whether it acts at all, and they are checked at the moment it runs.

How often each checkpoint runs

By default a checkpoint runs once and finishes. You can change that per checkpoint: re-run it when its trigger fires again, send one chaser if the carrier does not answer, or repeat it daily for as long as its conditions match.

Repeating daily is what replaces building five or six near-identical checkpoints by hand to chase an in-transit load. Full detail in How often a checkpoint runs.

Reactive auto-responding (optional)

  • Reads inbound SMS and email, understands intent (late-night lumper, breakdown, late ETA vs appointment), replies appropriately, and raises exceptions.

  • Waits briefly, for example 1–2 minutes, so your team can reply first. Backs off if someone is actively chatting.

Uses live data

  • Consumes tracking breadcrumbs from the driver app, ELDs and link trackers, and computes time-and-distance ETAs and miles to the next stop.

  • Factors in appointment windows and stop timing.

Multi-channel messaging

  • Texts the driver, emails the dispatcher, and presents one consolidated chat thread for your team.

  • Identifies who is speaking, for example "sent as Melissa", and can run under a dedicated branded phone number with call forwarding.

TMS updates and alerts (configurable)

  • Sets stop arrivals and departures, creates and resolves on-hand alerts, and can move loads to In Transit. It does not move loads to Delivered by default.

  • Updates a tracking-reference style field with current status, for example "Stop 1 ETA 10/16 14:00 – Chain AI".

Customization

  • Configured at workspace and pod level, with customer- and carrier-specific conditions.

  • Add checkpoint-specific instructions, for example requiring a selfie in a safety vest, or warehouse directions.

  • Set how often each checkpoint runs.

  • Language-aware, for example Spanish.

How to enable and configure (recommended rollout)

1. Start with proactive only

  • Go to Automation → Agent and load the Sample Agent.

  • Set the timezone, checkpoint times, and any exclusions (customers, carriers or DOTs).

  • Keep auto-parse on, for stop updates and alerts.

  • Leave every checkpoint on its default Run once to start.

2. Add reactive auto-responding after 1–2 weeks

  • Turn on reactive responses and set a short wait window, for example 1–2 minutes.

  • Add customer-specific instructions at checkpoints as needed.

3. Keep static rules for specialty SOPs

  • Retain narrowly defined rules, for example a warehouse app or safety-vest selfies.

  • Retire redundant reminder pings that the agent now replaces.

4. Scope and segmentation

  • Configure at workspace or pod level, and use team members to route notifications.

  • Use exclusions for regular carriers or projects that do not need check calls.

Best practices

  • Make team members explicit on loads so notifications reach the right people. The default is email only when offline.

  • Avoid running two tracking providers in parallel long-term. It depresses compliance and confuses drivers. If you must, tone down the cadence temporarily.

  • Use the agent for core check calls, and static rules to enforce narrow customer SOPs.

  • Let conditions end a repeating checkpoint rather than relying on its run limit.

  • Add multilingual scenarios, for example Spanish, where your corridors need it.

Common exceptions the agent handles

  • Tracking stalled, with a configurable stall threshold.

  • Late vs appointment. Compares ETA and arrival against the appointment, and can alert and ask what happened.

  • Delivered but not closed. Can prompt your team to close it, or handle it per your TMS rules.

  • After-hours lumper. Reassures, collects the receipt, escalates.

  • Permission issues, fake GPS and VoIP numbers. Diagnoses, instructs fixes, avoids bad data.

  • Breakdown or inclement weather. Acknowledges, collects a plan and an updated ETA.

FAQs

Does this replace my team?
No. It handles routine work, escalates exceptions, and yields when you engage.

Can we customize per customer?
Yes, through conditions and checkpoint instructions.

Can we limit it to certain loads?
Yes, by workspace or pod, customer, carrier or DOT, and more.

Will it spam drivers?
No. It is conversation-aware, throttled, and waits for humans. Even a checkpoint set to repeat daily sends at most one outreach per day, and stops as soon as its conditions stop matching.

What is the driver onboarding?
A simple SMS link. The app is optional, and driver-code autofill is supported.

Is it multilingual?
Yes, for example Spanish.

Which TMS updates are supported?
Stop arrivals and departures, on-hand alerts, and status notes or fields. It can move a load to In Transit, but not to Delivered by default. Customer-specific behaviours are configurable.

Did this answer your question?