Walk any manufacturing software trade show floor this year and you’ll hear the same word roughly every ninety seconds: agentic. Microsoft has it, SAP has it, Salesforce has it, and a long tail of MES and quality-management vendors have rebadged their copilots as “agents” almost overnight. The pitch is consistent across all of them: instead of a dashboard that tells you a lot is trending out of spec, an agent notices, reasons about it, and does something — holds the lot, opens a work order, nudges a setpoint, routes a deviation to the right approver.
That’s a real and worthwhile idea. It’s also, in the vast majority of what’s shipping today, not what you’re actually getting. Most of what’s being called “agentic AI” in manufacturing right now is a large language model sitting on top of your existing data warehouse or historian, generating fluent summaries and suggestions. That’s useful. It is not the same product as software with the authority and the guardrails to write back into your MES, your PLC logic, or your quality system. Plant IT teams need a way to tell these apart before procurement signs anything, because the two categories carry wildly different risk profiles and require completely different governance.
The line that actually matters: read-only vs. write-capable
Forget the marketing taxonomy of “co-pilot” versus “agent” versus “autonomous agent” — vendors use these terms inconsistently and sometimes interchangeably. The distinction that matters to you is much simpler: can this thing only read and recommend, or can it write and act?
A read-only system, however sophisticated its reasoning, is fundamentally a smarter reporting layer. It queries your MES, ERP, and historian data — often through the same OPC UA tags, ISA-95 B2MML interfaces, or REST APIs your existing dashboards use — and produces a recommendation a human reviews. Worst case, it’s wrong and someone ignores bad advice. That’s a data-quality and trust problem, not a safety problem.
A write-capable agent is different in kind. If it can trigger a work order in the MES, place a quality hold on a lot, adjust a process parameter, or release material to the next operation, it has become an actor in your production system with real consequences if it acts on stale data, a hallucinated interpretation, or a permission it shouldn’t have had. That’s the category deserving the scrutiny of a control system change, not a software rollout.
When a vendor says “agentic,” ask them directly: what write transactions can this execute without a human clicking approve, and against which systems? If the honest answer is “none yet, that’s on our roadmap,” you’re looking at a chat wrapper with good branding. That’s fine — just don’t let procurement, or the vendor’s own marketing, blur that into “closed-loop autonomy.”
A quick field test
Three questions separate genuine closed-loop agents from dashboards with a chat box:
- Can it act without a person in the loop, under defined conditions? Not “can it draft an action for approval” — can it actually execute a transaction against MES, ERP, or a control system on its own, even in a narrow, pre-approved scenario?
- Is there a reversible, logged transaction on the other end? A real action against a real system — a work order created in the MES, a hold flag set in the quality module, a setpoint change logged in the historian — not just an email or a Teams message that looks like an action but changes nothing downstream.
- Does the vendor have an actual permissioning model for agent identity? Not “the agent uses admin credentials,” but a distinct, scoped, auditable identity with its own role, the same way you’d provision a contractor or a new hire.
What plant IT should demand before an agent gets write access
If a vendor clears that bar — genuine write capability — the evaluation doesn’t get easier. It gets harder, because now you’re doing the same due diligence you’d do for any system with a hand on the process. A few things belong in every RFP and every pilot agreement:
Data contracts, not data access
An agent that reasons across MES, ERP, and historian data needs to know not just where the data lives but what it means, how current it is, and what its confidence bounds are. That means explicit data contracts: which tags and records the agent is allowed to read, at what refresh rate, with what staleness tolerance before it must refuse to act. An agent making a hold decision on a four-hour-old sensor read because nobody defined a freshness threshold is a failure mode vendors rarely mention until you ask.
Scoped permissioning, mapped to existing role models
Your MES almost certainly already has a role-based access model tied to ISA-95 concepts — operator, shift supervisor, quality engineer, plant manager. An agent needs to slot into that model as its own role, with its own least-privilege scope, not inherit a service account with broad rights because that was easier to configure. Ask specifically what the agent can do that a level-2 operator couldn’t, and why.
Audit trails built for scrutiny, not just logging
Every write action needs a record of what data the agent saw, what it reasoned (even if that reasoning is a model’s approximate explanation, not literal logic), what it decided, and what happened downstream — in a format that holds up under a quality audit or, in regulated industries, an FDA or customer audit. Generic application logs aren’t sufficient. If you can’t reconstruct why an agent held a lot six months after the fact, you don’t have an audit trail, you have a log file.
A bounded blast radius
Before any agent gets write access, define what it’s allowed to touch and what it categorically is not. A well-scoped agent might be permitted to create a maintenance work order but not to close one, or to flag a lot for quality review but not to release it. IEC 62443’s zone-and-conduit thinking applies here even outside classic OT security contexts: segment what the agent can reach, and don’t let convenience during a demo talk you into a broader grant than the use case needs.
A kill switch that’s actually tested
Ask how you disable the agent’s write access without taking down the whole system, and ask to see it done. If the vendor can’t demonstrate a fast, clean revocation path, that alone should slow down the rollout.
The honest state of the market
None of this means agentic AI in manufacturing is vaporware. Constrained, well-scoped closed-loop actions — an agent creating a maintenance ticket when a vibration threshold is crossed, or auto-generating a nonconformance record from a quality exception — are genuinely achievable with today’s tooling, and some plants are running exactly that in production. What’s overstated is the leap from there to broad, ambiguous “autonomous decision-making” across MES and ERP, which is where most vendor demos currently live and where the governance simply hasn’t caught up with the pitch.
The practical move for plant IT in 2026 isn’t to reject agentic AI or to rush it in. It’s to insist that every agent earn its write access the same way a new automation change would: scoped, permissioned, logged, and reversible. Vendors who’ve actually built that will welcome the questions. The ones still selling a chatbot with a new label will start talking about roadmap.
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.
