The Part Was on a Shelf the Whole Time

A few weeks ago I was in a discussion with an automotive OEM, and one part of it stayed with me.

They described a scenario anyone in manufacturing will recognize. A plant runs short of a critical part. Production is at risk. Meanwhile, another facility somewhere in the world has that same part sitting on a shelf, already bought and paid for. The catch is that identifying where it is can take days.

Not because the data is missing. Every unit of inventory is tracked. It lives across regional ERPs, warehouse management systems, supplier portals, and homegrown inventory apps that evolved independently over decades, built by different teams for different regions, with different data models and definitions.

The operational knowledge is there. It’s just fragmented across systems that were never designed to talk to each other, because for most of their lives they didn’t need to.

I spent years inside exactly this kind of environment, so the situation itself was familiar. What got my attention was the plan to fix it.

The default answer: build the lake first

Their roadmap was the one I see in most enterprise AI strategy decks right now. Consolidate everything into a centralized data lake, get the pipelines and governance in place, and then introduce AI agents on top of the unified foundation.

I want to be careful here, because this architecture is not wrong. For historical analytics, demand forecasting, and enterprise reporting, a data lake is the right answer. If you need to understand three years of inventory patterns across 40 facilities, you need that consolidated view. Nothing that follows changes that.

For operational AI, though, the lake-first approach involves two trade-offs that don’t always make it onto the slide:

Time to first value. You typically can’t deliver the first agentic workflow until the foundation is in place, which is often a multi-year program. The business problem, the stalled line and the stranded inventory, keeps costing money in the meantime.

What “current” actually means. Even once the lake is built, agents are reasoning over a synchronized copy. A refresh cycle of hours or a day tells you where inventory was at the last sync. A plant manager with a line about to stop needs to know where it is right now, and whether it’s already been committed to someone else.

Neither of these is a fatal flaw. They’re the honest cost of the architecture, and worth naming before you build a two-year plan around it.

A different framing

That conversation pushed me to articulate something I’d been circling for a while.

Instead of moving the data to the AI, what if you made the systems accessible to the AI?

Concretely: each inventory system exposes its capabilities as tools through the Model Context Protocol (MCP), an open standard for connecting AI to enterprise systems. If MCP is new to you, the simplest way to think about it is a universal adapter. Rather than building a custom integration for every system-to-AI connection, each system publishes what it can do (check stock, place a transfer order, query lead times) in a form any agent can discover and use, within permissions you define.

In the same shortage scenario, an agent could query live inventory across facilities from the systems of record themselves, recommend a transfer from the plant with surplus, initiate replenishment with the supplier, and coordinate the logistics handoff. All against current transactional data. All within governance boundaries the enterprise controls.

And nothing gets ripped out. The 25-year-old warehouse system keeps doing its job. It just becomes reachable.

Two questions, two architectures

I want to be careful not to swing the pendulum too far. I’ve watched enterprise technology discourse do that for 27 years, and the new pattern is almost never the death of the previous one.

Data lakes are not going away. Long-term planning still needs consolidated, historical, cleaned data, and the lake is where that lives. MCP-style access adds a different capability alongside it: governed, real-time reach into the systems where operations actually happen.

Analytics answers “what happened, and what will happen?”
Operations answers “what is happening right now, and what should we do about it?”

Those are different questions, and I think they deserve different architectures. The failure mode is using one to answer the other, or making one wait for the other.

The question I keep coming back to

As enterprises move toward agentic AI, I think many roadmaps may be optimizing for the wrong starting question.

The instinctive question is: How do we centralize our data?

The more useful question might be: How do we make our enterprise systems accessible to AI?

The first framing tends to push operational value into the distant future. The second lets an agent go to work on a real business problem in weeks, while the analytics foundation gets built in parallel rather than as a prerequisite.

I have my convictions here, and I’m building a company on them, so treat what I’ve written with that context in mind. I’ve also been wrong enough times in my career to hold those convictions loosely. So I’ll close this the way I closed my first post: by asking.

If you’re working through this in manufacturing, automotive, or supply chain, is the data lake still the right starting point for operational AI? Or are there scenarios where an accessibility-first approach gets you to value faster without giving up the analytics future?

I’d genuinely like to hear where you agree, and especially where you don’t. I’ll read every comment.