AI, Freight and the Art of Not Breaking Things

In every customer meeting, somebody asks the inevitable question: 'But will the AI actually work for us?' Usually in a hopeful but slightly apologetic way. It is a fair question, and it is aimed squarely at the kit, which in supply chain is almost never where the answer lives. The answer has embarrassingly little to do with which models or coding tools we use, a disappointment to anyone who's just sat through a fortnight of vendor demos.

The models are the box, and the box was the easy part. As Marc Levinson tells it, McLean’s first container sailing left Newark in 1956 with 58 35-foot containers on the converted T2 tanker Ideal X, bound for Houston. Steel, corners, doors: hardly an invention. The hard part was the twenty years that followed - agreeing standards, rebuilding ports, rewriting regulations, reshaping dock work, and convincing customs that a sealed box could travel on its paperwork. The box was never the problem.

Closer to home, the shiniest new thing hasn't solved anything if the berth schedule is held together with a laminated spreadsheet from 2019, the customs shed shuts at five, and Trevor, who knows where everything is, has just retired to Portugal.

The instructive detail is the corner fitting. Every box had to lock onto every crane, ship and chassis, so the industry needed a shared design. Sea-Land released its patent rights to the corner-fitting design, allowing a common standard to emerge: a proprietary standard was worth less than a universal one. It then took years to settle on twenty- and forty-foot containers, a compromise that suited almost nobody yet worked for everybody.

The longer answer is the engineering system behind our platform: what each part does when a container is at the border or a filing window is closing. The failures are included too; they taught us the most.

Freight doesn't care about your sprint

First, some context. Freight and customs move to the rhythm of vessel schedules, tariff deadlines and peak-season volume - none of which care whether your last deployment went smoothly or what your sprint cadence has to say.

This matters because the cost of a software mistake is wildly asymmetric here. A bad photo-sharing app update posts somebody’s brunch sideways; a misclassified HS code can quietly become a bottleneck in a broker’s queue, leading to a late filing, demurrage, and a container stranded over a long weekend because an exception vanished on Friday afternoon.

Every engineering decision that follows was made with that asymmetry in the room, glaring uncomfortably at me over the boardroom table. I’ll make the case through customs, where tariff schedules are moving faster than most systems were ever built to handle and mistakes are hardest to unpick. The same lanes, pipeline and checkpoints run beneath AP reconciliation and booking workflows.

Agents are brilliant, right up until they aren't

Coding agents work in long loops: plan, act, test, repeat. Given a clear brief and sensible boundaries, they are remarkably good (says someone who typed every semicolon by hand for years).

Left unsupervised, though, they develop a flair for expensive mistakes: endless loops, fixes that quietly break something else, and “improvements” that remove a compliance rule. In customs, that is not an inconvenience; it is a risk. Our answer is deliberately boring: scoped tasks, bounded permissions and human checkpoints. Agents can propose, build and test changes, but never ship to production. Prod is sacred.

For customers, this means better exception handling without an unexpected regression in compliance logic.

Two lanes: the sprinter and the marathon runner

That is how we organise the work internally. We run two kinds of work, and go to some lengths to keep them apart: the sprinter and the marathon runner. Both are running, but they pace, train and are measured differently.

The innovation lane is the sprinter. It is where new features, agents and workflows are tried first. It is high energy and low ceremony; prototypes capsize there regularly, on purpose. Better the test basin than the shipping channel.

The core lane is the marathon runner - regression tests, monitoring and validation against real customer configurations happen before anything touches live data. From the outside it has the glamour of a filing cabinet. In practice, it is where the hardest engineering lives: understanding what already exists, what a change might break, and how it behaves in the wild.

The separation matters because this industry trades in variation: carrier documents in different formats, half-complete manifests, country-specific requirements, customer configurations, and the exception that arrives at four o’clock before a bank holiday because of course it does. A workflow that works once in a demo has proved very little. The core lane exists to show that it works repeatedly under real volume and when it cannot, that it fails loudly. A system that shrugs is more dangerous than one that complains.

Two Paces. Two Definitions of Success.

Ideas move quickly in the test basin; survivors prove endurance in the core.

The pipeline matters more than the tools

An agent writing code ten times faster, feeding a release process that ships every three weeks, only creates a longer queue at the same locked gate. Worse, in this business a tariff schedule or customs ruling can be out of date before the fix reaches production, and neither HMRC nor CBP waits for your retro. Awkward arithmetic, which is presumably why it never makes the brochure.

So before we scaled the agents, we rebuilt the plumbing beneath them. We replaced the blunt dev-versus-live split and the single staging environment everyone fought over like the last sunlounger, with a series of progressively more production-like environments across every service we run. A release candidate soaks at each level before it earns the next.

There is a same-day promotion path for changes urgent enough to justify one, but the pipeline fails closed: a failed check stops the change outright. No “just this once”, no heroics at 11pm, and no promotion without human sign-off.

The Fail-Closed Release Airlock

Urgent work can move faster. It cannot move around the gates.

That pipeline has typically let us respond to a classification-rule change or new customs requirement in days rather than weeks, without skipping the controls that make a compliance-sensitive system worth trusting.

