The New Operator: Why Agentic AI in OT Needs Architecture We Haven't Built Yet

There is a new operator in your control room.

You did not hire them. You did not background-check them. You did not run them through the same training, observation, and qualification as every other operator in that room.

They may already have the authority to act.

This is the part of the AI conversation that has quietly moved past hype. Not chatbots. Not dashboards. Not predictive models that suggest what a human should do next.

Agent software that decides, acts, and intervenes in operational systems on its own initiative, with or without immediate human approval.

Agentic AI has entered OT...The architecture to govern it has not.

Before I Go Further — A Calibration

Not every OT environment in 2026 is running agentic AI in its control room. The pharmaceutical operator is working on a 2012 control system. The water utility is still trying to complete its asset inventory. The refinery has not finished its IT/OT segmentation project. For many sectors, agentic AI is still a roadmap conversation, not a Tuesday morning.

I am not writing about every OT environment today.

I am writing about where the leading edge already is and where the rest of the industry will be in a window measured in years, not decades. The plants that will be deploying agents three to five years from now are deciding their architecture posture today, often without realizing it. Every procurement contract signed in 2026 with an "AI-ready" clause is a quiet commitment to an architecture the buyer has not yet thought through.

This is the conversation we have to start now.

By the time it becomes operational reality across the industry, the gap I am about to describe will already be a backlog.

A year ago in this OT CISO newsletter, I wrote about AI quietly entering OT LLMs, nudging maintenance actions, suggesting analytics for setpoints, and proposing "next best moves" for real-time processes via cloud-connected models. The warning then was that AI was already influencing OT operations without the governance or architecture to handle it.

That was the advisory wave.

I followed it with the argument that autonomy without verifiability is negligence but that argument still assumed a human between the model and the action.

Agentic AI removes that assumption.

The model is now between the human and the consequence.

That is a different problem. It cannot be solved by adding governance to the existing program. It requires an architecture that the industry has not yet built.

What Has Actually Changed

For most of the last decade, AI in OT meant pattern recognition. A model would identify an anomaly. A human would decide what to do about it. The human-in-the-loop was the design assumption. Agentic systems quietly removed that assumption.

A predictive maintenance agent identifies an anomaly in a pump and reduces production to protect the asset. A network defense agent detects suspicious traffic and isolates a control segment. An energy-optimization agent reroutes load between substations based on a forecast it generated 3 seconds earlier. A SOC triage agent closes the alerts it judges benign and escalates only what it considers worth a human's time.

In each case, the action happens before — or instead of — human review.

The vendors selling these systems describe them as augmenting your team. That framing is comforting. It is also wrong. An agent that can act is not augmenting an operator. It is operating.

The question is whether the program around it knows that.

Why This Is Happening Now

There is a quieter driver behind the push toward agentic AI in OT, one that the vendor rarely names. The knowledge is leaving.

The operators who genuinely understand the process, who learned the plant from a senior engineer in 1995, who can hear an unusual vibration before the sensor catches it, who know which valve to close in which order when the line trips, are retiring. The engineers replacing them are fewer, less experienced, and entering an environment documented for compliance, not for understanding.

Vendors and integrators have noticed. The pitch for agentic AI is increasingly framed not as optimization but as continuity — the system will know what to do when nobody is left who remembers.

There is some truth in that framing...There is also a trap.

The more we delegate operational judgment to agents, the less the next generation of engineers will need to develop it themselves. The knowledge will continue to decline — not in spite of agentic AI, but partially because of it. We are using AI to compensate for the disappearance of expertise, and accelerating that disappearance in the process.

The skills gap I flagged in the retrospective will not get smaller.

It will be papered over by automation that hides the gap until the day the automation itself fails.

The Network That Was Already Broken

There is a second architectural problem that the agentic AI conversation does not adequately address.

The Purdue model has been the reference architecture for industrial networks for three decades. In its original form, it isolated the operational layers from the enterprise and the internet. It was never perfect — but it was honest about its assumptions.

Those assumptions broke a long time ago.

IIoT devices broke them first. Sensors, edge gateways, and connected instruments that needed cloud connectivity quietly punched holes in the segmentation that the Purdue model relied on. Most industries never fully closed those holes. They layered controls on top, monitored what they could, accepted the compensating risk, but the underlying assumption that Levels 1 and 2 are isolated from external networks has been false in operational practice for years.

The industry response was to rebrand the problem. Purdue 2.0. Zero trust for OT. Modernized reference architecture. What the industry has not been willing to call is the simpler thing unresolved security debt. Agentic AI inherits that debt and adds to it.

Agents need telemetry. They need context. Many of them need cloud connectivity for the models themselves. Many more need corporate network access for orchestration, updates, or model drift management. That means the agent acting on your control network is connected to something that is connected to something else that is connected to the internet. And then there is what sits underneath the agent.

The OT network the agent is acting on is, in most environments, full of legacy operating systems that vendors stopped supporting years ago. Industrial protocols designed in an era when the operating assumption was that physical access equals authorization, such as Modbus, DNP3, BACnet, and certain implementations of IEC 61850, as well as much of the building automation stack. These are not vulnerable because someone made a mistake. They are vulnerable by design, built for environments where the network itself was the boundary.

Now combine the three.

• An agent with authority to act.
• A network architecture that has not enforced its boundary for years.
• A control layer of legacy systems and insecure-by-design protocols underneath.

