LADX
Start free
← Resources
AI·10 min read·

Agentic AI on the plant floor: what is actually running

Every vendor has announced one. A smaller number have deployed. Here is what is genuinely in production, and what the word is doing in those sentences.

Short answer

Engineering assistance is genuinely deployed and runtime autonomy is not. Siemens, Rockwell and Beckhoff all ship code assistants inside their engineering tools, with reported productivity gains of twenty to thirty percent concentrated in onboarding and documentation. None of them writes to a running controller, and the constraint is not technical but regulatory: safety cases are built on determinism and traceability.

The loop that makes it usableModel writesany providerCompiler answerspass / failYou read itonly if it passedfailures go back, with the errorsthis is what makes a free model good enough

The word moved fast. Two years ago the pitch was a copilot that suggests code. Now every major automation vendor describes something 'agentic', systems that pursue an outcome rather than answer a question. It is worth separating what has shipped from what has been announced.

What is genuinely deployed

Engineering assistance is real and in use. Siemens' Industrial Copilot generates structured text inside TIA Portal and has been taken up at scale by industrial customers. Rockwell's FactoryTalk Design Studio has a code assistant built on a purpose-trained small model rather than a general one. Beckhoff's TwinCAT assistant reports productivity gains in the twenty to thirty percent range, concentrated in onboarding and documentation.

Notice what those have in common: they all sit in the *engineering* environment, not the *runtime*. They help you write the program. None of them touches a running controller.

What 'agentic' currently means in practice

Mostly: multi-step, with tools, and allowed to retry. An agent that reads a fault code, searches the manual, checks the last three work orders and proposes a cause is doing something meaningfully more than autocomplete. It is also not making decisions about the machine; it is assembling context faster than a person could.

That is a real and useful capability, and the honest framing of it is 'a very fast technician who has read everything', not autonomy.

What is not happening, and probably should not

Closed-loop control by a language model. Nobody serious is proposing that a probabilistic system should write directly to a controller running a machine that can hurt somebody, and the regulatory picture would not permit it even if they were.

The interesting constraint is not technical. It is that safety cases are built on determinism and traceability, and 'the model decided' is not an answer that survives an audit.

The useful question for 2026 is not whether AI can drive a plant. It is which parts of an engineer's week are not engineering, such as documentation, translation between dialects, searching manuals and writing the same interlock for the ninth time, and how much of that can be given away safely.

The constraint most vendors do not talk about

Most OT networks do not have internet access, and that is not an oversight. A cloud assistant is unavailable in exactly the environment where the work happens, which is why the deployments you read about are usually in the engineering office rather than on the line.

This is the strongest argument for local models in industry, and the reason it matters more here than in most software: air-gapped is not a paranoid preference, it is the default condition of the network.

Common questions

Do industrial AI copilots write directly to PLCs?
No. Every shipping vendor assistant sits in the engineering environment and helps write the program; none writes to a running controller. The blocker is not capability but accountability: a safety case requires determinism and traceability, and 'the model decided' does not survive an audit.
What productivity gains do industrial AI copilots actually deliver?
Vendors report twenty to thirty percent in pilot deployments, concentrated in onboarding to unfamiliar codebases, documentation and maintenance work rather than in writing new logic. The gains are real and they are in the tasks around engineering rather than in engineering itself.

Keep reading