What It Takes For An AI To Actually Work On The Manufacturing Floor

Open any general-purpose LLM (Claude, ChatGPT, Gemini, etc.), paste in a week of fermenter temperature readings, and ask it what went wrong. You'll get an answer that is articulate, structured, and confident. And it might even get some of the general fermentation science correct. But ask a plant engineer whether they'd change anything based on the findings, and you may get a silent head shaking, if they are polite.

Is it the case that LLMs are bad at reasoning? No, at least not the frontier models. However, surface-level reasoning is only one piece... and in manufacturing, it is the easiest piece. The hard parts are what goes into making that reasoning drive value: getting access to the data holistically, knowing enough about your plant to interpret it correctly, remembering what happened last week, last month, and so on, delivering insights to the right stakeholders at the right time, and doing all of this without the production data ever leaving your secure plant environment.

For teams looking at AI enablement in their manufacturing environments, the question isn't whether LLMs can do it. They can. The question is what has to be built around the model to produce genuine signals, not noise.

The Data Access: Your Variables

The most fundamental limitation of an out-of-the-box LLM is also the most obvious: it has no way to access your operational data.

Plant data lives behind layers of network security, spread across multiple, and often incompatible, systems: PLCs speaking proprietary protocols, historian DBs accessible only through specific interfaces, MES databases locked behind Windows authentication, proprietary software such as Asset Watch, FIIX, etc. None of these systems is designed to talk to a chatbot, and the concept of LLMs didn't exist when they were built.

To use an LLM for anything meaningful, one first has to solve the data collection problem, which is the same problem we explored in depth in our previous article on manufacturing data integration. That means building and maintaining a library of connectors, each tuned to the specific quirks of a source type (protocol compatibility, authentication method, data format), coordinated by a system that manages scheduling, retries, backfills, and health monitoring.

This is not a prompt engineering exercise; it's infrastructure engineering - often the hardest, invisible, and most under-appreciated part of making AI work in production environments. Before a model can reason over your process, the data has to be reliably collected, structured, and made available from dozens of incompatible sources, focused to keep context minimal, yet holistic enough to provide all required variables for the reasoning and decision-making.

The Context Problem: Your Process

After having data access solved, a general-purpose LLM doesn't know your plant; it doesn't know that.

• The facility runs batch fermentation on a 60-hour cycle
• Fermenter 3 historically underperforms relative to the others
• A data entry error on June 18th corrupted your wetcake yield calculations for two days
• The maintenance team ran a hot-water rinse on the beer column last Tuesday, and you're waiting to see if it changed the fouling curve.
• And many more daily operational events

Without this context, the model does what it was trained to do: it generates almost-true-sounding analysis based on general knowledge. And almost-true-sounding is precisely the problem - the fastest way to lose operator trust is to deliver recommendations that are too specific without sufficient context. 

It is statements like "increase fermenter temperature to 91.3°F," derived from four weeks of data, without accounting for seasonal variation, enzyme lot changes, or the fact that the plant already tried that last month and it didn't work (most important: incremental learning).

The systems that earn trust are those that carry forward weeks and months of operational and plant context, not those that reason from scratch every time a question is asked. What this means: curated domain knowledge, structured descriptions of the process, validated formulas and thresholds, operational logbooks that record anomalies and plant decisions, and continuous feedback loops where human expertise corrects and refines what the AI produces. Anything short of this is throwing darts in the dark!

Building this context layer is painstaking, plant-specific work. It cannot be downloaded or fine-tuned from a public dataset... it is accumulated over time, through direct collaboration between AI and plant engineers, and it is what transforms a model's output from "technically plausible" to "actually useful".

The Memory and Continuity Problem: Your Past

Useful manufacturing intelligence is inherently temporal;

• a weekly performance report needs rolling four-week context to detect trends
• a deep-dive root-cause analysis might span six months (or more) of historical data to validate a hypothesis
• an early-warning system needs to have learned what "normal" looks like for each signal variable - a constantly moving golden baseline - and flag deviations against that learned profile in advance.

