Nobody hands their fleet to a black box

Every pitch for AI in logistics has the same slide: the one where the dispatchers vanish and the trucks route themselves. It is a lovely slide. Nobody who has ever run a fleet believes it.

I used to design software that told trucks where to go. This year I designed software that decides for itself where to send them. The distance between those two sentences is not a better model. It is two years of learning how dispatch actually works, by hand, one legacy screen at a time.

The unglamorous half

For the last two years I have led the design of an intermodal transport management system, the tool drayage and trucking companies use to move shipping containers between ports, rail terminals, container yards and warehouses. Dispatchers, operations managers and drivers rely on it as their command centre, in a domain where every extra step has a cost.

It began life as a legacy desktop application. The screens were cluttered and the layouts rigid. There was no way to change more than one order at a time. Coordination with drivers happened outside the product entirely, over phone calls, texts and third-party apps. And despite sitting on rich operational data, driver locations, container statuses, delivery schedules, hours of service, the system offered no help with planning at all.

We did not rewrite it in one heroic push. I set the direction for the web platform first, got it approved, and then took the product across module by module against business requirements. Every module started the same way: study the legacy workflow, find where it actually hurt, then redesign. Order management became a table with row-level actions, a quick-add modal and a full multi-leg creation flow. A mass update feature let dispatchers change many orders field by field with a live preview, which the old system simply could not do. A communication centre pulled messaging, notifications and email into the product, next to the orders and drivers they were about.

Each module was checked twice before it was built: in validation sessions with dispatchers and operations users, and in review with drayage domain experts who knew the operational rules it had to honour.

The first AI feature was a sentence, not an agent

The first place AI entered the product was modest on purpose. Dispatch planning became a natural language interface. A dispatcher describes what they want to plan in plain language, the system extracts the parameters, and a proposed plan appears on a visual grid.

The rejected alternatives were a conventional form-and-filter planner, or leaving planning as the manual, screen-by-screen chore it had always been. A prompt met dispatchers in the language they already use to describe their own work. But the real design work was everything after the prompt. The plan had to be legible, and a dispatcher had to be able to review it, approve it, reassign legs and resolve conflicts one leg at a time.

That became the brief for everything that followed. In an operational tool, automation earns trust by being legible and reversible, not by being hands-off.

Then I built the thing the slide promises

This year I took the same domain much further, as a self-directed proof of concept. An orchestrator coordinates six specialist AI agents, each owning one part of the operation end to end: order intake and priority, route planning, dispatch control, live SLA monitoring, fleet and driver management, and driver and client communication.

There was no template for what an agentic operations console should look like, so I designed the product, the agent architecture and the implementation together, and built it with Claude Code on Next.js and React. Dispatch domain experts kept the agent behaviour honest about how real freight actually moves.

The hard problem was never whether the AI could plan a route. It could. The problem was whether a dispatcher would let it.

Autonomy is a dial, not a switch

The obvious designs were a binary automation toggle, or separate manual and automated systems. Both ask an operator to hand over all of their trust at once, or none of it.

So I built a dial. Autonomy is a dial, not a switch. Manual, hybrid and autonomous modes all run the same agents; the mode only decides whether an agent's rules may act or merely advise. A supervisor can watch the system recommend in hybrid, get comfortable, and then let it execute, without changing tools. That maps onto how people actually adopt automation: gradually, and with the right to take it back.

Three more decisions carried the same idea.

The boundary of what the AI may do lives in a rules engine of 31 rules, each flagged enabled, autonomous only, or protected, and editable at runtime instead of hard-coded. The trust boundary stays with the people responsible for the fleet.

Auto-approval of runsheets is tied to a confidence threshold. The system takes the high-certainty decisions and routes the ambiguous ones to a human, which is the most useful division of labour between software and the people supervising it.

And every autonomous action writes a decision record citing the specific rule that fired. The audit trail is a first-class part of the product, not a log someone reconstructs after something has already gone wrong.

The honest limit

It is a proof of concept. It runs against a simulated fleet of eight vehicles and matched drivers across Greater Sydney, with a scenario injector throwing in urgent orders and mid-day breakdowns so you can watch the agents react. When there is no live model connection it falls back to rule-based planning and monitoring, which makes it a very reliable demo and tells you nothing about a live operation.

It proves the model. It does not prove the rollout, and I am not going to pretend otherwise.

What it did do is change the conversation. Team leadership credited it with meaningfully advancing how the team thinks about transport in an AI future.

Why the boring work came first

The two halves of this story are one piece of work. I could not have drawn the trust boundary for an agentic dispatcher without first spending two years learning, module by module, where human dispatchers lose time and where they flatly refuse to let go.

Modernising legacy software is not a detour on the way to AI. It is the groundwork. You cannot design trustworthy autonomy into a workflow you have not first understood by hand.