In Freight, the Problem Is Rarely the Algorithm
In Freight, the Problem Is Rarely the Algorithm
Sixteen years at the intersection of supply chain and software taught me one thing the hard way: in freight, the problem is rarely the algorithm. It's fragmented data, carrier integrations that break, rate sheets living in 40 spreadsheets, and customers who just want to know where their box is.
The model is the easy part
When I built Lane Intelligence at Winmore, production models scoring tradelane attractiveness on incoming tenders and predicting win probability after pricing, the modelling stack itself was not the hard bit. Random Forest and ensembles after a proper EDA, integrated with Xeneta APIs for ocean and air market rates. That work is well understood.
The hard bit was everything upstream. What counts as the same lane when three systems spell the port differently? Which rate is current when a contract has been amended twice and the spot quote is fresher than both? Whose volume commitment are we scoring against? Every one of those questions is a data and definition problem, not a modelling problem, and every one of them will quietly poison a model that looks fine in a notebook.
Rate sheets are the real boss fight
Automating rate-sheet ingestion compressed parsing from days to minutes. That sentence hides a lot of pain. Rate sheets arrive as spreadsheets, PDFs, emailed attachments, and occasionally screenshots. The same carrier sends a different format per region. Surcharges live in footnotes. Validity windows overlap.
You cannot fix that with a better prompt. You fix it by treating extraction as a product with an accuracy target, a review path when confidence is low, and a feedback loop that makes next month's parse better than this month's. The LLM is a component. The workflow around it is the product.
Master data is a product decision, not a backlog ticket
At Infor I owned Freight Pay & Audit, the financial-close layer supporting 3-way match across shipment, rate, and invoice, and 2-way rate-only workflows, integrated via EDI 310, EDI 210, and XML. Three-way match is, at heart, a question about whether three systems agree on what an identity is. When they don't, you get disputes, and disputes are where margin quietly leaves the building.
That's why I treat master data and platform architecture as a first-class part of the roadmap rather than plumbing someone else will get to. Every downstream AI workflow inherits whatever mess sits underneath it. If carrier, lane, and equipment identities aren't clean, no amount of model sophistication rescues the output.
What this changes about how I build
I now start AI work in freight by asking three questions before anyone mentions a model. What decision does this actually change? What data does that decision depend on, and who currently owns it? What happens when the data is missing or contradictory, because in this industry it regularly is?
If those answers are shaky, a better algorithm just produces a more confident wrong answer, faster. The tools have changed across my career, configurable workflows, then classical ML, then LLMs, now agents, but the problem set has stayed remarkably consistent. Fix the data and the definitions, and the clever part gets much less clever, and much more useful.
Lokesh skipped presentations and built real AI products.
Lokesh Radhakrishna was part of the June 2026 cohort at Curious PM, alongside 20 other talented participants.