Agentic AI is not just another AI trend. It marks a fundamental shift — from AI that answers questions to AI that takes actions autonomously in complex environments. In industrial settings, this distinction carries real-world consequences. A system that can interpret a high-level production goal, decompose it into steps, issue commands to underlying systems, and adapt when conditions change is qualitatively different from a dashboard that flags anomalies for a human operator to investigate.

The implications for operational technology are significant. Industrial environments — factories, energy plants, water treatment facilities, refineries — are defined by real-time physical processes, safety constraints, and equipment that was often never designed with connectivity or intelligence in mind. Deploying agentic AI into these environments requires understanding both the technology's potential and the governance structure needed to keep it safe.

What Makes AI "Agentic"?

Traditional machine learning models perform a specific task: classify this image, predict this value, detect this anomaly. They are reactive and narrow. Agentic AI is different in kind. An agentic system combines a large language model (or equivalent reasoning engine) with planning capability, tool access, and memory — enabling it to pursue multi-step goals over time.

In practical terms, an agentic AI system in an industrial context can:

This is not a chatbot that helps an operator search a manual. It is a system that can observe, decide, and act — with or without a human in the loop at each step, depending on how it is configured.

Where Agentic AI Applies in OT

The Purdue Model — the industry-standard framework for OT network architecture — provides a useful lens for understanding where different types of agentic AI belong in an industrial stack. Each level of the model has different latency requirements, safety implications, and tolerance for uncertainty in the outputs that drive it.

Diagram 1 — Agentic AI Applications Across the Purdue Model
graph TD subgraph L45["Levels 4–5 · Enterprise & Cloud"] E1[LLM Orchestration & Multi-Agent Coordination] E2[Work Order & Procurement Automation] E3[Cross-Site Production Analytics] end subgraph L3["Level 3 · Site Operations"] S1[Historian Analysis & Predictive Maintenance] S2[Production Scheduling Optimisation] S3[Anomaly Trend Correlation] end subgraph L2["Level 2 · SCADA / HMI"] C1[Real-Time Process Optimisation] C2[SCADA Integration & Alert Management] end subgraph L01["Levels 0–1 · Field & Control"] F1[Edge AI: Local Anomaly Detection] F2[Deterministic ML on PLCs & Controllers] end L45 -->|"Orchestrates & plans"| L3 L3 -->|"Feeds insights"| L2 L2 -->|"Supervised signals"| L01 style L45 fill:#fff7ed,color:#7c2d12,stroke:#f97316 style L3 fill:#eff6ff,color:#1e3a5f,stroke:#1e3a5f style L2 fill:#eef2ff,color:#1e3a5f,stroke:#4338ca style L01 fill:#f0fdf4,color:#14532d,stroke:#16a34a style E1 fill:#ffedd5,color:#7c2d12,stroke:#f97316 style E2 fill:#ffedd5,color:#7c2d12,stroke:#f97316 style E3 fill:#ffedd5,color:#7c2d12,stroke:#f97316 style S1 fill:#dbeafe,color:#1e3a5f,stroke:#3b82f6 style S2 fill:#dbeafe,color:#1e3a5f,stroke:#3b82f6 style S3 fill:#dbeafe,color:#1e3a5f,stroke:#3b82f6 style C1 fill:#e0e7ff,color:#1e3a5f,stroke:#6366f1 style C2 fill:#e0e7ff,color:#1e3a5f,stroke:#6366f1 style F1 fill:#dcfce7,color:#14532d,stroke:#22c55e style F2 fill:#dcfce7,color:#14532d,stroke:#22c55e

At Levels 0–1 (field devices and basic control), AI must be deterministic, validated, and bounded. Edge models running on PLCs and controllers can detect local anomalies and generate immediate alerts, but they do not plan or reason — they execute validated logic at machine speed. At Level 2 (SCADA and HMI), AI assists with real-time process optimisation and alert management, with human oversight remaining central. At Level 3 (site operations), AI has access to historian data and can run predictive maintenance models and trend analysis. At Levels 4–5 (enterprise systems), LLM-based orchestration becomes appropriate — generating work orders, coordinating procurement, and running complex cross-site analysis.

Real-World Capabilities: What Has Already Worked

The CodeReAct framework — a pattern that embeds executable code within a thought-action-observation loop — has been deployed in data centre environments with directly applicable lessons for industrial OT. In this architecture, an AI agent analyses alerts from pumps, chillers, and compressors by interleaving reasoning steps with tool calls: querying sensor histories, running diagnostic calculations, and proposing remediation actions. The result in documented deployments was 25–40% faster diagnostics and a measurable reduction in unplanned downtime events.

