Position · · 5 min

Most plant-floor AI shouldn't be an LLM

The money problems in an industrial operation are mostly tabular and timeseries problems. Language models earn their place at the document pile, not the forecast.

We build with language models and we like them. This is not that essay. But most first conversations we have now start with “we need an AI strategy” and mean “we need an LLM somewhere visible,” and for an industrial operator that instinct points at the wrong end of the building.

Look at where a mid-size manufacturer or distributor actually loses money: forecast error, unplanned downtime, scrap, stockouts, slow quotes, missed service levels. Now look at the data those problems live in: order lines, downtime logs, sensor histories, delivery records. Tables and timeseries, years deep, sitting in the ERP and the historian.

The plant's money problems are tabular. The chatbot is pointed at the wrong data.

Boring models, embarrassing returns

For tabular and timeseries prediction, the workhorses remain gradient-boosted trees, well-built regressions, and occasionally a small neural net, trained on your own history. They are fast to train, cheap to run, and they explain themselves well enough that a planner can argue with them, which matters more than the last two points of accuracy. On problems like demand forecasting and failure prediction, these methods routinely beat far more fashionable architectures, and the research community keeps rediscovering this to its mild annoyance.

None of this requires a GPU cluster or a token budget. It requires the unfashionable work: cleaning nine years of history, joining tables that have never been joined, and wiring the output into the screen where the decision gets made. When someone quotes you a seven-figure “AI transformation,” check how much of it is that work. Usually none of it is, and that is the tell.

Where the LLM earns its place

Every industrial company also sits on a second pile of data the tabular tools can’t touch: contracts, claims, specs, certificates, maintenance manuals, decades of tickets. Answering a question from that pile is genuinely a language problem, and language models are genuinely good at it.

“If line 2 is down until Friday, which customer contracts do we breach?” is a three-day, four-person job at most operators we meet. An agent with retrieval over the contracts and read access to open orders answers it the same hour. The conditions that make it safe are non-negotiable: every answer cites the clause and the rows it came from, and a person signs off before anything leaves the building. An LLM without citations is a very confident colleague you can't cross-examine, and no operator should put one near a commitment.

The test we use

When a candidate system comes up in a diagnostic, we ask: is the underlying question a prediction over your operating history, or a question answered somewhere in your documents? The first gets a boring model and a place on an existing screen. The second gets an agent with citations and a sign-off step. A surprising amount of vendor pitching exists to blur exactly this distinction.

Both kinds of system move real numbers. But if your budget only stretches to one this year, the unfashionable answer is usually the right one: the forecast before the chatbot. The chatbot will still be there next year, cheaper and better. Your forecast error is costing you money this quarter.