Testing whether a broker could stand behind it

Standard software tests ask whether something executed, which is nice, though nobody at a border has ever asked me that. A broker has to stand behind the result, so our definition of done includes checks a customs professional would recognise. Our platform structures shipment data, proposes classifications with its reasoning, and surfaces exceptions. The licensed broker of record reviews, decides and files. The platform does not decide and it does not file. We are not a customs broker and do not provide classification advice; we build the system the broker uses.

That is the same bargain that made containerisation possible: trust in a sealed box came from manifests, seals, bonded procedures and the right to inspect it, not faith. Every change has to show that we are holding up our end:

• Is shipment and manifest data complete and properly structured, not merely “mostly there”?

• Do classifications match what the customer's own rules and precedents would produce, and are the uncertain ones flagged rather than quietly filled in?

• Are exceptions surfaced rather than swallowed, never quietly closed or silently dropped? If we cannot resolve one, somebody is told.

• Do existing customer workflows and carrier integrations still behave as they did yesterday?

• Do integrations with TMS, customs systems and carrier APIs still honour their contracts, so the critical data actually gets from origin to destination?

• Is the compliance logic traceable enough to survive an audit?

  
  

It is the least glamorous kind of progress, but it means fewer regressions around filings and finances, more work ready for broker approval in one pass, and compliance logic checked on every change.

Could a Broker Stand Behind It?

"The code ran" is only one small part of trustworthy customs software.

My old friend Leeroy Jenkins returns

I have a fondness for the Leeroy Jenkins school of failure: charge first, plan never. I am pleased to report the agents have been studying it too.

In staging, one got stuck reworking a single 43-cell test form, correcting itself against context it had already poisoned. Each fix rested on the wreckage of the last, like a man recalibrating his compass against the magnet in his own pocket and growing steadily more furious with north. Before we intervened, it had racked up 406 runs across 30 planning passes. Nobody was harmed, although the invoice had developed opinions.

The fix was not engineering genius, but boundaries: explicit cost and step budgets, clean-context restarts, checkpoints, and rules for abandoning a bad attempt rather than doubling down like a gambler who is “due”. In most teams, that is a cost-control footnote. Near a filing deadline, it is how you stop an agent missing a window with a customer’s name attached.

When Retries Stop Being Learning

A poisoned context turns self-correction into a tightening feedback loop.

Show me the money (again)

I have written before about what it costs to train these models. Running them in production is its own line item, and we watch it like a museum guard watches an exhibit that has moved.

When we scaled new AI use cases, our spend rose sharply, much as it does for anyone trying this at scale and willing to admit it. It came back down through the dreary work: cutting unnecessary retries, capping runaway behaviour, see above; all 406 runs of it, and retiring automation that never needed to exist.

That discipline keeps the economics workable in a high-volume, thin-margin industry, instead of reappearing on a customer’s invoice as “platform enhancements.”

Now, for my own two penn'orth

Time to make my position clear, stripped of metaphor for a moment.

The models are becoming commodities, faster than most vendors would like to admit. Within a product cycle or two, everyone in this space will have access to broadly the same ones. “We use the good AI” is an advantage with a shelf life measured in months, and shrinking.

The system around the models is different. It cannot be ordered from a catalogue; it has to be grown, safeguard by safeguard, around the constraints of the industry it serves. None of it photographs well, but it compounds and, in freight and customs, it has to be built from the filing deadline up.

We are still at the 1956 end of this: everybody has a box; almost nobody has the standards, rebuilt ports and procedures that let a professional put their name to what comes out of it. That gap is the work.

So when you evaluate AI in this space, skip the model-comparison slide. Ask what happens when a check fails at 11pm, who can decide what ships, what broke last month and what changed because of it, and how much was built for this industry rather than borrowed from someone else’s playbook.

Anyone can weld a box. Ask who built everything around it.

Glossary

The usual accessibility service for the jargon; shout if I missed any.

HS code: Harmonised System code, the international classification that determines duties and whether your goods clear customs or have a little sit-down.

Demurrage: The fee charged when a container overstays its welcome at a port. Freight's equivalent of a parking fine, with a parking fine's sense of proportion.

Agent (AI): Software that works in loops towards a goal, planning and acting with a degree of autonomy. Brilliant servant, dreadful unsupervised tenant.

Staging: A production-like environment where changes are tested before going live. The dress rehearsal, ideally with fewer surprises than the actual show.

Release candidate: A bundle of changes considered ready to ship, pending a soak period and final checks.

Fail-closed: A design where a failed check stops the change outright, with no option to wave it through under a warning nobody reads.

Straight-through processing: Work that completes end-to-end with no human intervention needed. The goal in suitable workflows, not customs entry.

Definition of done: The checklist a piece of work must pass to count as finished; ours includes the domain checks above on top of 'did the code run'.
Regression: When a change breaks something that previously worked. The reason the word 'soak' appears above at all.

CBP: US Customs and Border Protection, whose rulings shape what a compliant filing looks like on that side of the Atlantic.

HMRC: His Majesty's Revenue and Customs, the UK authority whose rules decide what a compliant filing looks like on this side of the Atlantic.