The Foundation Problem: Why AI Pilots in Global Trade Keep Failing 

Once an order is placed, roughly forty documents will be created by nine different companies, in four countries and two languages, and not one of them will be 100% accurate. The gap between what was agreed and put into writing, and what actually happens, is where operations teams lose money for the whole company. 

Almost every supply chain leader I speak with is hoping AI can close that gap. Many are also having a similar, frustrating experience: a demo that impresses their executive team, followed by a pilot that never reaches production. 

AI can do the work. But first, it has to understand your company. That is the part most pilots skip, and it shows up in four predictable ways:

1. Treating the data problem as a quality problem 
2. Building the agent before the company intelligence exists 
3. Ignoring team context and idiosyncrasies 
4. Preemptively restructuring or reducing the team 

Treating the data problem as a quality problem 

The common assumption is that data is a hygiene issue. Clean it, standardize it, and intelligence follows. 

It will not. A single product moving from a factory in Asia to a shelf in Texas passes through twelve or more independent companies, each with its own systems, formats and definitions. That fragmentation is structural. You are not going to normalize it at the source, because you do not control the source. 

The consequence is that root causes hide across boundaries. One distributor was absorbing roughly $30,000 a day in penalties and assumed it was a logistics problem. Meanwhile a supplier was shipping early, and containers were arriving before the warehouse could receive them. The cost surfaced three functions away from where it originated, and only by connecting procurement data to logistics data was it exposed. 

Your systems know what happened. Your people know how the company actually works. Cleaning the first does nothing to capture the second. 

Building the agent before the company intelligence exists 

Would you build a house without a foundation? Then why spend tens of thousands, perhaps millions, deploying agents across your organization before anything in the stack understands how your company operates? 

The foundation is not cleaner plumbing. It is the understanding that sits above your systems: what is happening now, what your company knows, how it handles the work, what people decide and why, and what has been learned from what happened before. Systems of record hold transactions. None of them hold that. 

It is tempting to skip this, because agents are the easiest layer to build and the easiest layer to point to as success. But agents are the least differentiated piece of any AI transformation. The models are becoming commodities. Your company’s intelligence is not. The difference is not the agent. It is what the agent knows when it acts. 

Ignoring team context and idiosyncrasies 

Let’s say you have done the hard work of structuring your data. That is genuinely ahead of most of your peers. But you have been running your business on hyperspecific processes, digitally recorded and not, for years if not decades before this pilot began. 

Encoding those idiosyncrasies is not a nice-to-have. There are five things a system has to hold before an agent can act on your behalf: 

• Context. What is happening right now. Which purchase order is still open, which invoice belongs to which shipment. 
• Knowledge. What the company knows but has never written down. That a certain supplier always ships 2% short. That a certain carrier still bills a surcharge that was negotiated out of this year’s contract. 
• Know-how. How your company actually handles the work. The sequence, the tolerances, the workarounds that exist because the system does not support the real process. 
• Decisions. What people chose and why. Not just that an exception was approved, but the reasoning that made it approvable. 
• Memory. What happened before and what was learned from it. Last quarter’s near-miss is only useful if the system still has it. 

Most pilots capture the first two and stop. The last three are where the specificity lives, and specificity is the whole job. 

Preemptively restructuring or reducing the team 

When you reduce the team that holds institutional memory, you do not simply lose capacity. You lose the corrections that would have made the technology reliable. Strip out human context too quickly and you are not running a leaner operation. You are running a more fragile one that has lost its institutional knowledge.

The right sequence is unglamorous. An operator overrides a decision, the reason is captured, and the system does not make that mistake again. Observe, reason, act, correct, learn. Capability transfers first. Capacity comes out afterward. 

What a working sequence looks like 

The pilots that survive do not start bigger. They start narrower and compound. 

Prove one workflow. Make the value measurable. Every approval, edit, override and outcome in that workflow adds to what the system understands about how your company operates, and the next workflow starts from that understanding instead of from zero. The first use case solves a problem. The second one is cheaper, faster and more accurate because the first one happened. 

That is the difference between running ten pilots and building something. Ten pilots each start at zero. A compounding system does not. 

Three questions before your next pilot 

1. Does the system get better at our specific operation over time, or does it start from zero on every task? 
2. When someone corrects the system, where does that correction go, and who benefits from it next month? 
3. Are we measuring model accuracy, or are we measuring decision latency and work genuinely removed from the team? 

None of this is the interesting part of AI. Context capture, correction loops and institutional knowledge do not make for a compelling demonstration. But they are the difference between a pilot that impresses a steering committee and a system an operations team actually runs on. After thirty years of supply chain technology that promised more than it delivered, that distinction is the only one worth measuring.

Valentina Jordan is CEO and Co-founder of Nauta.