A malicious actor who compromises the corporate path to that agent does not have to compromise the OT network in the traditional way. There is no boundary to breach. No protocol-level exploit to develop. No multi-stage intrusion to engineer.

The agent is already inside. Already authorized. Already trusted by the surrounding systems. The agent is the path.

Where the Architecture Is Missing

Every operator in an OT environment exists inside a system of authority, visibility, rollback, audit, and safety boundaries. We did not build that system by accident. It exists because operators occasionally make decisions that affect physical processes, and the surrounding architecture has to catch the consequences.

Agents do not have the same architecture around them.

• Authority. Who decided what the agent is allowed to do? In many deployments, agent authority is shaped during integration and procurement rather than through a formal governance review. The resulting scope may not be clearly documented for the asset owner.
• Visibility. A human operator's actions are visible in real time. An agent's actions are often logged but not surfaced. By the time anyone notices the agent did something, the action is already several hours old, and the operational context has changed.
• Rollback. When a human operator makes a wrong call, the correction is usually a manual procedure. When an agent makes a wrong call, the correction depends on whether the architecture supports rollback at all. Many do not. The agent commits the action. The plant lives with it.
• Kill-switch. Stopping a human operator requires a conversation. Stopping an agent should require a button. In practice, stopping an agent in many environments requires an IT ticket, a vendor call, and a decision chain that takes longer than the incident.
• Audit trail. Most agent logs capture what was done. Few capture why the reasoning, the inputs, the alternatives, the agent considered and rejected. Without that, the post-incident review is reduced to forensic analysis of the action and speculation about the intent.
• Safety boundary. A human operator knows what they are forbidden to do, regardless of the production goal. An agent optimizing an objective function will pursue that objective unless the boundary is hard-coded into the architecture—not into a policy document.

Most agentic AI deployments in OT today are missing at least three of those six.

The Accountability Question

When a human operator makes a bad call, the response is well-rehearsed. There is a review process. There is retraining. There is a qualification revocation. In serious cases, there is regulatory and legal accountability.

When an agent makes a bad call, the response is improvised.

Was it the vendor's fault? The vendor will point to the integrator. Was it the integrator's fault? The integrator will point to the asset owner who approved the deployment scope. Was it the asset owner's fault? The asset owner will point to the vendor's documentation.

Consider a composite accountability scenario: the vendor points to the integrator, the integrator points to the approved deployment scope and the asset owner points back to the documentation. Without preassigned accountability, the operator is left to absorb the consequence.

The accountability question is not theoretical. It is the question that determines whether the program will improve after an incident — or simply add another disclaimer to the next procurement contract.

What to Build Before Deploying

I do not believe in stopping agentic AI in OT. The operational pressure to deploy it is real, and the capability genuinely solves problems the industry has struggled with for years.

I believe in building the architecture before the agent acts, not after.

That starts with treating agents like new operators. A new human operator goes through scope definition, training, qualification, supervised practice, and ongoing review. An agent should go through the same. What is it allowed to act on? Under what conditions? Who reviewed its decision boundary? Who can rescind its authority? Is there a probationary period where its decisions are reviewed before they are executed?

It continues with separating authority from action. An agent can recommend an action and execute it pending operator confirmation, and for high-stakes decisions, that should be the default, not the exception. The argument that "the operator will just rubber-stamp it" is a training problem, not an architecture problem.

It requires kill-switches built into the system, not into procedures. The operator on shift should be able to stop the agent, just as they can stop a process immediately and locally, without escalation.

It requires auditability of reasoning, not just action. If the program cannot reconstruct why an agent made a decision, it cannot learn from that decision.

It requires non-negotiable safety boundaries. An agent optimizing for energy efficiency cannot be allowed to violate a safety interlock, regardless of how the optimization function is weighted. The boundary belongs in the architecture — not in the prompt.

And it requires that the network the agent connects through is treated as a security perimeter, not a convenience. If the agent needs cloud connectivity, the path must be governed, monitored, and revocable. If the agent needs corporate network access, the segmentation that should have existed since the IIoT wave has to be retrofitted now before the agent becomes the route an attacker uses to reach the control layer.

None of this is exotic. None of it requires research-grade capability.

It requires the discipline to treat the agent as what it actually is a new operator with authority to act on physical systems through a network we never finished securing for the operators we already had.

Final Thought

There is a phrase I have started using in advisory conversations on this topic.

Autonomy without verifiability is negligence...Authority without accountability is the same thing, one level higher.

We are deploying agents into environments designed for humans, through networks designed for isolation that no longer exist, onto protocols that were never built to resist a malicious actor. The architecture that catches a human operator's mistakes does not catch an agent's. The network that protected the old plant does not protect the new one. The knowledge that backed up the operator is leaving the building.

The plants that will navigate this transition well are not the ones that deploy fastest. They are the ones that build the surrounding architecture first — and treat the agent as an operator with all the scrutiny that role has always required.

The plants that do not will eventually contribute case studies that the rest of us will read.

If you are deploying or planning to deploy agentic AI in your OT environment, two questions worth sitting with this week:

• If your agent took an unexpected action tonight, would you know within five minutes, be able to stop it within one, and be able to explain why it acted at all?
• And do you know every external path that connects to the system your agent is acting on?
• `And who would notice if one of them were compromised?

If any of those answers are unclear, the architecture is not ready.

I would like to hear what you are seeing in the field. Where are agents already acting in your environment? What governance is around them? What gap worries you most?