Opinion article authored by Dan Winson, Founder and CEO, Zetifi
Connected fleet technology has become very good for helping organisations ask straightforward questions: Where is the vehicle? Is the worker where we expect them to be? Are they speeding, braking harshly or idling excessively? Can they press a button if they need help?
Those are important questions, and today’s telematics, tracking and lone-worker systems answer them well. However, the harder questions start when the answer is not obvious.
Is the worker actually safe? Does a missed check-in require action, or did they simply lose coverage? Does a harsh-braking event need investigation, or is it the same speed bump that triggers an alert every morning? Does a fault need attention now, or can it wait until the next scheduled service? Who should respond, and when should an issue be escalated?
Most importantly, can the organisation show what happened, what decision was made and whether its safety process actually worked?
These questions require more than another alert. They require context.
From alerts to judgement
Fleet managers already handle large volumes of information. Speeding events, fault codes, geofence crossings, maintenance warnings, safety events and driver behaviour data can arrive continuously.
The problem is rarely a lack of data. It is deciding which events matter.
Traditional automation works well when the rules are fixed. A new driver can automatically receive training tasks. A missed service interval can create a maintenance reminder. An unacknowledged safety alert can escalate after a defined period.
Agentic AI becomes useful when the decision depends on several pieces of information at once.
Consider a missed worker check-in. On its own, that event says very little.
Was the worker expected to be in an isolated area? Has their vehicle moved recently? Did mobile coverage disappear at the same time? Have they acknowledged another message? Is this worker performing a task with a higher level of risk? What does the organisation’s escalation policy say should happen next?
An agent with access to that context can assess the event against defined policies and decide what should happen next, or prepare the information for a person to decide.
That is a different job from generating another notification.
Finding the signal in the noise
The same principle applies to fleet operations. Battery-health data may show signs of deterioration before a vehicle fails to start. Across one vehicle, somebody may notice and issue. However, across hundreds of vehicles, the pattern can be easy to miss.
With access to the right data, an agent could identify a developing problem, compare it with previous behaviour and raise a maintenance task before the vehicle fails in service.
Driver behaviour provides another example. A harsh-braking alert might indicate a genuine near miss. It might also be caused by a known road feature that triggers the same event repeatedly. Looking at one alert in isolation does not tell you much. Location, frequency, vehicle history and surrounding events provide the context needed to decide whether it deserves attention.
This is where the distinction between the easy and hard questions matters. The easy question is: did harsh braking occur? The hard question is: does anybody need to do something about it?
The data problem comes first
None of this works because an AI model suddenly becomes smart. The agent needs access to the right operational data, in a form it can use.
This doesn’t mean moving every trip record, GPS point and telematics measurement into one new database. Source systems should generally remain responsible for the detailed information they already manage well.
What matters is making the relevant events, current state and business context available to the tools making decisions. These may include fleet events, worker check-ins, maintenance status, rosters, escalation policies, asset information and previous operator actions.
For organisations already using Microsoft 365, SharePoint, Power Automate, Teams and Copilot Studio can provide one way to connect those operational events with workflows and agents. Other technology stacks can do the same job.
The important design decision is not the brand of AI model. It is deciding what information the agent can access, what actions it can take and where the authoritative records remain.
The hard part is not building a chatbot
Low-code tools are also changing who can build these workflows.
The person who best understands when a fleet event matters is often not a software developer. It might be the fleet controller, service manager, safety lead or operations manager.
Modern automation and agent tools can let those people describe rules, build workflows and test changes without writing a complete software application. This may be useful, but it also creates a new governance problem.
Giving more people the ability to build automation means identity, permissions, testing and audit become more important, not less.
An agent that can read information is one thing. An agent that can contact a worker, create a maintenance task or escalate a safety event is another. Organisations need to decide where deterministic rules are appropriate, where AI judgement adds value and where a human must remain involved.
For consequential decisions, human review should be designed into the workflow rather than added after something goes wrong.
Closing the gap
Agentic AI is unlikely to replace fleet management systems, telematics platforms or lone-worker technology. Indeed, it’s more useful role may sit between them. Those systems already collect the signals. Agents can help assemble the context around those signals and turn them into action. That changes the question fleet managers need to ask from not simply, ‘what data do we have’ to ‘which decisions are people still making manually because the information needed to make them sits across several systems?’
Those are the hard questions but where agentic AI starts to become genuinely useful.
