Every fleet-optimisation pitch that leads with "the LLM plans the routes" is wrong in a way that shows up the first week in production. Vehicle routing is a hard combinatorial optimization problem — the kind with decades of operations-research literature and purpose-built solvers behind it — and an LLM asked to reason its way to an efficient route across 40 stops will produce something plausible-looking and measurably worse than what a solver returns in milliseconds. The LLM's job in a fleet agent is orchestration and communication, not arithmetic over a distance matrix.
What the LLM should — and should not — do
Route optimization is an assignment and sequencing problem with hard constraints: vehicle capacity, time windows, driver hours, depot locations. This is exactly what solvers like Google OR-Tools, a dedicated routing API, or a commercial VRP engine are built for, and they will outperform an LLM on both solution quality and latency by a wide margin, every time. The agent's role is to gather the inputs — today's orders, vehicle availability, current driver locations — call the solver as a tool, and then turn the solver's output (a sequence of stops per vehicle) into something a human or a driver can act on: a summary, a dispatch message, an explanation of why a particular stop moved.
This division isn't a compromise — it's the correct architecture. Treat the solver as ground truth for anything involving distances, capacities, or time windows, and treat the LLM as the layer that explains, summarizes, and drafts communication around what the solver decided.
An LLM asked to plan a multi-stop route by reasoning in natural language will silently violate constraints — double-booking a time window, ignoring vehicle capacity — because it has no mechanism to backtrack and re-verify a combinatorial solution the way a solver does. Any accuracy it shows on small examples will not hold at fleet scale.
Real-time re-routing when things go wrong
A flat tire, a closed road, a customer that's a no-show — these require re-solving the routing problem for the remaining stops, not editing the plan by hand. The agent's value here is speed of detection and re-dispatch: watching for a disruption signal (a driver marks a stop failed, a telematics feed shows a vehicle stopped for 20 minutes off-route), re-calling the solver with the updated constraints (remaining stops, current vehicle positions, remaining driver hours), and pushing the new plan back out. The solver call itself is the same tool used for the original plan; what changes is the trigger and the reduced problem size, which also means re-solves can run fast enough to be genuinely real-time.
Integrating telematics and GPS data
Live vehicle position feeds — from a telematics provider or the driver's phone — are what make re-routing decisions accurate instead of guesswork. The integration pattern is a background job that ingests position updates on a short interval, updates a vehicle-state table, and exposes that state as a tool the agent (and the solver) can query. Keep this ingestion path independent from the agent's request/response cycle: telematics data should be flowing and current whether or not an agent call happens to be in flight, since disruption detection often needs to trigger a re-plan proactively rather than waiting for someone to ask.
{
"tool": "reoptimize_route",
"input": {
"vehicle_id": "VAN-07",
"remaining_stops": ["ORD-8841", "ORD-8842", "ORD-8850"],
"current_position": {"lat": -1.2921, "lng": 36.8219},
"reason": "stop_failed:ORD-8839"
},
"output": {
"status": "resolved",
"new_sequence": ["ORD-8842", "ORD-8841", "ORD-8850"],
"eta_delta_minutes": 12,
"constraint_violations": []
}
}Drafting driver and customer communication
This is where the LLM genuinely earns its place. Once the solver produces a revised plan, someone has to tell the driver their next stop changed and tell the affected customer their delivery window shifted — in plain language, adjusted for tone, sometimes in a different language for a regional fleet. Generating that message from structured solver output (old ETA, new ETA, reason for the change) is a good, low-risk use of an LLM: the facts come from the solver, the LLM just phrases them. Keep a human-readable audit log of what was sent so a dispatcher can see exactly what a customer was told if a complaint comes in later.
Human dispatcher override
No routing agent should be fully autonomous in a fleet with real drivers and real customers. Dispatchers know things the system doesn't — a driver who's having a bad day, a customer who always complains regardless, a road closure not yet in the traffic feed. Build the override as a first-class path: every automated re-route should be visible in a dispatcher console before or immediately after it goes out, with a one-click revert, and the agent should defer to a manual override rather than re-optimizing over top of it. Log overrides separately — they're a signal about where the solver's constraints or the agent's judgment are systematically wrong.
If reverting an automated re-route takes more clicks than the dispatcher's patience allows, they'll stop reviewing and just let bad routes ship. The override needs to be at least as fast as the automation was.
Wrapping up
A fleet optimisation agent that works is a thin conversational and orchestration layer wrapped around a real solver, a live telematics feed, and a human who can always override it. The moment the LLM starts trying to compute routes itself is the moment quality quietly degrades in ways that are hard to catch until a customer complains about a driver going in circles.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.