Intermodal Dispatch Management in 2026: How to Orchestrate TL, LTL, and Drayage on One Platform

Intermodal dispatch is a handoff problem, not a routing problem

A shipment leaves a Chicago warehouse for a Houston retail DC. Drayage moves it to the rail terminal. Intermodal rail carries it south. A last-mile van dispatches it to the store. Three carriers, three dispatch systems, three status feeds that never speak to each other.

Now introduce a delay. The rail leg arrives 90 minutes late. The last-mile carrier is still scheduled against the original ETD. The consignee already received a delivery window that is now wrong. A dispatcher discovers the problem by phone, then manually re-sequences fourteen other stops around it.

Nothing broke inside a leg. Every carrier performed acceptably within its own scope. The failure happened in the space between legs, where no system holds authority. McKinsey estimates that inefficient logistics handovers account for 13 to 19 percent of logistics costs, amounting to as much as 95 billion dollars in annual losses in the US alone. Intermodal is where handovers are densest, which makes it where that cost concentrates.

This is why intermodal dispatch resists the tooling built for it. Freight TMS platforms optimize tendering and long-haul carrier assignment. Telematics platforms track owned assets. Last-mile dispatch tools sequence final delivery. Each is competent within its mode and blind at the transition. The dispatcher becomes the integration layer, absorbing every handoff manually.

Locus, the world’s first agentic Transportation Management System, treats this differently. Built by Mara Labs Inc. and acquired by Ingka Group, parent of IKEA, in 2025, Locus orchestrates execution across 1,000+ carriers, 30+ countries, and 1.5B+ deliveries, with 250+ real-world constraints modeled per computation.

Also Read: End-to-End Freight Automation in 2026: Why Full-Journey Orchestration Beats Point Automation

The three-system trap

Walk into most mid-to-large freight operations and the intermodal dispatch stack looks like this:

• A freight TMS handles load tendering and carrier assignment for the long-haul leg. It thinks in loads and lanes.
• An ELD or telematics platform handles driver location and hours of service for the owned fleet. It thinks in vehicles and compliance windows.
• A last-mile dispatch tool handles final delivery sequencing. It thinks in stops and time windows.

Each layer is competent. The problem is that none of them holds the shipment as a single object. The TMS closes its record when the long-haul leg tenders. The last-mile tool opens its record when the freight lands. In between sits an accountability gap where the shipment technically exists in no system’s active queue.

The operational cost surfaces first at terminals. ATRI found that drivers were detained at 39.3 percent of all stops in 2023, losing between 117 and 209 hours per year depending on sector, at a cost of 3.6 billion dollars in direct expenses and 11.5 billion dollars in lost productivity. Detention is the clearest measurable consequence of arrivals that are not sequenced against actual gate availability, and drayage legs into intermodal terminals are among the most exposed.

The cost then compounds downstream. Delivery windows get calculated before upstream variance is known. Dispatcher headcount scales linearly with volume because exception handling stays manual. Carrier performance data fragments across three exports, making scorecards retrospective rather than operational.

Also Read: The Definitive Guide to Choosing a Dispatch Platform for Intermodal Trucking

What unified intermodal dispatch orchestration actually requires

Five capabilities separate genuine orchestration from a TMS with integrations bolted on.

1. A multi-leg order model

The platform must represent one shipment as a set of connected legs, not as separate orders handed between systems. Most freight TMS platforms model an order as a single leg with an origin and destination, so a drayage move and a last-mile delivery become two unrelated records.

That modeling choice is what breaks intermodal. If leg one and leg three are separate objects, a delay on leg one cannot mathematically propagate to the ETA on leg three. No amount of dashboard integration fixes a data model that does not encode dependency. Connected legs make propagation automatic rather than manual.

2. Carrier-agnostic allocation across modes

The dispatch engine needs to allocate TL carriers, drayage providers, and last-mile fleets from the same allocation logic, not from separate modules with separate rules.

In practice, carrier-agnostic means comparing cost and time in transit across modes at the moment of dispatch, not only at the moment of booking. The waste that mode-siloed allocation produces is measurable: ATRI puts deadhead, or empty running, at approximately 16.7 percent of all truck miles. Legs planned in isolation cannot match a return move against an outbound one. When a rail leg slips, the relevant question is whether to hold the last-mile slot, re-allocate to a different carrier, or convert the leg entirely, and that requires one engine with visibility into all available capacity. Locus provides this through its ShipFlex multi-carrier orchestration layer across 160+ pre-integrated carriers within a 1,000+ carrier network.

3. Real-time exception propagation

When an upstream leg is delayed, the system should calculate downstream impact across all connected legs, re-allocate capacity where needed, and push revised ETAs to the consignee without a dispatcher initiating any of it.

This is where most intermodal stacks stop. Gartner found that while 95 percent of supply chains must react quickly to change, only 7 percent can execute decisions in real time. Closing that gap requires event-driven architecture rather than scheduled polling: carrier status arrives as webhook events, each event triggers recalculation across the leg graph, and the recalculation either resolves autonomously or escalates. Polling every fifteen minutes guarantees the average exception is discovered seven and a half minutes after it becomes actionable, which is exactly the window in which last-mile capacity gets committed elsewhere.

