Logistics Software and the Exception Problem: Why AI Belongs at the Edges, Not the Middle

Most warehouse and transport software is competent at the path where nothing goes wrong. An order arrives, stock is allocated, a pick list is generated, a label prints, a vehicle is assigned. That flow has been solved and re-solved for decades, and a new system that merely does it again is not worth the migration risk. The operational cost in logistics has moved almost entirely into the exceptions, and the exceptions are where software has historically given up and escalated to a person with a phone.

This matters for how AI should be introduced, because it inverts the usual instinct. The temptation is to put a model at the centre: forecasting demand, optimising routes, predicting delays. Those are real applications, but they are also the ones where a small error propagates through everything downstream. The higher-yield, lower-risk placement is at the edges: the messy, ambiguous, human-language work that surrounds the clean transactional core.

Keep movement deterministic

Inventory arithmetic should never be probabilistic. Stock allocation, bin assignment, quantity reconciliation and the state machine a shipment moves through are all problems with correct answers, and they should be implemented as code that produces the correct answer every time and fails loudly when it cannot. A model that is right ninety-nine percent of the time is unacceptable here, because the one percent becomes a stock discrepancy that surfaces weeks later during a count, by which time the cause is unrecoverable.

This is not conservatism about AI. It is the recognition that these subsystems already have exact solutions, and replacing an exact solution with an approximate one is a downgrade regardless of how impressive the approximation is.

Put intelligence where the ambiguity actually is

• Inbound documents. Packing lists, bills of lading, customs paperwork and supplier confirmations arrive as PDFs, scans and email bodies in inconsistent formats. Extracting structure from them is genuinely ambiguous work, and a wrong extraction is caught at the reconciliation step rather than silently corrupting stock.
• Exception triage. A short shipment, a damaged pallet, a mismatch between the manifest and what arrived: classifying what happened and proposing the remedy is judgement, and it currently consumes supervisor attention that scales linearly with volume.
• Communication. Chasing a supplier, notifying a customer that a window moved, drafting the claim for a damaged consignment. High volume, low stakes per message, and every draft is reviewed before it leaves.
• Search over operational history. "Has this supplier short-shipped this SKU before?" is a question the data can answer and no interface currently asks well.

Forecasting deserves more scepticism than it gets

Demand forecasting and route optimisation are the applications most often pitched and most often disappointing, for a structural reason: they are evaluated against a future that the forecast itself changes. If a forecast causes you to stock differently, the demand you observe is partly a consequence of the forecast, and the accuracy number you compute afterwards is measuring a counterfactual you cannot see.

That does not make forecasting useless. It makes the deployment question different. A forecast presented as a planning input, alongside its uncertainty and the assumptions it rests on, is useful to a planner. The same forecast wired directly into automatic replenishment is a system that will confidently over-order a seasonal line and discover it a quarter later. The distinction is whether a person is choosing to act on the prediction or the system is acting on their behalf.

Integration is the project, whatever the brief says

Logistics platforms do not exist alone. There is a carrier API that returns tracking in its own vocabulary, an ERP that owns the financial truth, a customer portal, scanners on the floor and at least one spreadsheet that someone will admit to only in week three. Most of the delivery risk in a logistics build lives in these seams, not in the features, and a plan that treats integration as a phase at the end has misjudged which part is hard.

In logistics, the system of record must be boring. Put the intelligence where a wrong answer meets a human before it meets the inventory.

For operations and supply-chain leaders

The most informative question to ask about a proposed logistics build is which subsystems are deterministic and which are model-driven, and why each one falls where it does. A partner who has run these systems in production will draw that line quickly and defend it. A proposal where AI is described as improving the whole platform has not drawn the line at all, which usually means it will be drawn later, under pressure, by whichever component fails first.