This pattern is directly transferable to industrial OT. An agent that can reason over historian data, query SCADA APIs, cross-reference equipment specifications, and generate a structured maintenance recommendation — without requiring an engineer to pull data from five different systems — represents a genuine productivity gain that does not require autonomous physical action to deliver value.

Edge AI vs. Cloud AI: The Deployment Split

The most important architectural decision in industrial agentic AI is the boundary between edge and cloud. This boundary is not just technical — it is a safety and governance boundary.

Diagram 2 — Edge vs. Cloud AI Deployment Split
flowchart LR subgraph Rule["Critical Rule"] RNode["Never use stochastic LLMs\nfor direct control at Levels 0 to 2"] end subgraph Edge["Edge Tier — Levels 0 to 3"] ENode["Lightweight pre-trained models\nDeterministic, bounded outputs\nNo cloud dependency required\nSub-millisecond response latency\nRuns on PLCs, edge compute, gateways"] end subgraph Cloud["Cloud Tier — Levels 4 to 5"] CNode["Complex LLM reasoning\nMulti-agent orchestration\nCross-site analysis\nWork order and ERP integration\nHigher latency acceptable"] end Rule -.->|"Governs boundary"| Edge Edge -->|"Validated alerts and signals"| Cloud Cloud -->|"Advisory outputs only\nhuman gate before action"| Edge style Rule fill:#fee2e2,color:#7f1d1d,stroke:#dc2626 style Edge fill:#f0fdf4,color:#14532d,stroke:#16a34a style Cloud fill:#fff7ed,color:#7c2d12,stroke:#f97316 style RNode fill:#fecaca,color:#7f1d1d,stroke:#dc2626 style ENode fill:#dcfce7,color:#14532d,stroke:#16a34a style CNode fill:#fff7ed,color:#7c2d12,stroke:#f97316

The edge tier handles everything that requires immediate, reliable, deterministic response: anomaly detection on sensor streams, local process supervision, safety interlock monitoring. These models are small, pre-trained, and validated before deployment. They do not "reason" in the LLM sense — they produce bounded outputs based on known-good logic.

The cloud or central tier handles complex multi-step reasoning, cross-site analysis, and integration with enterprise workflows. This is where LLM-based agents are appropriate — because their outputs are advisory, not directly controlling physical processes. A cloud AI agent that generates a maintenance work order is not issuing a command to a pump. The work order goes through an existing approval and scheduling workflow. That distinction is fundamental.

The Agentic AI Architecture

A safe agentic AI deployment for OT follows a layered architecture that separates data collection, inference, action, and human oversight into distinct, controlled stages.

Diagram 3 — Agentic AI Loop for Industrial OT
flowchart TD OT["OT Data Sources\nHistorian · SCADA · Sensors · CMMS"] Norm["Data Normalization Layer\nOPC-UA · MQTT · Protocol Conversion"] Edge["Edge AI\nLocal Anomaly Detection · Immediate Alert"] Agent["Cloud LLM Agent\nPlan · Act · Observe Loop"] Tools["Tool Calls\nSCADA API · Historian Query · Work Order System · Email / Ticketing"] HITL["Human-in-the-Loop Review\nEngineer Approves or Rejects Recommended Action"] Action["Approved Action\nScheduled Maintenance · Parameter Adjustment · Procurement Request"] OT --> Norm Norm --> Edge Edge -->|"Validated signal"| Agent Agent --> Tools Tools -->|"Analysis result"| Agent Agent --> HITL HITL -->|"Approved"| Action HITL -->|"Rejected — agent re-plans"| Agent style OT fill:#f8fafc,color:#1e3a5f,stroke:#94a3b8 style Norm fill:#eff6ff,color:#1e3a5f,stroke:#1e3a5f style Edge fill:#f0fdf4,color:#14532d,stroke:#16a34a style Agent fill:#fff7ed,color:#7c2d12,stroke:#f97316,stroke-width:2px style Tools fill:#eef2ff,color:#1e3a5f,stroke:#4338ca style HITL fill:#fef9c3,color:#713f12,stroke:#ca8a04,stroke-width:2px style Action fill:#dcfce7,color:#14532d,stroke:#16a34a

This architecture makes the human gate explicit and structural — not an optional safeguard that can be bypassed when the system becomes more trusted over time. The agent can plan and call tools autonomously, but any output that affects a physical process or commits a resource goes through human review before execution.

CISA and NCSC Governance Framework