4. Terminal and facility constraint modeling

Intermodal terminals impose receiving windows, dock capacity limits, and appointment requirements. These must function as hard constraints during allocation, not as notes managed in a parallel spreadsheet.

The distinction matters because a plan that violates a terminal window is not a slightly worse plan. It is an invalid plan that produces dwell, detention, and a re-plan. Locus models 250+ real-world constraints natively in its routing engine, including facility windows and capacity ceilings.

5. Performance analytics by leg and mode

An intermodal carrier scorecard measured at shipment level hides the thing you need to know. A shipment that arrives late tells you nothing about which leg failed.

Useful analytics break performance out by leg type: terminal dwell time on drayage, on-time percentage by lane and mode for the middle mile, and first-attempt delivery rate on the last-mile leg. That granularity is what converts a scorecard from a quarterly procurement artifact into a weekly allocation input.

Also Read: How AI Dispatch and Allocation Works for Freight Carriers: A Practical Guide (2026)

Intermodal dispatch capability by platform type

Two honest readings of this table. Freight-first TMS platforms are stronger than Locus on rail and drayage carrier API breadth, which is a real gap. Visibility network platforms hold the widest carrier status coverage of any category, but they report exceptions rather than executing against them, which is the difference between knowing a leg is late and having the next leg already re-allocated.

Also Read: Best AI Dispatch and Allocation Platforms for Logistics Carriers in 2026

How Locus handles multi-leg execution

Locus runs on DiSCO, an agent architecture where eight named agents operate a continuous Sense, Decide, Execute, Learn cycle. Four are directly relevant to intermodal dispatch. The Capacity agent evaluates available capacity across carriers and modes. The Carrier agent handles allocation and performance-weighted selection. The Dispatch agent commits and re-commits execution plans. The Hub agent manages facility-level constraints, yard operations, and multi-leg handoffs. The Orchestrator coordinates across them, and the Customer agent owns downstream notification when a plan changes.

The behavior that matters operationally is what fires without a dispatcher. A confirmed upstream delay is a sense event. The system recalculates downstream leg feasibility, evaluates whether existing last-mile capacity still satisfies the revised window, and either re-allocates or escalates. Six governance mechanisms bound this: explainability, traceability, evaluation, autonomy levels, an execution sandbox, and human-in-the-loop controls.

Two deployments show the mechanism at multimodal scale. A leading North American retailer moved freight across ocean, rail, DC, hub, and store on six disconnected systems, with planning running leg by leg and no way to match backhaul. Consolidating onto one agentic decision layer produced 100 percent real-time visibility across truck, rail, and 3PL, an 80 percent-plus reduction in manual dispatch, and 1 million dollars-plus in savings with break-even inside the first year. Separately, a Fortune 50 parcel and logistics leader running multimodal freight forwarding across air, ocean, and ground moved weekly execution from 75 percent to 92 percent across 51 service-center locations, surfacing 14 million dollars-plus in previously unused annualized capacity.

Consolidating three systems into one

The integration surface is predictable. Load tender data flows from the TMS. Driver location and hours of service flow from telematics. Order release and inventory confirmation flow from WMS or ERP. Status events flow from carrier APIs. Notifications flow outward to consignees.

Direction matters more than volume. Carrier status, telematics, and order release are inbound. Notifications and revised appointment requests are outbound. Only carrier allocation decisions and status acknowledgment need to be genuinely bidirectional, which narrows the hard integration work considerably.

The upside justifies the sequencing work. Deloitte estimates that enterprises which orchestrate AI agents well could increase the value they capture by 15 to 30 percent, which is the clearest available figure for why orchestration beats point automation. Sequence realistically: integration and data mapping, historical migration for scorecard baselines, dispatcher training, then a parallel run on a subset of lanes before cutover.

The change management risk exceeds the technical risk. Dispatchers have built years of judgment around a three-screen workflow, and their compensating behaviors are invisible until removed. Run parallel long enough for dispatchers to see the system reach the same conclusions they would, on lanes they know well. Trust in autonomous re-allocation is earned on familiar lanes, not announced in a training deck.

Also Read: TMS-WMS-ERP Integration Architecture for US Enterprises in 2026

Is unified intermodal dispatch orchestration right for your operation?

1. Do you regularly manage shipments with more than one carrier leg per order?
2. Do middle-mile delays currently require manual dispatcher intervention to update last-mile schedules?
3. Are your carrier scorecards built from exported spreadsheets rather than live platform data?
4. Do you operate more than three carrier types, for example drayage plus LTL plus last-mile parcel?
5. Is your current TMS unable to trigger last-mile re-dispatch automatically when a prior leg slips?

Three or more yes answers means this is a consolidation decision rather than a feature addition, and should be evaluated as one: against the cost of three licenses, three integration surfaces, and the dispatcher headcount currently absorbing the gaps between them.