AI Dispatch in Practice: A 2026 Field Guide for European Shippers Running Captive, 3PL, and Gig Capacity

What AI dispatch actually means

The term covers three different things, and the distinction matters before any workflow makes sense.

Rule-based dispatch with AI branding applies fixed logic and asks a dispatcher to confirm. ML-assisted dispatch proposes an allocation and waits for approval on each one. AI-native or agentic dispatch decides and executes within defined policy, escalating by exception rather than by default.

Only the third changes the shape of the working day, because the first two keep the dispatcher as the gate on every decision, which means throughput stays tied to how many decisions a person can process.

Scepticism is warranted, and Gartner has named the reason: agent washing, the rebranding of assistants, robotic process automation, and chatbots as agentic without substantial agentic capability. In the same research Gartner predicts more than 40 percent of agentic AI projects will be cancelled by the end of 2027, attributing it to cost, unclear value, and inadequate risk controls rather than to capability.

The rest of this guide is written as workflows for that reason. What a system does at 07:00 is harder to overstate than what it is called.

Also Read: Agentic-Washing: How to Tell a Real Agentic TMS From a Rebranded Rules Engine in 2026

Workflow 1: building the morning plan

Before. A planner opens the order file, checks which vehicles and drivers are available, applies known constraints from memory and a spreadsheet of local rules, sequences routes, and distributes the plan. On a large operation this runs for hours, and the plan reflects conditions as they were when it started rather than when it finishes.

After. The plan is generated against the current order set and current resource availability, with constraints held in the model rather than in the planner’s head. The planner reviews exceptions the system flagged as infeasible or marginal, adjusts policy where the output looks wrong, and releases.

What changed. The planner stopped producing the plan and started governing it. That is a harder job in some ways, because it requires making explicit the judgements previously applied intuitively, and it scales in a way that manual planning does not.

The evidence. A global FMCG leader operating across ten countries with 1,000+ distributors and 5,000+ riders had scheduling cycles running long enough that picking stalled at the warehouse waiting on plans. Autonomous planning collapsed a three-hour manual cycle into a five-minute run, clearing the bottleneck and eliminating 12,000+ trips a month through demand-matched capacity and fuller loads.

The productivity ceiling this removes is documented. McKinsey has found that with advanced system support, 80 to 90 percent of planning tasks can be automated while still delivering better quality than the same tasks performed manually.

Workflow 2: allocating across captive, 3PL, and gig capacity

Before. Volume is assigned to the captive fleet first, because it is already paid for. What does not fit goes to contracted carriers. What they reject goes to gig or spot capacity. Each step is a separate decision made by a different person or system, frequently at a different time of day.

After. All three pools are evaluated in one allocation, priced on cost, capacity, serviceability, and SLA risk per order, at the moment of dispatch.

What changed. The overflow architecture is the problem the single decision solves. Filling captive capacity first and passing the remainder onward guarantees you use the most expensive marginal capacity on the highest-volume days, which is exactly backwards. It also means the cheapest available option for a specific order is never considered if the captive fleet had room, regardless of whether that fleet was the right fit for the drop.

The evidence. A Fortune 50 parcel and logistics provider governs 4,500+ drivers, 1,500+ captive and 3,000+ third-party, under one policy, with zone-based, tendering, dynamic, and on-demand assignment logic all running inside one decision engine rather than as separate processes. Weekly execution moved from 75 percent to 92 percent across 51 locations, and a single-site analysis surfaced 565,000 dollars in unused capacity, including premium-tier service given away on cheaper classes, scaling to 14 million dollars-plus annualised across 25 sites.

That last detail is the one worth noting for a European operation running a similar mix. The leak was commercial and invisible until allocation was instrumented.

Also Read: The End of the “Captive Fleet Only” Era: Orchestrating Hybrid Last-Mile Capacity in 2026

Workflow 3: the 11:30 disruption

Before. A driver reports a breakdown. The dispatcher checks which stops remain, finds the nearest vehicle with capacity, calls that driver, reassigns verbally, updates the system afterwards, and tells customer service who is affected. During the twenty minutes this takes, three other things happen that nobody is looking at.

After. The breakdown is an event. The system recalculates the affected stops against remaining capacity across all pools, reassigns what can be reassigned, identifies what cannot be served today, and issues revised commitments downstream. The dispatcher is notified of the resolution and of the exceptions that need a decision.

What changed. Reassignment moved from sequential to simultaneous. A dispatcher fixes one problem at a time and cannot see the second-order effects; an engine re-solves the affected network at once. This is the workflow where the difference is largest, and it is also the one demos skip.

The gap this closes. Gartner found that while 95 percent of supply chains must react quickly to change, only 7 percent can execute decisions in real time.

Workflow 4: the carrier rejection

Before. A tender is rejected. The load returns to a queue. Someone re-tenders down a list, possibly a printed one, possibly by phone. If nobody accepts, it goes to spot at whatever the market is charging that morning.

After. Rejection is a trigger. The system re-tenders against a ranked list reflecting cost, historical acceptance, and serviceability on that lane, evaluates spot against the alternative of re-planning the load into tomorrow, and escalates only if no option clears the threshold.

