Architecture for Industrial AI Agents

1. The objective

An industrial AI agent is software that monitors a production line and does tasks with the systems on that line. A long-term agent operates for days or weeks, starting tasks when conditions on the line change and examining problems with the same data and tools that an engineer would use.

To do this work, an agent needs three capabilities:

• Full context: data from the historian, MES records, maintenance history, and the PLC logic itself.
• Tools: the ability to read from systems, run analyses, and eventually change the process.
• Memory: information that carries from one shift to the next and survives a restart.

The value of these agents is significant. When the bottleneck process stops, the whole plant’s output stops with it. An agent can begin examining the cause immediately, at any hour.

At Nexus, we build agents for manufacturing operations. This white paper shares what we’ve learned about each part of the system.

2. Current technology: sandboxes and policy controls

In the software industry, agents run in sandboxes, which are isolated computer environments dedicated to a single agent. Current sandbox systems have two layers: isolation and policy.

Isolation layer. Each agent receives a temporary, isolated computer. Hosted services such as E2B, Daytona, Modal, and Amazon Bedrock AgentCore offer cloud sandboxes to agent developers. Most are designed for tasks lasting minutes to hours.

Policy layer. This layer controls which actions an agent can take, using rules enforced outside the model. In October 2026, AWS released Strands Box (opens in a new tab) as a developer preview. It combines operating-system isolation with policies that consider the agent’s previous actions. In an example from AWS (opens in a new tab), an agent can post incident updates to Slack no more than three times in ten minutes.

Cloud sandbox systems rely on three assumptions:

1. The tools are on the internet.
2. The sandbox can connect to the tools.
3. An operator can reverse an incorrect action.

At Nexus, we talk to industrial operators on a regular basis. It’s clear that in plants, none of these assumptions hold. Therefore, Agents deployed in industrial environments need to take into account several key differences:

3. Differences in operational technology (OT)

Plant networks are built in layers, described by the Purdue model and the IEC 62443 standard. Controllers, HMIs, and SCADA systems sit in the lowest layers, isolated from the business IT network by a demilitarized zone (DMZ). The network is designed to block incoming connections from the internet to the control layers.

Many plants already send historian data to the cloud through outgoing-only connections. Data can leave the plant, but the tools an agent uses must stay. Five conditions set OT apart from software environments:

• Tools exist only on site. OPC UA servers, Modbus and EtherNet/IP devices, PLC programming software, and MES transactions all run on the plant network. Connecting them to a cloud sandbox would require new paths through the network isolation, which increases the attack surface.
• Actions have physical consequences. An incorrect action can scrap a batch, stop a line, or injure someone. These results are often irreversible. Plants manage this risk with management of change (MOC), approved operating limits, and safety systems kept separate from the control system.
• Much of the equipment is old. Many HMIs are 20 or more years old. Some protocols have no authentication, and some controllers stop when a network scan sends them too much traffic.
• Plants run 24 hours a day. Production continues when the wide area network (WAN) connection fails. Agents need to keep working, or fail safely, when the internet connection drops.
• Process data is sensitive. Recipes, setpoints, and yields are valuable intellectual property. Every prompt sent to a model carries some of this data.

Plant security teams evaluate every new system against these five conditions; at Nexus, we designed our platform around them from the start.

4. Areas of focus for system designers

Large Language Models often run in the cloud to take advantage of large data centers, but it is possible for the sandboxes, agent lifecycle, triggers, data, and tools to stay firmly within the plant network. Using this architecture, a plant can use AI agents without adding a new path into the control network. The following eight design rules make this possible.

Data goes up in one direction; changes go down only through SCADA

1. Install the orchestration layer at the right network level. Run the sandboxes, agent lifecycle management, triggers, and integrations on site infrastructure that IT already manages, such as a VM or a Kubernetes cluster at Level 3 or in the DMZ. At Nexus, our platform can run out of the box on a customer VM or Kubernetes cluster at the site.
2. Send OT data one way to a site database. Data should flow up from OT through diode-like paths into a time-series database at Level 3, such as TimescaleDB. Agents can then read from this database, which gives them the full process history and adds no load to older controllers. Our platform includes an OT monitor that enforces these one-way data flows.
3. Write changes only through existing control paths, with human approval. Route changes through the SCADA paths operators already use. Each change then passes through the existing alarms, interlocks, and records. Expand the agent’s permissions in steps: read, recommend, write after approval, and finally write within an approved operating range. Our platform is read-only by default, and customers can enable writes through existing SCADA paths with human approval. Operators stay in control, and the plant keeps its existing safety layers.
4. Enforce policies outside the model. Use fixed rules that the model cannot change, such as “no more than two setpoint changes per hour” or “no writes during startup.” Treat all input data as potentially dangerous. A work order, vendor manual, or email can contain hidden instructions for the agent; this attack is known as prompt injection.
5. Keep secrets out of the sandbox. A credential broker attaches credentials to approved requests. Give each agent its own identity with only the permissions it needs.
6. Control what data reaches the model. For a cloud model, use outgoing-only connections to specified endpoints, and ensure you understand your provider’s data retention policy. Alternatively, open-weight models such as GLM-5.3 or DeepSeek V4 can run with no internet connection at all. With several hundred billion to 1.6 trillion parameters, they need a multi-GPU server, usually in a corporate data center.
7. Design for unreliable infrastructure. Agents should save their progress at regular intervals and resume after a reboot or a WAN failure. If the model becomes unavailable, agents should fall back to read-only alerts while the plant keeps running.
8. Record every action and update the software safely. Keep a permanent record of every observation, tool call, and approval. This record supports MOC processes and validated environments such as 21 CFR Part 11. Download signed updates through outgoing-only connections, with a software bill of materials (SBOM).

5. Questions from your security team

Before a pilot starts, any vendor deploying agents near OT should answer these questions clearly. We encourage plants to ask every vendor these questions, including us.

Question	Satisfactory answer
Does the system create a new connection path between IT and OT?	No. Data moves up in one direction only. Every write uses an existing SCADA path with human approval.
Does the agent send traffic to our controllers?	No. Agents read from a time-series database at Level 3. Only approved changes travel through SCADA.
Could a hidden instruction in input data change a controller?	No. The agent has no direct write path. Every write must pass fixed policy rules and human approval.
What data leaves our network?	Only prompts to the model, sent to a specified endpoint under a data retention policy you have reviewed. With a local model, nothing leaves.
What happens if the internet connection fails?	The agents pause or fall back to alerts only. The control system never depended on them, so it keeps running.
Who operates, updates, and audits the system?	It runs on your VM or cluster under your change control process. It keeps a full record of every action.
Can we shut the system off?	Yes, with a single switch. Read-only is the default mode.

6. Conclusion

Long-term AI agents can bring real value to plant operations when their architecture respects how plants are built and secured. Keep the orchestration layer, data, and tools on site. Use one-way data flows, and require human approval for every change. With that architecture, a plant can adopt agents and keep its current security model. To see how we apply it at Nexus, visit getnexus.ai.