Every MES and SCADA vendor with a product roadmap slide is now showing you an agent. Ask it why line 4 is down, and it’ll tell you. Ask it to recommend a changeover sequence, and it’ll suggest one. Some will even take action — kick off a work order, page a technician, adjust a setpoint within guardrails. The demos are genuinely impressive. The problem isn’t the AI. The problem is what happens when that same agent gets pointed at your actual historian and your actual downtime log instead of a curated demo dataset.
Most plants’ OEE and downtime data is not structured well enough for an autonomous system to reason over it. It’s structured well enough for a human to eyeball a Pareto chart once a week and make a judgment call, because humans are extraordinarily good at filling in gaps, ignoring garbage, and applying tribal knowledge the data itself never captured. An agent doesn’t have tribal knowledge. It has whatever’s in the tag structure, the reason code table, and the event timestamps — and if those are inconsistent, an agent won’t just be less accurate than a person. It will be confidently wrong, at scale, continuously, which is a much worse failure mode than a dashboard nobody trusts.
Why this is a data problem before it’s an AI problem
Agentic AI orchestration, whatever a given vendor’s marketing calls it, still boils down to a model reasoning over context and taking or recommending action within some workflow. The quality ceiling of that reasoning is set entirely by the quality floor of the data it can see. This is not a new idea — it’s the same “garbage in, garbage out” problem that has haunted every analytics initiative in manufacturing for decades. What’s changed is the cost of getting it wrong. A bad BI dashboard just sits there unused. A bad agent actively recommends actions, and if it’s wired into anything with write-access — a WMS, a maintenance CMMS, a line controller — bad reasoning becomes a bad action.
Before any pilot, the honest question isn’t “which vendor’s agent is smartest.” It’s “would a new engineer who joined last week and only had access to our OEE and downtime tables be able to correctly diagnose what happened on second shift yesterday?” If the answer is no, an agent can’t either.
The readiness checklist
Tag naming that means something without a decoder ring
If your tag naming convention only makes sense because Dave who set up the historian in 2011 remembers what it means, you have a documentation problem masquerading as a data problem. An agent needs a consistent, ideally ISA-95-aligned hierarchy — site, area, line, cell, equipment, tag — so it can reason about scope. “Is this a machine-level fault or a line-level stoppage?” is a question the tag structure should answer on its own, not a question that requires a phone call. Audit your naming convention for consistency across lines and across sites before you even think about connecting an agent to it. Inconsistent naming between two lines running the same process is one of the most common and most fixable failure points.
Reason-code hygiene, not reason-code sprawl
Downtime reason codes are where most OEE programs quietly rot. Operators under pressure default to “Other” or “Misc” because the real code is three menus deep on the HMI. Over time you end up with a reason code list that’s grown to hundreds of entries, half of them near-duplicates, a third of them never used, and a chunk of your downtime bucketed into a category that tells you nothing. An agent trying to correlate downtime causes with shift, product, or operator will treat “Other” as a legitimate category and either ignore it or, worse, draw a false correlation because “Other” happens to cluster on Mondays. Before a pilot, prune the reason code taxonomy to a manageable, mutually exclusive set, retrain operators on it, and — critically — track what percentage of downtime is still landing in catch-all buckets. If that number is high, fix it first. No agent can reason its way out of a taxonomy problem.
Event timestamps that agree with each other
Downtime events, quality events, and OEE calculations often come from different systems — PLC, MES, historian, manual entry on a tablet — each with its own clock, its own latency, and its own idea of when a “stop” actually started. A five-second discrepancy between a fault timestamp and a shift-log entry is invisible to a human doing weekly analysis. It’s a serious problem for an agent trying to sequence cause and effect, especially if it’s correlating a downtime event against an upstream quality deviation or a changeover log. NTP synchronization across PLCs, historians, and MES servers isn’t glamorous work, but it’s foundational. So is deciding, organization-wide, whether a downtime event’s timestamp is when the fault triggered, when the PLC logged it, or when an operator acknowledged it — and making sure every system agrees on the answer.
Context linking: the piece everyone skips
This is the one that separates a usable data layer from a pile of clean-but-isolated tables. An agent doesn’t just need to know a line stopped for eleven minutes with reason code “changeover.” It needs to know what product was running before and after, which operator was on shift, what the last maintenance action on that asset was, and whether a quality hold was active. That means your OEE/downtime layer has to be joined — reliably, not through a nightly batch job someone forgot to schedule — to your MES work order data, your CMMS maintenance history, and ideally your quality system. Most plants have all of this data. Very few have it linked at the event level in a way a query, let alone an autonomous agent, can traverse without a data engineer hand-writing a join every time.
What to actually do before you pilot anything
Run a data readiness audit before you run an agentic AI pilot, not alongside it. Concretely: pick one line, pull every downtime event from the last full quarter, and try to manually reconstruct root cause for the top ten stoppages using only what’s in the system — no tribal knowledge, no phone calls. Where you hit a wall — an ambiguous reason code, a timestamp that doesn’t reconcile, a missing link to what job was running — that’s your punch list. It will almost always include the same four items: naming conventions, reason code hygiene, timestamp reconciliation, and context linking. Fix those, and you’ll find that a lot of the value you were hoping the AI agent would deliver — faster root cause, better Pareto visibility, tighter shift handoffs — starts showing up before the agent is even switched on.
That’s worth sitting with. The vendors racing to ship agentic features in 2026 are competing on orchestration and model integration, and that’s a legitimate technology race. But for most plants, the binding constraint isn’t which copilot you buy. It’s whether the data underneath it can support a conclusion an agent — or a person — can actually trust. Pilot the agent once that’s true, and it has a real shot at earning trust on the floor instead of becoming the next tool operators quietly route around.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
