Fleet telematics has solved visibility. You can see where the truck is. What the industry has not solved is the question that comes immediately after: who acts on what the truck just told you, and when?
A connected vehicle running GPS, a CAN bus tap, TPMS sensors, a fuel-level probe, an electronic cargo lock and a dashcam emits somewhere between two thousand and twenty-five thousand signals a minute, depending on how deep you tap. Conventional platforms turn all of it into the same artefact: a red dot on a dashboard, and a notification for a human who is already dispatching, already on the phone with a customer, already driving.
That isn’t an intelligence problem. It’s a delegation problem — and it has exactly three answers.
Three modes, one platform: unattended work, a decision held open for a human, and a question answered in plain language.
• Autopilot — the agent runs continuously, triggers on events, and takes action without asking.
• Human-in-the-loop — the agent does the work, then stops and waits for a yes.
- Ask — a human asks a question; the agent finds the answer across every system.

The interesting design work isn’t building the three modes. It’s deciding which signal belongs in which — and having the plumbing to move a workflow from the third to the second to the first as trust accrues.
First, what the devices actually give you

Before mapping modes, it helps to be honest about the shape and quality of each feed. They are wildly different, and that difference drives everything.
Each device feeds a domain, and each domain has a natural starting mode. Those defaults move as evidence accumulates.
Two rules fall straight out of this. First, high-frequency, low-value signals must be processed at the edge — raw CAN at 100 Hz has no business on a cellular link. Second, and more importantly, the value is almost never in one feed.
“Fuel dropped 40 litres” is noise. “Fuel dropped 40 litres while GPS shows stationary, ignition off, at 2:14 AM, six kilometres off-route, with the cargo lock reporting an open event and no matching card transaction” is an incident with a case file already attached.
That correlation is what makes autonomy safe. It is also what separates an agent from a rules engine wearing an AI badge.
Mode one: autopilot
The agent runs continuously in the background. Triggers on events, processes data, takes action.
Autopilot earns its place where the decision is high-frequency, low-ambiguity, and cheap to be wrong about. If the cost of a false positive is that someone gets a message they ignore, automate it. If it’s that a truck comes off a revenue run, not yet.
Tyre health

Pressure is temperature-dependent, so a naive threshold fires every cold morning and stays quiet through a genuine slow puncture until it’s nearly flat. A useful agent normalises for ambient temperature and load, then watches the slope of loss across days.
Same two weeks, same axle. Threshold logic fires twice on cold mornings and misses the real leak until day twelve.
When it finds a real leak trending toward failure, it opens a work order tagged to the next scheduled depot stop and reserves the tyre from inventory. No human touched it. Under-inflation is the leading preventable cause of blowouts and one of the cheapest failures in trucking to catch — and most fleets still discover it at the roadside.
Predictive maintenance
Diagnostic trouble codes are noisy, and most fleets ignore amber codes entirely. A useful agent scores DTC clusters against duty-cycle history. A turbo underboost code on a vehicle that also shows rising exhaust gas temperature and declining fuel economy over three thousand kilometres is a different animal from the same code appearing once on a healthy engine. Autopilot books the service slot; it doesn’t diagnose.
Fuel anomaly detection

This is where multi-feed correlation earns its keep. A tank-level drop on its own is meaningless. The same drop lined up against position, ignition state and cargo-lock events is a case that assembles itself.
Four feeds, one night. The agent builds the case — then hands the accusation to a person.
Legitimate refuels get auto-reconciled against fuel card transactions and closed. Only genuine mismatches escalate — which means the fraud team looks at four events a week instead of four hundred. Note where the arrow points at the end: the agent detects, but it does not accuse.
Dashcam triage

