Two Operators Can Think Differently and Meet the Same Goal
Plants judge operators by results within limits. Agents should be judged the same way.
A colleague who works with pharmaceutical manufacturers wrote to me recently. The smart manufacturing leads in those conversations want deterministic artificial intelligence (AI) agents, and the question put to me was how to address that. It is a fair request from an industry where every batch record is an inspected document.
What a business needs from an agent is what it already needs from an operator: work toward an agreed goal, act within approved limits, and produce results that can be checked. The reasoning can vary. The definition of success and the rules that govern every action must stay fixed.
“Deterministic” usually means one of three things.
It can mean the same answer every time, and a hosted language model may give different answers even to the same request with the same settings. It can mean the same decision about whether a proposed action is allowed, given the same conditions, which software can guarantee. Or it can mean a decision you can rebuild and explain months later, which a complete record makes possible.
The last two are the ones that matter in a plant, and both can be built today.
Human Operators and Agent Operators
What makes a plant predictable today
Put two experienced operators on the same shift, in front of the same screens, and they will not think through a problem the same way. Kahneman, Sibony and Sunstein collected the research on this in Noise: experts given identical cases often reach different conclusions. Plants do not depend on operators agreeing. Procedures, operating limits and permits set what either operator may do, and interlocks, the rules wired into the plant so a valve cannot open while a condition holds, enforce the parts that must never be left to judgment. When both operators make sensible moves inside those rules, the plant judges the shift on its results: throughput, quality, energy and time spent inside the limits.
Agents should be built and judged the same way, which comes down to two separate questions. Was the action permitted? And did it move the plant toward the goal?
The goal defines success
Start with the goal, because that is what an agent is for. In a plant it can be written down precisely. Utility functions express how much different levels of throughput, quality and energy use are worth to the business, and an objective function combines them into one agreed score. I have written about these objective functions before, in “KPIs Can’t Make Decisions”. Given the same plant data, the score comes out the same every time. The language model can propose different plans, but it cannot redefine success.
That is where an industrial agent should be judged. Two agents, or two runs of the same agent, may choose different moves, and the question is the one a plant asks of two operators: over an agreed period, allowing for whatever else happened on the plant, which move improved the measured result more while staying inside the limits?
A fixed goal does not make success certain, because plants have disturbances and some targets turn out to be out of reach. It makes the judgment of success repeatable. That matters, because a system that makes the same mistake every time is perfectly predictable and of no use to anyone. Two rules make the evaluation meaningful: the agent is scored on what the plant measured after it acted, never on its own prediction, and safety and quality limits are enforced as checks that no score can override.
A language model is one part of an agent
**Much of the confusion comes from treating the language model and the agent as the same thing.**Gartner describes AI agents as software that uses “AI techniques to perceive, make decisions, take actions and achieve goals”. A language model is one of those techniques. On its own it cannot read a plant, it holds no goal, and it takes no action. An Operator Agent is not the coding agent you get from Claude or Codex (or all the other coding platforms with “agents”)
Related: Operators, Not Creators
Most of the agent products I am shown put the language model in charge anyway. It decides what to do next and when the job is finished, and little outside it checks the result. Every one of those choices can change from one run to the next.
An industrial agent team is built the other way round. I have written before that a true multi-agent system is about 90% business process logic, and I counted our own code again on 17 October to check. About 9% of XMPro MAGS (Multi-Agent Generative Systems) is the code that calls a language model and the templates for its instructions. Most of the rest implements the surrounding process: memory, scoring against the goal, coordination between agents, communication and records. Its behavior still depends on the information and events it receives, which is why the record matters. The model is called at fixed points to interpret what is happening and propose a plan, and the rest of the system decides what happens to that proposal.
What keeps the outcome inside the limits
On a petrochemical plant where agent teams are connected to the customer’s control system the design puts rules on both sides of the agents.
Before any agent sees a reading, the plant’s data is checked. Failed or stuck instruments are caught and flagged, a validated estimate or the last good value stands in for a failed reading, and every limit is calculated from tables the plant’s engineers approved. The agents never calculate a limit themselves.
After an agent proposes a change, the software that would send it asks three questions at that moment. Has the operator switched this unit to act mode? Is this something agents are allowed to change? Is the value within its limits? If any answer is no, the change is refused, logged and reported to the operator. In advise mode, agents recommend and nothing is written. The plant’s own control logic and safety systems stay independent of all of it.
The agents are also told in their instructions not to change anything unless the unit is in act mode. That instruction helps, but it is not what keeps the plant safe. The model is asked to follow the instruction, and the check runs whether it follows it or not.
I have written before about computable policies, and this is where they earn their place. A rule written in a document or a prompt is guidance. A computable policy is the same rule written so software can check it against plant data, and for an agent that is the form that binds. An agent with its rules built in as checks applies them on every action and every shift, without fatigue or shortcuts.
Staying within the rules is only part of the job
An agent can follow every rule and still miss the goal. It might keep a pump within its approved speed limits but fail to deliver the required flow.
We therefore need to check two things: did the agent stay within the limits, and did the process achieve the intended result?
Three questions to ask a vendor
Can you replay any past decision from its record and show it would be decided the same way again? When the model gives a different answer, can you show that nothing outside the limits gets through? Against a goal we agree before the trial, what did the agents actually achieve?
A system can refuse every request and still pass the first two questions. The third establishes whether it meets the agreed operating goal, which is why all three belong in the acceptance plan.
For engineers who want the mechanism, our in the Multi-Agent repository covers how inputs are validated, how each action is checked before it reaches the plant, how rules are held as computable policy, and what goes into the decision record. Gavin Green and I set out the full argument, with formal definitions, a five-test assurance protocol and references, in the working paper Deterministic Where It Counts. In pharma, the same questions line up closely with what regulators are starting to ask, which I cover in an upcoming companion piece, “Six Things Pharma Should Prepare to Demonstrate About an AI Agent”.
The useful question for a manufacturing leader is what each decision in a process has to get right. Write down the goal it is judged against, what agents may change and who may let them, and the evidence your team will see afterward. Once that list exists, the language model has a defined job: interpret situations no rule anticipated and propose actions that the surrounding process checks and evaluates, inside a goal and limits that stay the same every time.
Pieter van Schalkwyk is the CEO of XMPro, specializing in industrial AI agent orchestration and governance. Drawing on 30+ years of experience in industrial automation, he helps organizations implement practical AI solutions that deliver measurable business outcomes while ensuring responsible AI deployment at scale.
He is the lead author of the Industrial AI Agent Manifesto, published by the Digital Twin Consortium in February 2026, a governance framework for trustworthy autonomous operations.
Our GitHub Repo has more technical information. You can also contact myself or Gavin Green for more information.
Read more on MAGS at The Digital Engineer
How this was made: I worked with Claude to check sources, draft from my direction and edit, and with Codex to review the argument and evidence. I do not publish anything I have not rewritten myself.
This article originally appeared on XMPro CEO’s LinkedIn blog, The Digital Engineer, on 19 October 2026.
