The demos look great. A second use case is launched. Then a third. Each one starts from scratch. None of them builds on the others. After twelve months, the board’s question shifts from “What is our AI strategy?” to “Where’s the return on investment?” Why 95% of corporate AI projects fail to deliver a return on investment.
The data confirms what those responsible for digital transformation are observing in their own companies. The report from the MIT Media Lab’s NANDA project concludes that, despite companies’ enormous investments in generative AI, 95% of companies are not achieving a business return. And the report includes a quote from an interview with the COO of a medium-sized manufacturing company that I found particularly valuable for this discussion:
“The hype on LinkedIn suggests that everything has changed, but nothing fundamental has shifted in our operational processes. We’re processing some orders faster, but that’s really all that’s changed.”
So this isn’t a modeling problem—it’s an architectural problem. This becomes most evident in a discussion currently taking place in nearly every IT department of a manufacturing company: Should we connect our new AI agents directly to the operational systems that control the factory?
The technically correct answer is “no.” The strategically important answer is: “Why?”
Why Directly Connecting AI to Operational Data Fails
There’s a meme circulating in IT circles that sums up the problem with a reference to Gandalf: You shall not connect an MCP to your operational database.
The Model Context Protocol (MCP) is the new standard for granting AI agents access to enterprise data and tools. In a manufacturing environment, the operational database behind the execution system stores the current production status. Work in progress. Equipment status. Quality holds. Genealogy. Operator actions. Process enforcement. Technically speaking, it’s possible to connect an AI agent directly to this database. But it’s also the fastest way to ensure that your AI program never makes the leap from pilot operation to production.
MCP and the Problem of “False Abstraction”
The reason lies not only in security, although the security risk is real. The reason is that this architecture is not scalable. Every new use case must figure out the same operational meaning from scratch. Every model must relearn what a “Hold” instruction means, what a route is, who is authorized to approve what, and what constitutes a valid state change. There are no cumulative resources. There is no shared context. There is no regulated path from insight to action.
Every AI pilot project that bypasses the execution layer rebuilds the context that should actually be created once and reused forever. Executives driving these transformations sense this intuitively, even if they can’t put a name to it. That’s why their pilot projects look impressive in the conference room but prove fragile on the shop floor. That’s why the second use case takes almost as long as the first. That’s why the program never reaches its promised scale.
4 Hidden Sources of Error When AI Bypasses Your Operational Level
When AI is connected to manufacturing through the wrong level of abstraction, four specific things go wrong. None of these manifest as system errors. All of them show up on the income statement.
1. Loss of Trust on the Shop Floor
An AI agent that draws conclusions from raw data tables will ultimately deliver a confident, plausible, but incorrect answer.
In the boardroom, that’s embarrassing. In a factory, it changes the way operators treat every future recommendation. Once manufacturing employees lose trust in the system, the value of every downstream use case drops to zero—regardless of the model’s quality.
2. Decisions at the Wrong Level
A row in a database is not a business transaction. Actions such as lifting a lockout, changing a route, moving materials, or adjusting equipment statuses are subject to manufacturing decisions that involve rules, approvals, and consequences. An AI based on rows rather than events makes decisions that appear correct when viewed in isolation but cause chaos when considered as a whole. The operational definition of a delayed batch is not the same at one site as it is at another.
Models that do not take this into account provide recommendations that represent an average across all plants and are not applicable anywhere.
3. Uncertain Automation and Untraceable Actions
There is only a single tool call between an AI that answers a question and one that performs an action. Without a regulatory layer in between, that boundary disappears.
So if an agent ultimately writes incorrect data into production or triggers a workflow that skips a required check, the incident report won’t say, “It was the AI.” It will say: “We don’t know what happened.”
That is a worse outcome than any number of failed pilot projects, no matter how large.
4. Regulatory Risks in Validated Environments
In regulated environments—including medical devices, pharmaceuticals, semiconductors, and, increasingly, aerospace and defense—any system that affects production status must be validated, traceable, and explainable.
An AI agent with direct database access cannot meet this standard. The agent itself isn’t the problem; it’s the architecture surrounding it. Any regulatory authority involved will recognize this even before the AI team does. Each of these issues can be resolved in a pilot project. None of them can be resolved in production operations.
The cost of fixing these issues retroactively—through revalidation, rebuilding trust, and restoring credibility with the board—is an order of magnitude higher than the cost of designing the architecture correctly from the start.
Why AI Demos Work, But Production Doesn’t
It’s never been easier to create an AI demo for manufacturing. APIs, connectors, MCP, function calls, low-code orchestration. A skilled team can produce something impressive within a week: realistic-looking data, natural-language responses, generated SQL, a draft action plan. To executives, it may seem as though the future is already here, but in reality, they’re still a long way from it.
What Demos Leave Out (and Why It Matters)
Most of these demos work because they leave out the crucial parts. They run on limited amounts of data. They assume clean semantics. They use user-friendly prompts. They rely on elevated permissions. They avoid edge cases. They aren’t confronted with the pressures of shift changes, audit requirements, plant exceptions, site-specific configurations, or regulatory oversight.
Anyone can demonstrate AI, but few can deploy it reliably in live operations. The difference lies not in the model, but in what lies between the model and the factory. A proof-of-concept can answer the question: “Which batches are delayed?” A production system must answer a much more difficult question: Which batches are delayed—according to the correct operational definition, for this user, at this location, based on validated data, with traceable reasoning, without disclosing confidential information, and without triggering an unsafe downstream action.
Execution as the Canonical Context for AI
The correct pattern is easy to describe but more difficult to implement. AI agents should not connect to the operational database. They should connect to regulated production capacities, which in turn operate via the execution system.
This regulated capacity layer is where the added value is created, and that is where the business significance lies. Authorization, sequencing, validation, and traceability are also enforced there. There, the distinction between “recommend” and “execute” is made explicit.
Every AI use case connected through this layer reuses everything that has been previously modeled, rather than reinventing it.
Structure First, Intelligence Second
What I have emphasized time and again is that a well-modeled execution layer is the canonical operational data model that makes AI trustworthy at scale. Simply put: structure first, then intelligence. McKinsey reached the same conclusion from a different perspective in April 2026. In “Scaling agentic AI with data transformations,” they report that nearly two-thirds of companies have experimented with AI agents, but fewer than 10% have scaled them to the point where they deliver tangible value. Their assessment is clear: “Success with agentic AI depends on a data architecture that can support increasing levels of autonomy, coordination, and real-time decision-making.”
Eight out of ten companies cite data constraints as a barrier. In the manufacturing industry, this data architecture already exists. It is referred to as the execution layer. For a CIO or transformation leader, this shifts the focus of the AI discussion in a useful way. The question is not which AI tool to buy. The question is which layer of the architecture possesses the controlled capabilities on which every future AI use case will depend.
If this layer exists and is under your own control, AI becomes an investment that pays off. If this is not the case, every pilot project is a standalone initiative, and the program will never reach the scale that justifies the budget. Create an execution layer that amplifies every AI use case.
If you’re leading digital transformation at a manufacturing company, a shift in the AI discussion is on the horizon. The first wave was about access: Can we get models to communicate with our systems? The next wave is about control: Can we get models to act through our systems securely, at scale, and with self-reinforcing results?
The companies that win this next wave will not be the ones with the best models. They will be the ones whose operational layer has been built to form the canonical context for AI. They will have a standardized competency layer upon which every new use case can be built at no cost. Their second AI initiative will cost only a fraction of their first. Their tenth will be almost free. The companies that fall behind will continue to launch pilot projects. The pilot projects will continue to look good. And the return on AI investment will continue to take twelve months to materialize.
AI in manufacturing doesn’t fail because the models are wrong. It fails because the execution was never properly modeled. Once that’s fixed, AI stops being a pilot program and becomes a self-reinforcing asset. So yes, you shouldn’t connect MCP directly to your operational database. But the real point goes beyond that. You should build an execution layer that makes every AI use case a multiplier of the previous one, rather than a repetition of the same initial project.
This is the architectural decision that determines whether your AI program achieves the scalability it was sold on, or whether it quietly becomes the most expensive collection of demos your company has ever paid for.
– – – – –
Further Reading
👉 www.criticalmanufacturing.com
Photo: unsplash