Both the US Cybersecurity and Infrastructure Security Agency (CISA) and the UK's National Cyber Security Centre (NCSC) have published guidance on AI in critical infrastructure. The core framework resolves into four principles that apply directly to industrial AI deployments.

Diagram 4 — Governance Framework for Agentic AI in OT
flowchart TD subgraph P1["1 · Understand AI"] U["Know the failure modes\nHallucination · Model drift · Adversarial inputs\nMap AI outputs to physical risk"] end subgraph P2["2 · Consider Use"] C["Define the business case\nAssess OT data security risks\nConfirm regulatory posture"] end subgraph P3["3 · Establish Governance"] G["Testing and evaluation protocols\nChange control for AI models\nRegulatory compliance mapping"] end subgraph P4["4 · Embed Safety and Security"] S["Human oversight at every control boundary\nTransparency of AI decisions\nValidation before autonomy is extended"] end P1 --> P2 --> P3 --> P4 style P1 fill:#eff6ff,color:#1e3a5f,stroke:#1e3a5f style P2 fill:#eef2ff,color:#1e3a5f,stroke:#4338ca style P3 fill:#fff7ed,color:#7c2d12,stroke:#1e3a5f style P4 fill:#f0fdf4,color:#14532d,stroke:#16a34a style U fill:#dbeafe,color:#1e3a5f,stroke:#3b82f6 style C fill:#e0e7ff,color:#1e3a5f,stroke:#6366f1 style G fill:#fef9c3,color:#713f12,stroke:#ca8a04 style S fill:#dcfce7,color:#14532d,stroke:#22c55e

Understand AI means developing genuine literacy about how AI systems fail — not just how they succeed. Hallucination (confident but incorrect outputs), model drift (performance degradation as the real world diverges from training data), and adversarial inputs (deliberate manipulation of AI behaviour) are all real risks in industrial deployments. AI literacy among the engineering leadership team responsible for OT is not optional.

Consider Use means applying the governance framework before deployment decisions are made, not after. Is the AI system being considered for a role where its outputs could affect physical processes? What are the data security implications of connecting OT historians to an AI platform? How does the deployment interact with NIS2, IEC 62443, or sector-specific obligations?

Establish Governance means creating the institutional structures that keep AI systems under control over time: change control processes for model updates, testing protocols before any AI model is promoted to production, and clear accountability for AI performance in the OT environment.

Embed Safety and Security means designing human oversight and validation into the architecture — not as a checkbox, but as a structural feature. Every AI output that can affect a physical process must have a review and approval step that a human can understand and act on.

The Human-in-the-Loop Imperative

The question of how much autonomy to extend to AI in industrial environments is the central deployment decision. A useful framework distinguishes three modes of operation:

Advisory mode: The AI observes, analyses, and recommends. A human engineer reviews the recommendation and decides whether to act. The AI has no ability to initiate action. This is the appropriate starting point for all new deployments.

Supervised automation: The AI can take certain actions autonomously within defined bounds — for example, adjusting a setpoint within a pre-approved range, or scheduling a maintenance notification. A human monitors and can override at any time. Appropriate for well-understood, low-consequence, reversible actions after the AI has demonstrated reliable performance in advisory mode.

Autonomous operation: The AI acts without per-action human approval. Appropriate only for a small class of actions that are: (a) well-defined with predictable outcomes, (b) reversible without human intervention, and (c) of sufficiently low consequence that errors can be recovered automatically. In most OT environments, very few actions meet all three criteria.

The progressive extension of AI autonomy should be driven by demonstrated reliability at the previous level — not by a predetermined schedule or by vendor assurances. Prove advisory performance first, then earn supervised autonomy, then evaluate autonomous operation on a case-by-case basis for specific, bounded actions.

Starting the First Deployment

The first agentic AI deployment in an OT environment should be narrow, observable, and advisory. A single well-defined use case — predictive maintenance on a specific class of equipment, for example — allows the organisation to build the data pipelines, validate the AI's analytical outputs against engineering expertise, and develop confidence in the system before expanding scope or autonomy.

The technical prerequisites are often underestimated. A reliable, normalised data feed from the relevant OT systems is non-negotiable. Most industrial operators have the data — but it is distributed across multiple historians, uses inconsistent tag naming, and has gaps and anomalies that must be addressed before an AI model can use it meaningfully. Expect the data engineering work to take as long as the AI model development.

The governance prerequisites are equally important. Who approves changes to the AI model? Who is accountable when the AI makes a wrong recommendation that an engineer acts on? What is the process for retraining the model when OT network topology or equipment configuration changes? These questions need answers before the first deployment — not after the first incident.