An agentic dispatch assistant that never sleeps for a logistics operator

The dispatch desk that never stops shifting

A road-freight operator lives and dies on the dispatch desk. Jobs come in, trucks go out, and the plan that looked clean at six in the morning is being rewritten by mid-morning. A customer moves a delivery window. A driver calls in sick. A load is late off the dock and the run behind it slips. None of these is unusual. Together they mean the dispatcher spends most of the day not deciding, but finding out.

Finding out is the slow part. The job sits in the transport management system, the driver’s hours are in another screen, the truck’s position is on a maps tab, and the customer’s latest message is in someone’s inbox. To answer a single question, such as which deliveries are now at risk because one truck is running two hours late, the dispatcher cross-checks three or four systems and makes a few phone calls. By the time the picture is clear, the situation has moved again.

The cost is real and it compounds. While the dispatcher is gathering context, at-risk jobs go unspotted, the replan happens later than it should, and the desk runs reactive all day. The work that actually needs a person, weighing one customer against another or judging whether a driver can safely take an extra run, gets squeezed into the gaps. For a small or mid-size operator without a large planning team, that pressure lands on one or two people.

Why an agentic GPT assistant, grounded in fleet data

The version that works is an agentic assistant on an OpenAI GPT model, sitting beside the dispatcher and grounded in the operator’s live fleet and job data. The dispatcher asks a question in plain language, such as what is at risk if this run slips by an hour, and the assistant retrieves the current state of the relevant jobs, vehicles and driver hours, reasons over them, and answers. When something changes, it surfaces the affected runs and drafts a revised plan for the dispatcher to accept, adjust or reject.

We headline a GPT model rather than a rigid rules engine on purpose. A traditional rules engine can only answer the questions someone coded into it, and dispatch reality does not stay inside those lines. The questions are open-ended, the phrasing varies, and the right answer depends on context the rules never anticipated. A GPT model handles the language and the reasoning, so the dispatcher can ask in their own words and get a useful answer rather than a menu of pre-built reports.

The supporting pieces make that safe and grounded. LangChain orchestrates the assistant, letting it call the right tool for a question, pull live records, run a check and assemble an answer in steps rather than in one guess. Retrieval-augmented generation (RAG) keeps it honest. Before it answers, the assistant retrieves the current state of jobs, runs, vehicles and driver hours from the operator’s systems, so every response is built from real records rather than what the model happened to learn in training. The GPT model reasons. The data decides what it reasons about.

The scope is deliberately bounded. The assistant recommends and drafts. It does not move a job, reassign a driver or commit a plan on its own. The dispatcher reviews and makes the call, which keeps a person accountable for every reallocation.

Building it, and where it got hard

The model was rarely the hard part. The danger lived in confidence, and one problem stands in for the rest.

An agentic assistant that sounds sure of itself is exactly what you do not want near a dispatch decision. Early in testing the assistant would, now and then, suggest a clean-looking reallocation that quietly breached a driver’s fatigue limit, or invent a plausible job detail that was not actually in the system. A language model can produce a confident, well-worded answer that is simply wrong, and on a dispatch desk that is dangerous. A suggestion that breaks a driver’s hours or a delivery window is worse than no suggestion at all, because it looks trustworthy.

The fix had four parts and none of them was a cleverer prompt. First, grounding. Every answer is built through RAG from live fleet and job data, so the assistant works from real jobs and real runs and cannot invent one. Second, hard rules stay outside the model. Driver fatigue limits under the Heavy Vehicle National Law and Chain of Responsibility obligations are enforced as deterministic checks the assistant cannot override, so a suggested reallocation that breaches a fatigue rule is blocked before it ever reaches the dispatcher. Third, the assistant flags uncertainty instead of guessing. When the data needed to answer is missing or stale, it says so and hands the question back. Fourth, the dispatcher stays the decision-maker on every reallocation.

Two other constraints shaped the build. The transport system enforced rate limits, so live lookups were cached and batched rather than called on every turn. And because the same data feeds compliance records, the assistant’s reads and the dispatcher’s decisions were logged, so there is a clear trail of what was suggested and what a person actually chose to do.

What changed

In a representative deployment the assistant took the context-gathering off the dispatcher. The time spent cross-checking systems before a typical replan fell from several minutes to under a minute, because the assistant pulled the affected jobs, runs and driver hours into one answer instead of leaving the dispatcher to chase them. When a job changed, a suggested reallocation surfaced roughly three times faster than the manual phone-and-spreadsheet loop it replaced. At-risk deliveries were flagged earlier in the day, rather than becoming obvious only once a truck was already late.

These figures are illustrative. They describe the pattern we see rather than a published result for a named operator. The shape is the point. The slow, repetitive work of finding out comes off the desk, the deciding stays with the dispatcher, and the operator runs the day a step ahead of the next change rather than a step behind it.

Where this fits

An agentic dispatch assistant is one application of our AI Agents service, built on an OpenAI GPT model, for the realities of Australian road freight. It is a contained, high-value starting point, because the data already exists in the operator’s systems and the value comes from putting it in front of the dispatcher fast, with the safety and compliance rules kept firmly in human hands. If your dispatch desk spends more time finding out than deciding, the place to start is to map the questions your dispatchers ask most and decide where a person must stay in the loop.