What changed. The decision became a computation rather than a phone call. It also became consistent, which matters for scorecarding, since a carrier’s acceptance rate only means something if tendering follows the same logic every time.

What Europe adds

The workflows above apply anywhere. Three constraints make the European version harder, and a platform holding one configuration will handle them badly.

Driver hours varying by jurisdiction. Regulation (EC) 561/2006 governs EU driving and rest, national implementations of working time provisions differ, and GB operators run retained rules that diverge in detail. A route crossing regimes is subject to different limits along its length, so the rule set has to be applied per leg rather than per operation. Applying the strictest set everywhere costs capacity; applying the loosest produces plans that are invalid.

Urban access schemes. Low emission and zero emission zones across European cities, London’s Ultra Low Emission Zone and Direct Vision Standard among them, determine which vehicle can serve which city and when. That makes vehicle eligibility a hard allocation constraint rather than a compliance check, because assigning a non-compliant vehicle produces a plan that is uneconomic or unexecutable rather than a charge to reconcile.

Cross-border legs. Customs and clearance events sit outside the carrier’s status stream, so a shipment can go quiet at precisely the point where delay originates. That interval needs to exist as a modelled state with its own expected duration rather than as a gap.

There is also a governance dimension. Algorithmic allocation of work engages worker-management provisions under the EU AI Act and automated-decision provisions under GDPR, which makes explainability and traceability product requirements rather than policy documents.

Also Read: Driver Hours and Route Efficiency in Europe: How Compliance-Aware Optimisation Reconciles Both in 2026

The sense, decide, execute, learn loop in practice

Each workflow above is one turn of the same loop, and it is worth naming the stages because the fourth is the one most implementations omit.

Sense. Orders, resource availability, driver hours remaining, vehicle eligibility, carrier status, traffic, and exception events, arriving as events rather than on a polling schedule.

Decide. Allocation and sequencing against the full constraint set, including the jurisdictional rules above, with feasibility rather than preference determining what is possible.

Execute. The plan committed and re-committed, with communication to drivers, carriers, and recipients generated from the decision rather than from a status field updated afterwards.

Learn. Observed outcomes, particularly actual service times per location and carrier acceptance behaviour by lane, feeding back into the model so next week’s plans use measured values rather than assumed ones.

The learn stage is what separates a system that performs identically in month twelve from one that improves. It is also the stage that requires deliberate design, because outcome labels arrive hours after the decision and attributing them back is not automatic.

Also Read: Which Dispatch Decisions Should Your AI Make? A Decision-by-Decision Autonomy Map for 2026

Setting autonomy sensibly

Nobody should switch this on wholesale, and the mechanism that prevents it is autonomy configured per decision category rather than as one system-wide level.

A workable starting posture: resequencing within a route and re-tendering against a ranked carrier list run automatically, because both are reversible and frequent. Reassignment across drivers runs automatically within defined cost and hours bounds. Anything with contractual consequence, penalty determination, spot purchases above a threshold, service downgrades, runs recommend-only until the operation has evidence.

Then widen on evidence rather than on schedule. The signal to watch is the override rate by decision category: falling overrides mean the constraint model is catching up with reality, flat overrides mean either the model is missing something or the team has not accepted the change.

Governance maturity is the sector’s weak point, which is why this matters. Deloitte found that only 21 percent of organisations report having a mature governance model in place for agentic AI, based on a survey of 3,235 IT and business leaders across 24 countries.

Where Locus fits

Locus, the world’s first Decision-Intelligent, Agentic TMS, implements these workflows through DiSCO, eight named agents running a continuous Sense, Decide, Execute, Learn cycle. The Dispatch agent plans and re-sequences against 250+ real-world constraints per computation, the Capacity agent forecasts demand and right-sizes resources, the Carrier agent allocates across contracted and gig capacity in the same decision as owned fleet, and the Customer agent manages downstream commitments when a plan changes.

Six governance mechanisms bound autonomous action: explainability, traceability, evaluation, autonomy levels, an execution sandbox, and human-in-the-loop override. For European operations the first two carry particular weight, given the AI Act and GDPR considerations noted above.

Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently, with 1.5B+ deliveries optimised across 360+ enterprise customers in 30+ countries.

Also Read: Logistics Orchestration Autonomy Is a Portfolio, Not a Single Level in 2026

What to ask in a demo

Five requests, all of which produce more information than a feature discussion.

1. Show the 11:30 disruption. Bring a real breakdown scenario from a recent day and watch what the system does without anyone touching it.
2. Show a plan the system refused to produce, and name the constraint that made it infeasible.
3. Show captive, contracted, and gig capacity being evaluated in one allocation rather than in sequence.
4. Show the decision record for a specific automated assignment, six months old if the demo environment has history.
5. Show driver hours rule sets differing per leg within one planning run.

Request two is the most diagnostic of constraint modelling. Request five is the one that separates platforms built for Europe from platforms configured for it.

Request a Locus demo here.