Agentic AI is more than a chatbot with buttons
An AI agent differs from a conventional chatbot because it can decide which tools to use, perform multiple steps and maintain enough state to pursue a task. In an office environment that may mean reading a document, querying a database and preparing a report. In a factory, those same capabilities raise an important question: what happens when the tool the agent controls is a production system?
OT engineers are right to be cautious here. A manufacturing system is full of commands that look technically simple but have physical consequences. A request to write a PLC variable, acknowledge an alarm, restart a service or alter a recipe parameter is not just an API call. The system needs context, authority, validation and a clear audit trail.
Observation is the easiest place to begin
The safest early use of an OT agent is read-only observation. The agent can search documentation, query historical data, compare alarm sequences, inspect system status and assemble a diagnostic report.
For example, an engineer could ask why a packaging line experienced repeated stops during the last shift. The agent could retrieve the alarm history, identify the dominant states, correlate stops with upstream equipment and produce a timeline. Nothing needs to be written back to the control system.
This looks less spectacular than a fully autonomous “AI factory,” but it creates a useful engineering feedback loop. The team learns whether the agent can interpret the data before granting it more authority.
The three boundaries of an industrial agent
A useful architecture separates observation, decision support and execution.
Observation is about reading trustworthy state. Decision support is about proposing an action, explanation or next step. Execution is the point where a command is actually issued.
These boundaries should be visible in both software and governance. An agent may be allowed to call a historian query without requiring the same permission needed to change a setpoint. A technician may approve one class of action while a production engineer approves another.
Why direct PLC control is usually the wrong starting point
LLMs are designed to generate plausible sequences of language. That is not the same as guaranteeing a correct sequence of control operations. Even with tool constraints, the system has to cope with stale state, unexpected conditions and incomplete context.
Consider a simple request: “Restart the machine if the fault is recoverable.” Human engineers know that this sentence hides several conditions. Is the machine in a safe state? Is the downstream conveyor clear? Has the fault occurred repeatedly? Is a technician currently working on the cell? Has the maintenance lockout procedure been completed?
An agent should not be expected to infer these conditions from a natural-language request. They need to be represented explicitly by the application and existing safety/permission mechanisms.
A better pattern: agent outside, controls inside
A sensible pattern is to place the agent at the orchestration layer and expose narrow, typed tools. Instead of giving the model arbitrary database credentials or unrestricted HTTP access, expose functions such as get_active_alarms(), get_equipment_state(), find_procedure() or create_maintenance_draft().
Each tool should validate its own inputs and permissions. The model decides which tool might help, but the tool remains responsible for enforcing the real rules.
This is the same engineering philosophy used elsewhere in automation: make invalid states difficult to reach. A constrained tool interface is the software equivalent of an interlock.
Auditability matters more than cleverness
Industrial agents should record what they observed, which tools they called, what information they used and which human approved an action. The system should be able to reconstruct the sequence later.
This is particularly important when the agent is involved in maintenance or quality workflows. A fluent explanation is not an audit trail. Engineers need timestamps, identifiers and source references.
Where agents make sense today
- Maintenance triage and work-order preparation.
- Engineering document retrieval and revision comparison.
- Alarm and event analysis.
- Shift-report generation from historian and MES data.
- Root-cause investigation support.
- Change-request drafting and evidence gathering.
These use cases all benefit from orchestration while keeping final decisions with people or deterministic applications.
Design for partial failure
An industrial agent should assume that tools fail. The historian may be unavailable. A document index may be stale. A network path may be disconnected. A data source may return incomplete results.
When that happens, the correct response is not to “try harder” by inventing missing information. It is to surface the missing evidence and stop at a defined boundary. Engineers already understand this concept from fault handling: degraded operation is safer when it is explicit.
The useful future for agentic AI in OT is therefore not maximum autonomy. It is controlled autonomy around tasks where the cost of human attention is high and the consequences of a wrong control decision are unacceptable. That is a much more interesting engineering problem.
Agents need a defined operating envelope
An industrial agent should have a written description of what it is allowed to observe, what it may recommend and which actions require human approval. This sounds like governance paperwork, but it is really system design. Without an operating envelope, every new integration changes the risk profile in ways the team may not notice.
Use stateful workflows carefully
Agents often maintain task state across several steps. That can be useful for investigations, but stale context is a real risk. A machine state captured ten minutes ago may no longer be valid. The tool layer should therefore make freshness explicit and re-read critical state before an action that depends on it.
Approval should be a real technical gate
If an agent proposes a maintenance action, the approval step should not be a cosmetic button. The system should bind the approval to the exact action, target asset and evidence used to produce the recommendation. This creates a clear audit trail and prevents a later change in context from being hidden behind an earlier approval.
Think about concurrency
Manufacturing systems can have several operators and services acting at once. An agent that reads a value and later writes a command may be working from stale assumptions. Optimistic locking, revalidation and explicit command states become important when autonomous workflows move closer to operational systems.
Where agentic behaviour has the most leverage
The strongest applications are usually cross-system tasks that are tedious for humans but low-risk when executed with narrow tools: collecting evidence for a failure review, comparing revisions, preparing a shift report or creating a structured maintenance draft. Those tasks benefit from orchestration while keeping the physical process under established control.