Logistics may be the most optimized industry on earth.
A route solver decides which stops belong together and in what order. A load-building system decides how freight fits into a trailer. A warehouse management system decides where inventory sits and which path a picker walks. Telematics measures the vehicle. Scanners record the handoff. Rating engines calculate the charge.
Thirty years of engineering went into removing seconds, kilometres, empty space, and unnecessary touches from the movement of a box.
Those are constrained optimization problems. The rules may be complicated and the search space may be large, but the result has to satisfy explicit limits: vehicle capacity, delivery windows, labour, distance, compatibility, warehouse layout, and contractual service levels.
A language model dropped into that control path does not improve the mathematics.
It makes a precise system less predictable.
The practical AI opportunity in logistics is somewhere else. It sits between the optimized systems, where one company hands work to another and a person covers the gap.
The Core Is Already Computational
AI discussions often start by looking for the most important decision in an operation.
In logistics that points quickly to routing, inventory allocation, load planning, or warehouse execution. Those decisions are commercially important, but importance does not make them language problems.
If a deterministic solver can calculate a route against known constraints, it should remain deterministic. If an optimization engine can prove that a load fits, a language model should not be asked for an opinion. If a warehouse system can produce a repeatable pick sequence in milliseconds, replacing it with an agent adds cost and uncertainty without adding useful judgment.
This distinction matters because “AI” now covers several different technologies.
Machine learning has been used for years to forecast demand, estimate arrival times, detect anomalies, and improve planning inputs. Operations research handles routing and scheduling. Rules engines enforce tariffs, dimensions, and compliance checks. Language models are good at reading messy text, interpreting documents, assembling context, and drafting an explanation.
The right architecture uses each for the work it can do reliably.
Use the solver for the route.
Use the model for the email explaining why the route failed.
The Seam Is Where the Information Changes Shape
Inside one company, systems can eventually be integrated. Data definitions can be reconciled. APIs can be built. Events can be published. The work may be difficult, but one owner can decide to change both sides.
The boundary between companies behaves differently.
A shipper produces a commercial invoice in one format. A broker receives it through a mailbox. A carrier exposes status through a portal. A customer sends a spreadsheet with its own product identifiers. A warehouse captures damage in photographs and free text. Someone retypes values because the next organization will not change its system merely because the first organization purchased new software.
That is the seam.
It is not only a technical integration gap. It is a boundary between budgets, contracts, incentives, operating hours, data definitions, and authority.
An API would be cleaner. The counterparty may never provide one.
AI is useful here because it can translate between forms without pretending the organizations have become one system. It can read an attachment, identify the relevant fields, compare them with a shipment record, and prepare the next transaction. But the workflow still needs explicit validation and ownership because the model is operating where definitions are least consistent.
You can automate a document.
You cannot automate a counterparty.
Border Documents Show the Pattern
Consider a shipment crossing a border.
The movement may require a commercial invoice, packing list, product description, tariff classification, country of origin, value, weight, and other declarations. Different parties produce and consume those facts. The shipper, carrier, freight forwarder, customs broker, port, customs authority, warehouse, and customer may each hold a fragment.
Seatrade Maritime reported that when Maersk analysed one avocado shipment from Mombasa to Rotterdam, it found 30 parties, 100 people, and 200 information exchanges around the movement.
The container followed a physical route.
The information followed dozens of organizational ones.
This is where a language model can remove real work. It can extract the product description and quantities from the invoice, compare them with the packing list, identify missing values, retrieve the current reference data, and pre-fill a declaration for review. It can explain why two documents disagree instead of presenting an operator with two raw files.
But classification and submission still need control.
A tariff code affects duty and compliance. The system should not silently invent one because a description looks similar. It should retrieve an approved classification when one exists, present evidence when confidence is low, route a new product to the responsible specialist, and record who accepted the result.
The model reads the ambiguity.
The policy decides what happens next.
Start at the Exception Desk
The exception desk is often a better first AI project than the planning engine.
Picture the person handling a late trailer, a short delivery, a customs hold, a damaged pallet, or a missed appointment. The transport system is open on one screen. The carrier portal is open on another. The customer’s email is in a third window. A scanned proof of delivery may be attached to a message. A warehouse note may use a different reference number from the invoice.
Before the operator can make a decision, they have to reconstruct the event.
Which shipment is this?
What was planned?
What actually happened?
Which party has acknowledged the problem?
What evidence is missing?
Which commitment was made to the customer?
That reconstruction is reading work. It is search work. It is entity-matching work across systems that were not designed to agree.
An AI-assisted workflow can detect the anomaly, gather the relevant shipment events and documents, build a timeline, highlight contradictions, and propose the next action. The operator then validates, changes, or executes it.
The operator remains essential because the decision can carry commercial context that no operational system holds. A one-day delay may be acceptable for one customer and a serious relationship risk for another. A replacement shipment may be cheaper than a claim but wrong for a customer whose renewal is under discussion. The model may see the service-level agreement without understanding the relationship around it.
The useful automation is not “resolve every exception.”
It is “make the exception understandable before the operator touches it.”
Reconciliation Is Another Reading Problem
The same pattern appears after the movement.
A carrier invoice has to be compared with the contracted rate, shipment record, proof of delivery, fuel surcharge, accessorial charges, detention events, weight, zone, and any spot quote agreed during the exception.
The relevant evidence may live in different systems and formats. The invoice says one thing. The transport platform says another. The contract contains a table or clause that does not map neatly to a database field. The exception approval sits in an email thread.
Tompkins Ventures states that at least 5 to 10 percent of freight invoices are billed incorrectly each year. It lists duplicate invoices, overpayments, rate errors, detention charges, unauthorized accessorial charges, and spot quotes on lanes where contracted prices already exist.
The arithmetic is not the hard part.
The hard part is assembling enough evidence to know which arithmetic applies.
A language model can extract the charge, find the related shipment, retrieve the contractual clause, and prepare a discrepancy packet. A deterministic calculation should then recompute the expected amount. A policy rule can decide which discrepancies are auto-rejected, which are queued for review, and which are too small to pursue.
Again, the model belongs around the control path, not in place of it.
It reads and assembles.
The system calculates and enforces.
A Production Pattern for the Seam
The architecture for this work is less glamorous than an autonomous logistics agent.
That is a good sign.
A practical seam workflow has six stages.
1. Detect the event. A deterministic trigger identifies a late milestone, missing document, unmatched invoice, conflicting quantity, or new message connected to an open shipment.
2. Resolve the business object. The system establishes which shipment, order, customer, carrier, invoice, or claim is involved. If entity resolution is uncertain, the workflow stops for review rather than attaching evidence to the wrong object.
3. Assemble evidence. The model reads the relevant documents and messages, while system connectors retrieve authoritative structured facts. Every extracted fact retains its source.
4. Apply policy. Rules define access, approval thresholds, required evidence, and which actions the workflow may propose or execute. Read is not write. Suggest is not approve.
5. Validate or execute. A human reviews consequential or ambiguous cases. Low-risk repetitive actions can be automated only after their error modes and rollback paths are understood.
6. Write back and observe. The result returns to the transport, warehouse, finance, or customer system. The workflow records the evidence, decision, actor, timing, and outcome so the next exception does not begin from zero.
This is integration work.
The model is one component inside it.
Measure the Seam, Not the Demo
A good demonstration can summarize a customs document or explain a late shipment in seconds.
That does not prove the operation improved.
The useful measures are closer to the work:
- Time from anomaly detection to an operator-ready case
- Number of systems or documents manually opened per exception
- Percentage of extracted fields accepted without correction
- Percentage of cases attached to the correct shipment and customer
- Exception resolution time and reopen rate
- Amount recovered from valid freight-invoice discrepancies
- False holds, false claims, and unauthorized actions
- Manual rekeying removed from each handoff
- Cases that still require a counterparty to change behaviour
The last measure is important. A workflow may automate everything on one side and still wait for a PDF, phone call, portal update, or approval from another company.
That delay is not a model failure.
It is the operating boundary the project must be designed around.
The Counterparty Is Part of the Architecture
Enterprise architecture diagrams usually stop at the company boundary.
Logistics cannot.
The carrier, broker, supplier, warehouse, customer, insurer, and customs authority are part of the workflow even when they are not part of the system. Their portals, document formats, operating hours, and response habits constrain what automation can accomplish.
A realistic project plan should therefore count two things.
First, count the handoffs where a person retypes or reconstructs information that a machine already knew. Those are candidates for AI-assisted reading and evidence assembly.
Then count the handoffs where success depends on a counterparty that will not change its system. Those are the boundaries that determine the fallback, review queue, and achievable service level.
The first number describes the opportunity.
The second describes the project.
Logistics does not need another model trying to rediscover the route solver. It needs a governed reading layer across the parts of the operation that still communicate through attachments, portals, reference mismatches, and people who know which phone call will move the freight.
The box was optimized years ago.
The information around it is still waiting at the border.