Skip to content

( By / WiseTech Global / Lead Product UI/UX Designer, CargoWise Landside / 2026 / 6 min read )

Autonomous AI TMS

Delivered a working proof of concept that a logistics operation can be run by a coordinated agent team under a single orchestrator, with each of six agents owning a real logistics domain end to end

The result and the decision behind it

( What it did )

Delivered a working proof of concept that a logistics operation can be run by a coordinated agent team under a single orchestrator, with each of six agents owning a real logistics domain end to end

( The decision behind it )

Autonomy as a dial, not a switch

Operators build trust incrementally. Letting them watch the AI recommend in hybrid and then let it execute in autonomous, without swapping systems, maps directly onto how automation is actually adopted.

Generated schematic standing in for imagery of Autonomous AI TMS. It depicts nothing.
Generated schematic, not a screenshot of Autonomous AI TMS.

Generated schematic, not a screenshot. Real imagery to follow.

( The account )

Context

Transportation management is a coordination problem under constant disruption. A dispatcher running a fleet's day has to absorb a stream of new orders, cluster and sequence them into efficient routes across mixed vehicles and drivers, approve and dispatch those routes, watch the operation live for SLA risk and breakdowns, and keep drivers and customers informed as circumstances change. Done manually it is reactive, labour intensive, and error prone, because one person cannot watch everything at once.

Autonomous AI TMS exists to explore a specific question in that space: can an agentic AI system take on those responsibilities reliably, and can autonomy be introduced gradually enough that operators actually trust it? It is a proof of concept that demonstrates how order intake, route planning, dispatch approval, live monitoring, and customer communication can be run by a coordinated team of AI agents rather than a room of human dispatchers, observed unfolding in real time against a live fleet simulation.

The project was a self directed build, not a design and handoff exercise. With no template for what an agentic operations console should look like or how its trust boundary should work, I had to design the product concept, the agent architecture, and the full implementation together.

The problem

The core problem is that logistics dispatch is a bottleneck. A human coordinator has to hold too many concurrently changing variables in view: delivery windows, weights, priorities, and handling requirements for every order; the location, capacity, and performance history of every driver and vehicle; live SLA breach risk, breakdowns, and stuck unassigned orders; and the communication that keeps everyone informed. Any of these slipping produces missed windows and broken routes.

Automating it is not simply a matter of pointing a model at the data. Operators will not hand a fleet to a black box. The real problem was trust: how to let an AI system take on real operational authority while keeping every decision explainable, bounded, and adjustable, and while letting a supervisor raise or lower how much the system may do on its own without swapping tools.

What I did

The system is built as a master orchestrator, NOVA (Neural Orchestration and Vehicular Automation), coordinating six specialist agents, each owning one domain of the operation. NOVA observes the full simulation state on every cycle, dispatches the relevant sub agents, and, depending on the active mode, either surfaces recommendations for a human or executes decisions directly.

The defining idea is that autonomy is a dial, not a switch. A single operating mode control moves the level of autonomy from fully manual, through a human in the loop hybrid, to hands off autonomous operation. The same agents run in every mode; the mode simply gates which of their rules are permitted to act versus merely advise. The boundary of what the AI may do is externalised into a JSON backed rules engine rather than hard coded, so operators can toggle rules, edit them, and add their own, making the trust boundary explicit and adjustable. Every autonomous action produces an auditable decision record citing the specific rule that fired, so the intelligence is legible rather than opaque.

Outcomes

  • Demonstrated a graduated autonomy model (Manual, Hybrid, Autonomous) that maps directly onto how operators actually adopt automation, using one mode control over a shared set of agents
  • Made AI decision making observable in real time as it responds to live, injected disruptions such as SLA risk, driver breakdowns, and closing delivery windows
  • Produced explainable, auditable decisions with rule level reasoning attached to every autonomous action, rather than opaque black box assignments
  • Kept the trust boundary transparent and in human hands through an operator editable rules engine, with graceful offline degradation so the full behaviour is demonstrable with or without a live model connection

What I learned

Autonomy is more trustworthy as a gradient than a capability. The hardest part of the project was never whether the AI could plan a route; it was whether an operator would let it. Designing autonomy as a dial over a shared set of agents, so the same intelligence advises or acts depending only on granted authority, did more for trust than any improvement in raw planning quality would have.

Explainability has to be structural, not decorative. Because every autonomous action was made to emit a decision record citing the rule that fired, the audit trail became a first class part of the product rather than a log to reconstruct later. Building that in from the start was what made autonomous authority legible instead of unsettling.

Treating the trust boundary as data pays off. Externalising agent behaviour into an editable rules engine, rather than hard coding it, turned "what is the AI allowed to do" into something an operator can see and change. That single decision made the system adjustable per deployment and kept the boundary where it belongs, with the people responsible for the fleet.

The full record / 4 decisions
My role
Lead Product UI/UX Designer, CargoWise Landside
Timeline
2026
Platform
Web (Next.js 15 / React 19), responsive operations console
Category
Agentic AI / Logistics Automation
Status
Proof of concept

Tools Claude Code, Anthropic SDK, Next.js 15, React 19, TypeScript, Tailwind CSS, Zustand, GitHub

Team Solo build (concept, design, full-stack); collaborated with operations and dispatch domain experts across FCL and LCL freight workflows

Decisions

Autonomy as a dial, not a switch

What
Kept the same agents active across all three modes and gated only their authority to act, so an operator moves from manual to hybrid to autonomous with one control.
Alternatives
Separate manual and automated systems, or a binary on/off automation toggle.
Why
Operators build trust incrementally. Letting them watch the AI recommend in hybrid and then let it execute in autonomous, without swapping systems, maps directly onto how automation is actually adopted.

A rules engine as the trust boundary

What
Externalised agent behaviour into a JSON backed rules engine of 31 rules, each flagged enabled, autonomous only, or protected, editable at runtime from the NOVA control page.
Alternatives
Hard coding agent behaviour directly into the agent logic.
Why
Because rules are data rather than code, the boundary of what the AI may do autonomously is transparent and adjustable per deployment without a rebuild, and operators keep the trust boundary in their own hands.

Confidence gated automation

What
Tied auto approval of runsheets to a numeric confidence threshold, automating high certainty decisions and routing anything below the threshold to human review.
Alternatives
Automating all decisions uniformly, or requiring human approval for every decision.
Why
Automating the easy, high certainty decisions while reserving human attention for the ambiguous ones is the highest leverage division of labour between the system and its operators.

Explainability by default

What
Made every autonomous action produce a decision record with an action, a reasoning string citing the specific rule that fired, and an outcome, surfaced in a first class decision log.
Alternatives
Treating the decision trail as a secondary logging concern added later.
Why
An auditable, human readable trail is what makes autonomous authority acceptable. Building it in from the start meant the audit trail was never an afterthought bolted onto a black box.

( Tags )

  • Logistics
  • AI Product Design
  • Full-Stack