The edge model classifies the clip. Everything below the severity bar — a hard brake with no following-distance violation, a false-positive lane departure on a faded road marking — is auto-closed with a stored reason.
One week, forty vehicles. Two automated stages remove the noise before a safety manager sees anything.
This is the single highest-ROI autopilot workflow in most fleets, because the alternative is a safety manager watching video for six hours a week. It’s also the one drivers appreciate most — nobody wants to be coached on a clip where another vehicle cut in.
Compliance and admin
Hours-of-service calculation, mileage by jurisdiction from GPS breadcrumbs, inspection reminders, cold-chain temperature logs, geofence-triggered ETA updates to the customer. Nobody should ever do these by hand.
Autopilot without a replayable decision log isn’t automation. It’s an unaccountable robot.
Every automated decision needs to be written down with its inputs, its reasoning and its timestamp. When a customer disputes a delivery or an insurer questions an incident, that trail is the whole game.
Mode two: human-in-the-loop
The agent prepares the work, then pauses for review or approval before proceeding.
This is where most of the actual money is, and it’s the mode fleet software historically does worst. There are two failure modes: making a human do the preparation the agent could have done, and making a human approve everything, which trains them to click yes without reading.
Done properly, the agent does ninety-five percent of the work and presents a decision, not a task.

Four seconds of agent work on the left. The thing a human actually has to look at on the right.
The same shape recurs across the operation:
• Driver coaching packets. The agent pulls the week’s dashcam events, correlates them with CAN data — was the harsh brake preceded by someone cutting in? What was the following distance? — ranks them by coachability, and drafts the conversation guide. The safety manager reviews, removes the one that clearly wasn’t the driver’s fault, and approves. A two-hour job becomes a four-minute review, and the coaching is fair, which is the only reason drivers accept it.
• Maintenance above a threshold. Autopilot books the tyre. The engine rebuild gets prepared — vendor quotes pulled, downtime modelled against the route plan, warranty status checked against the OEM contract — and then it stops.
• Cargo security exceptions. A cargo lock reports a door-open event at an unscheduled location. The agent assembles the case: position, the dashcam clip either side, the assigned manifest, whether this location has appeared before. It proposes an action and waits. This must be human-in-the-loop, because accusing a driver of theft on a false positive is a genuinely expensive mistake.
• Route and dispatch changes. A vehicle running forty minutes late will miss a delivery window. The agent computes the reallocation — which vehicle absorbs the drop, what it costs, which customer gets a revised ETA — and waits. Dispatchers will not tolerate an AI silently reshuffling their day, and they’re right not to.
• Anything that grounds a vehicle. Any recommendation that removes an asset from revenue service. Always.
Architecturally, the pause is the interesting part. AWS Step Functions has a `waitForTaskToken` pattern built for exactly this: the workflow suspends, a task token is issued, the approval UI — or a Slack or Teams action button — calls back with the token, and the state machine resumes down the accept or reject branch. Store the token and the full proposed action with a TTL, so a decision nobody makes expires safely rather than firing three days late.
And log the rejections. Rejection data is the training signal that tells you which workflows are ready to be promoted to autopilot. A workflow that has run four hundred times with a ninety-nine percent approval rate is a candidate. One running at seventy percent is telling you the humans are still doing real work.
Mode three: ask
A human asks a question in plain language; the agent pulls the answer across every system.

Ask is the mode people demo and the mode people underestimate. Its real function isn’t convenience — it’s closing the gap between a question and an answer for people who will never open a telematics dashboard.
The operations director doesn’t want a report on fuel efficiency. She wants to ask, at eight on a Sunday evening, which depots are getting worse quarter over quarter and whether it’s driver behaviour or vehicle condition — and get a real answer with the workings shown.
Two depots, two different root causes, four systems queried — and an honest note about the sensors that were offline.
Other questions a fleet agent should handle without ceremony:
• Why was this vehicle late three times this week? — route replay, traffic overlay, CAN idle time, loading-dock dwell time at each stop.
• Which vehicles have a tyre likely to fail before the next service interval? — trend model against the service calendar.
• What’s the total cost of ownership delta between our 2022 and 2024 tractors? — fuel, maintenance and downtime joined across four systems.
• Which drivers improved most after coaching? — event rates before and after, normalised for route difficulty.
• Is this fault code covered under warranty on this VIN? — diagnostic code plus vehicle plus contract terms.
Two things separate a useful fleet agent from a demo. It cites. Every number comes back with its source, its time window and the vehicle set it was computed over. Fleet managers are quantitative people who have been burned by wrong dashboards; an uncited number is worse than no number. And it admits gaps. “Sensor offline since Tuesday, this figure covers thirty-four of forty vehicles” is the answer that builds trust. Silently averaging over missing data is how you lose a customer.
The AWS shape of this

