For the last several years, “AI on the shop floor” has mostly meant a chatbot bolted onto historian data. Ask it a question, it gives you an answer, you decide what to do. That’s a copilot. It’s useful, it’s low-risk, and it’s not what’s shipping now.
Look at where the major MES and automation vendors have been pointing their roadmaps. Siemens has been building agentic capability into its industrial AI stack that goes beyond diagnostics into recommending and, in some workflows, executing changes. Rockwell Automation has talked openly about agents that can act within defined guardrails inside FactoryTalk. AVEVA has pushed agentic AI into its industrial software portfolio for tasks like alarm response and workflow orchestration. SAP’s Joule has moved from answering questions to taking multi-step actions inside business processes, including ones that touch production and quality. None of these are hypothetical future features — they are being demoed, piloted, and in some cases sold, right now.
The common thread: the AI stops being a suggestion engine and starts being an actor. It can nudge a setpoint, re-sequence a work order, or auto-approve a quality disposition without a human clicking “yes” first. That’s a real and important shift. It’s also a shift that almost no plant has a written policy for.
What’s actually different about “agentic,” mechanically
A recommendation engine and an agent can run on identical models under the hood. The difference is what happens after the inference. A copilot outputs text or a flagged anomaly and stops. An agent has been granted a permission — often through an API call, a write-back to a PLC or MES parameter, or a workflow action in a system like SAP or a quality module — to actually change the state of the plant or the record.
That permission is the whole ballgame. Once an AI system can write to a setpoint, close a work order, or disposition a nonconformance, it’s no longer a tool that informs a decision. It’s a decision-maker. And your plant almost certainly does not have that role defined anywhere in your quality manual, your SOPs, or your validation documentation, because the role didn’t exist until recently.
The governance gap practitioners are hitting
Pilots are surfacing the same question in different forms: if the agent adjusts a setpoint and something goes wrong three shifts later, who is accountable, and can you reconstruct what happened? Most plants can answer that question instantly for an operator action — you have electronic batch records, e-signatures, and an audit trail baked into the MES. Almost none can answer it yet for an agent action, because the agent isn’t a user in the traditional sense. It doesn’t badge in. It doesn’t have a training record. It doesn’t get retrained after a deviation.
This is where the gap actually bites, and it’s worth naming the specific failure modes:
- No authority tiering. Everything the agent can touch gets treated the same, whether it’s a minor HMI display preference or a critical process parameter.
- No equivalent of e-signature. Regulated industries (pharma, medical device, food) rely on 21 CFR Part 11-style signed records to establish who approved what and why. An agent action needs an equivalent evidentiary trail — model version, input data, confidence score, and the rule that authorized it to act without a human — or it’s a validation liability waiting to surface in an audit.
- No rollback plan. If an agent reschedules a week of work orders based on a demand signal that turns out to be wrong, can you cleanly revert, or has downstream data already been consumed by other systems?
- No drift monitoring. A model that was validated against a process baseline six months ago may be quietly wrong today. Nobody’s watching for that the way they’d watch for calibration drift on a sensor.
A workable authority framework
You don’t need a novel governance philosophy here — you need to borrow one that already exists and apply it to a new kind of actor. ISA-95’s model of role-based authority and ISA-88’s batch/procedure hierarchy already give you a vocabulary for “who or what is allowed to do this, under what conditions.” Extend it to agents with three tiers:
- Tier 1 — Advise only. The agent flags, recommends, or drafts. A human reviews and acts. This is where nearly all deployments should sit today for anything touching product quality, safety, or regulatory-relevant parameters.
- Tier 2 — Act with human confirmation. The agent proposes a specific action and a qualified human approves it with a single click, but the system captures that approval as a discrete, auditable event equivalent to an e-signature — not a Slack message, not a verbal okay.
- Tier 3 — Act autonomously within bounded limits. The agent executes without a human in the loop, but only within parameters that have been explicitly validated as safe to automate — think narrow, well-understood adjustments with hard interlocks, not open-ended optimization.
Very little on a regulated shop floor should be Tier 3 today. Non-regulated, low-consequence adjustments — HVAC trim, non-critical scheduling suggestions, alarm triage — are reasonable candidates. Setpoint changes on a validated process, quality dispositions, and anything that becomes part of a device history record or batch record should stay at Tier 1 or 2 until your quality and validation teams have built a real case file for why the model’s behavior is predictable and bounded.
What to actually do before the next pilot
Treat the agent like you’d treat a new operator role, not like a software update. That means writing an SOP for what it’s authorized to touch, requiring the vendor to document the decision logic (not just the marketing description of “AI-powered”), and insisting that every agent action lands in the MES audit trail with the same rigor as a manual entry — timestamped, attributable, and reversible.
Ask vendors directly what tier their agentic features actually operate at, because the sales deck won’t volunteer it. And loop in your quality and validation team before the automation team signs a pilot agreement — in a validated environment, an agent that writes to production records is a system change, not a feature toggle, and it needs to go through change control like anything else that touches your quality system.
The vendors are moving fast because the underlying model capability genuinely justifies it. That doesn’t mean your plant’s governance has to move at the same speed. It means it has to move deliberately, with the authority boundaries written down before the agent ever gets write access to anything that matters.
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.