In contrast to the requirements, out-of-the-box LLMs are stateless; every conversation starts fresh. The model doesn't remember that last week's analysis flagged elevated acetic acid levels in two fermenters, doesn't know whether the recommendation it gave was followed, whether it worked, or whether the same problem has now persisted for three consecutive weeks. Each conversation starts with a clean slate, and any continuity has to be reconstructed manually by the user.

In practice, this means that temporal intelligence requires a purpose-built system augmenting the model, one that maintains running state across sessions, accumulates observations over time, tracks whether issues are recurring or resolved, and feeds this historical context back into each new analysis. 

The difference between something that sounds legit and a persistent system is continuity: the ability to watch a process evolve, remember what it observed, and learn from what happened next. Without this, models cannot drive a continuous improvement process.

The Insight Execution Problem: Your Focus

Suppose you solve all of the above: reliable data access, rich domain context, and temporal continuity. You now have a system that can generate genuinely useful analysis. The next question is deceptively simple: who sees it?

A general-purpose LLM delivers its output to exactly one surface, which is the chat interface of the person who asked. It lives inside a chat interface: the engineer who prompted it sees the analysis, the shift operator on the floor doesn't, the plant manager reviewing Monday's performance doesn't, the on-floor team that could have acted on a 2 PM acid spike doesn't!

Useful intelligence requires an execution layer, a delivery infrastructure that gets the right information to the right people at the right time through the right channel. That could mean, exhaustively:

• daily operational snapshots delivered to operators before their shift begins
• weekly performance reports sent to plant management
• ahead-of-time early warnings that trigger push notifications or emails when thresholds are breached

LLMs that live inside a browser window, just being a chatbot, stay with the person who asked. Intelligence that's embedded into operational workflows - automated notifications, scheduled reports, mobile alerts, embedded dashboards - reaches the people who need to act.

The Privacy Problem: Your Data

Solving all the above brings us to a constraint that rarely appears in AI marketing materials but dominates every serious manufacturing deployment conversation: raw production data cannot leave the secure plant environment.

Manufacturing facilities operate under strict data security protocols. And it makes sense. Process recipes are proprietary, yield data is competitively sensitive, quality records may have regulatory implications, etc. And even setting aside sensitivity, many plants operate with restricted internet connectivity - air-gapped networks where the idea of sending raw data to a cloud API is architecturally impossible.

The solution requires a fundamentally different deployment model: local-first architectures where data collection, processing, machine learning pipelines... all run entirely within the plant's network perimeter or approved data center regions. Keeping 100% of production data within the facility while still delivering intelligence is a non-negotiable feature - any platform that requires data to leave the premises in an uncontrolled manner has disqualified itself.

The Scaling Problem: Your Trust

There is one final gap that separates a working prototype from a production deployment, and it has nothing to do with model capability. It's all about the product design.

A skilled plant engineer can use a general-purpose LLM effectively: they know the right questions to ask, can frame prompts with the necessary context, and can critically evaluate whether the output makes sense. 

But making that same intelligence accessible at an enterprise level. Shift operators who need simple, actionable daily updates; plant managers who need executive summaries and trend visualizations; maintenance teams who need alerts calibrated to their specific domain - that requires product design, not prompt engineering.

The gap isn't in what AI can do. It's in who AI can reach and add value in their day-to-day output. The difference between a personal tool and an organizational capability is product design and ease of usage, not model size.

The Full Picture for LLMs

Undoubtedly, LLMs are extraordinary. They are the most capable reasoning engines we have built until now, and their ability to process, synthesize, and generate useful analysis from unstructured information is genuinely transformative. That part is an indisputable fact.

But a reasoning engine alone is not a solution. In the same way that an engine is not a car. You need a chassis, wheels, fuel lines, a transmission, and a driver to actually go somewhere. An LLM without the augmenting software and infrastructure is impressive but inert.

The question for any manufacturing team evaluating AI today isn't "how powerful is the model?" It's "what has been built around the model to make it work in our world?"