You need one ingestion spine that all three modes hang off. The specific services matter less than the separation of concerns, but concretely:
Decode at the edge, correlate in the stream, reason in the cloud, act in the systems of record — with an audit trail under all of it.
At the edge, AWS IoT Greengrass on the telematics gateway handles CAN decoding, TPMS debouncing, fuel-signal smoothing and dashcam inference. Ship events and features, not raw frames. For serious signal-level work, AWS IoT FleetWise is purpose-built for CAN and OBD decoding with condition-based collection — you define a campaign like “collect brake pressure at 50 Hz, but only when harsh braking is detected.”
For ingest, AWS IoT Core with MQTT topics per device class, and IoT Rules fanning out by criticality. Device Shadow holds last-known state so an Ask query never waits for a truck to wake up.
For stream and store, Kinesis Data Streams on the hot path into Lambda or Managed Service for Apache Flink for windowed aggregation; Amazon Timestream for time-series telemetry; DynamoDB for current state and asset metadata; S3 for the raw parquet lake and dashcam clips, with Glue and Athena over the top.
For intelligence, SageMaker for the numeric models — remaining useful life, fuel anomaly scoring, harsh-event classification — and Amazon Bedrock for the reasoning and language layer, with Knowledge Bases over your maintenance manuals, SOPs, fault-code dictionaries and contracts. Step Functions orchestrates anything multi-step, including the approval pauses.
For action, Lambda writes back to the maintenance system, EventBridge fans out to dispatch and billing, and Amazon Location Service does the geospatial work.
One spine, three postures toward the human.
The part that actually matters
Here’s the thing the three-column framing doesn’t say out loud. These aren’t three features you choose between. They’re one workflow at three stages of maturity, and the platform’s job is to make the promotion path easy.

Ask, then human-in-the-loop, then autopilot. Approval rate is the graduation metric.
Every high-value automation follows the same route. Someone asks the question manually enough times that it becomes a pattern. You wrap it as a prepared action that a human approves. You measure the approval rate. When it’s boringly high, you promote it — with a kill switch and a sampled audit.
Which means there are four questions to ask of any new workflow:
1. What does being wrong cost? Auto-closing a false dashcam alert costs nothing. Grounding a vehicle costs thousands. That number sets the starting mode.
2. Is the decision reversible? Reversible, and autopilot is defensible. Irreversible, and it stays human indefinitely.
3. Does it touch a person’s record? Anything affecting a driver’s employment, pay or safety score is human-in-the-loop as a matter of policy, not capability.
4. Can I replay the decision? If you can’t reconstruct exactly which sensor readings produced an action six months later, you can’t run it on autopilot — not because the model is bad, but because you’ll lose the dispute.
Where to start
If you’re building this, don’t start with the agent. Start with the two unglamorous things everything else depends on.
Normalise the signals. A harsh-braking event must mean the same thing across a Volvo, a Tata and a Ford. If your CAN decoding is vendor-specific and your thresholds are per-device, no model you train will generalise and no answer will be trustworthy.
Fix the entity graph. Vehicle to device to driver to route to customer to contract. Most fleet data platforms have this scattered across four systems with inconsistent identifiers, and every “why was this vehicle late” question dies on the join. An agent is only as good as its ability to traverse that graph.
Then pick one workflow per mode and ship it. Autopilot: dashcam false-positive suppression, for immediate measurable hours saved. Human-in-the-loop: maintenance approvals over a cost threshold, for visible money. Ask: a natural-language layer over vehicle history that your operations team can actually use.
Three modes, one data spine, one trust ladder. The fleets that win aren’t the ones with the most sensors — they’re the ones who figured out which decisions to stop making themselves.
Figures are illustrative, built to show the shape of each pattern rather than results from a specific deployment.
This article was originally published on Medium by Ponvannan P.
