Reading a Machine Is Not Commanding One: Your AI Agent Wants Write Access to the Plant Floor

The demonstration always goes well.

An agent watches a line. It notices that a spindle is drawing more current than it did on the same part last month, correlates that against the tool-change log, and concludes that the tool is worn. It writes a clear, well-reasoned paragraph explaining this. Everyone in the room agrees the paragraph is correct.

Then someone asks the question that ends the meeting: fine — can it change the tool offset itself?

And the honest answer, in almost every case, is not "not yet, for safety reasons". The honest answer is that nobody in the room knows which wire the instruction would travel down, what the machine would say back, or whose name would be on it afterwards. The agent has been reading. Reading and commanding are not two settings of the same thing.

This article is about that gap, because 2026 has been the year the industry decided to cross it without measuring it first.

Write access assumed

Here is the diagnostic sentence, and it is worth keeping:

If nobody can name the transport the command leaves on, the cause code it comes back with, and the person whose name is on it — the agent does not have write access. It has a demo.

The failure mode is write access assumed. It shows up in roadmaps as a phase-two bullet, usually worded as "closing the loop" or "moving from insight to action", and it is costed as though it were a software feature. It is not a software feature. It is a different product, with a different regulatory surface, a different insurance conversation, and a different set of people who have to agree.

The argument of this article is not that agents should be kept away from machines. It is that the question of whether software may operate equipment was settled long before anyone said "agent" — and the settlement is not a yes or a no. It is a structure. The structure has clause numbers. Most of what the AI industry is currently inventing is a worse version of something already written down.

The argument is a century late

Process industry did not agonise over whether software should be permitted to move a valve. It built a layered answer and then standardised it.

The layers have names. In ISA-95 and IEC 62264 — the Purdue model, in conversation — Level 0 is the process itself, the valves and drives and motors. Level 1 senses and manipulates: this is the PLC, the thing that actually runs the machine. Level 2 is supervisory: screens, alarm servers, the operator's window onto the plant. Level 3 is site operations, where production management lives. Level 3.5 is the IT/OT boundary. Level 4 is the business.

Commands travel down. They do not teleport. An instruction originating at Level 3 or from anything cloud-shaped crosses the customer's Level 3.5 boundary and reaches the physical world only through the PLC, which is entitled to refuse it.

Alongside all of that, and deliberately not part of it, sits the safety system. IEC 61511 is explicit about the separation: the basic process control system and the safety instrumented system "shall be designed to be separate and independent to the extent that the functional integrity of the SIS is not compromised." Independent means independent. The safety system is certified, it is someone else's, and it always wins.

There is a number attached to this that deserves more attention than it gets. Under IEC 61511, a control system that is not itself built to the standard may be credited with a risk reduction of at most a factor of ten. That is the ceiling on how much safety credit ordinary control software is permitted to claim. An agent is ordinary control software. It does not get a better number for being clever.

So the correct frame for "should the agent be allowed to act" is not a philosophical one. It is: which layer is it sitting in, what is the layer below entitled to refuse, and which certified thing overrides both.

Claim one: reading and commanding are different products

Consider what changes the moment software is permitted to send rather than receive.

When a system reads, a wrong answer produces a wrong screen. Someone notices, or does not. The cost is measured in bad decisions and lost confidence. When a system writes, a wrong answer produces a moved actuator. The cost is measured in scrap, in an unplanned stop, in a damaged spindle, and — in the case everyone is careful not to say out loud — in someone standing near the machine when it starts.

That difference propagates outward into things that are not engineering at all.

It changes the legal surface. The EU Machinery Regulation 2023/1230, which applies from January 2027, addresses connected devices directly in Annex III. Connecting another device, or any remote device that communicates with the machinery, must not lead to a hazardous situation. Safety-critical software and data must be protected against corruption. And the machine "shall collect evidence of a legitimate or illegitimate intervention" — with a tracing log kept for five years. The regulation binds the machine manufacturer, not the software vendor. But the manufacturer will have views about what you have connected to their machine, and the five-year log is a question your customer will eventually ask you to answer.

It changes the workforce surface, and in Germany it changes it sharply. A per-person record of who commanded what is, almost certainly, co-determined under BetrVG §87(1) Nr. 6, which covers technical equipment "bestimmt …, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen". The case law is unkind to the obvious workaround: it is enough that the system is objectively suitable for monitoring behaviour or performance. Intent is not the test. So the same audit trail that your safety investigation depends on is the artefact your works council has a say over, and those two requirements arrive from opposite directions and have to be reconciled by someone.

And it changes the insurance and liability surface in ways that are nobody's favourite slide.

None of this is an argument against command capability. It is an argument that "we'll add write in phase two" is not a sentence about software.

Claim two: every guardrail being invented already has a clause number

The most striking thing about reading the 2026 agentic-AI literature next to the industrial control standards is how much of it is rediscovery.

The AI world has converged, this year, on a boundary: agents may investigate freely, but a human approves anything that mutates production. It is presented as a hard-won insight about autonomy. It is, more or less exactly, select-before-operate — a pattern standardised in IEC 61850, present in DNP3, and present in IEC 60870-5-104 as select-then-execute, answered by a positive or negative confirmation. It has a timeout. It has a termination step. Selecting a device reserves it, so a second, conflicting command is refused rather than interleaved.

The AI world talks about "guardrail agents" that block high-risk actions and escalate them. Industrial control calls this dual approval, it is a requirement in IEC 62443-3-3, and the supervisory suites have shipped it for twenty years under names like verified write: one person performs, a second person signs, and — this is the part usually lost in translation — the second person is permitted to reject. They are not countersigning. They are deciding.

The AI world discusses "confidence thresholds" and what the agent should do when it is unsure. Industrial control asks a blunter question: is the data any good? NAMUR NE 107 gives field devices four status signals — Failure, Function check, Out of specification, Maintenance required. A reading from a device in Failure or Function check must not justify a command, regardless of how confident anything downstream feels about it. Protocols carry this too: OPC UA's status codes are Good, Uncertain and Bad, where Bad means specifically "not usable", and sourceTimestamp is set as close to the source as possible so that staleness is measurable rather than assumed.

And the AI world's weakest area — what happens when the action is refused — is where industrial control is strongest.

This is the detail I would most like readers to take away, because it is small and it is decisive. In mature industrial protocols, a refusal is enumerated. IEC 61850 carries a fixed list of causes: Blocked-by-interlocking. Blocked-by-mode. Blocked-by-process. Blocked-by-health. Command-already-in-execution. Locked-by-other-client. No-access-authority. Time-limit-over. Abortion-by-communication-loss. DNP3 has its own: TIMEOUT, LOCAL, NOT_AUTHORIZED, ALREADY_ACTIVE, AUTOMATION_INHIBIT.

A refusal from a fixed list can be counted, alarmed on, trended and argued with. A free-text refusal, or worse a silent no-op, cannot. Ask any vendor pitching an agent what their refusal vocabulary is. If the answer is a string, the loop is not closed; it is open and painted.

Then there is feedback. A command is not finished when it is sent. The mature pattern is a read-back with a timer: the symbol shows "in progress" until the machine's own state confirms the change, and if confirmation does not arrive inside a per-equipment timeout, that is a disagreement, and a disagreement is an alarm. Note what does not happen here — the supervisory system does not drive the equipment somewhere safe. Moving to a neutral position on failure is the PLC's job. The layer above raises its hand and says the plant did not agree with me.

Claim three: the binding constraint is the last metre

Here is the fact that collapses more agentic roadmaps than any other, and it fits in one sentence from a public specification.

MTConnect — the protocol a very large share of connected machine tools speak, and the one behind an enormous amount of the shop-floor data currently being fed to models — says this in Part 1, version 2.2, section 5.1:

"the API is read-only and does not produce any side effects on the agent or the equipment."

Read-only. Not "read-only by default", not "read-only unless configured". A machine reachable only over MTConnect cannot be commanded through it at all. Not by a person, not by an agent, not by the best model ever trained.

Commanding such a machine requires a second channel — OPC UA, a vendor API, a direct path to the PLC — with its own authentication, its own permissions, its own network exposure and its own conversation with whoever holds the machine's warranty. That is a separate integration, separately scoped, separately paid for, and frequently separately refused by the machine builder.

This is what I mean by the last metre. Everything upstream of it — the model, the reasoning, the orchestration, the beautifully argued paragraph about the worn tool — is the easy half, and it is the half that demos. The last metre is a per-machine, per-protocol, per-contract question, and the answer for any given machine on any given floor is often simply no.

Even where a write path exists, it is narrower than people expect. OPC UA does not offer a machine as a single yes-or-no. UserAccessLevel and UserWriteMask narrow write rights per user and per node. The service errors are specific — Bad_UserAccessDenied is a different problem from Bad_NotExecutable, and an agent that collapses them into "failed" has thrown away the only information that would tell an engineer which of the two to go and fix. The standard also requires that a Write which changes system state "shall generate an audit event", which means the audit trail is not an optional extra you bolt on; it is part of the protocol's contract.

And above all of it sits a piece of hardware that no software negotiates with. The selector at the machine. Set to Local, the machine takes instructions from the person standing in front of it and from nobody else — and in a properly built system the remote screen does not fail mysteriously, it greys the control out and says why, because the refusal has a name.

The German sources are the clearest, and they are not about AI

The best public writing on how remote commands should behave was not produced by the AI industry, and it does not mention agents anywhere. It is German, it is about Fernwartung, and it has been sitting there since 2023.

DGUV FBHM-133, Sichere Fernwartung von Maschinen, published 31 July 2023, states the hierarchy without hedging:

"Not-Halt und Sicherheitsfunktionen haben stets Vorrang vor Fernwartungs-Befehlen."

Emergency stop and safety functions always take precedence over remote commands. Always. And the corollary, which is the sentence every agentic-AI roadmap should be measured against:

"Das Aussetzen oder Rücksetzen von Sicherheitsfunktionen … darf nicht aus der Ferne möglich sein."

Suspending or resetting a safety function must not be possible remotely. Not "should be restricted". Must not be possible.

The rest of the document reads like a specification somebody should have handed to the agent vendors. Commands that could cause an unexpected hazard for a person on site — the example given is starting a drive — "sollten technisch unterbunden werden": they should be technically prevented, not merely discouraged by policy. A remote session is initiated from the operator's side and confirmed at the machine, which means a human on the floor consents before anything remote happens. Accounts are personal, because an action performed by a shared service account cannot be investigated. Logs are kept centrally and out of the remote party's reach — an audit trail the acting party can edit is not an audit trail. Sessions are time-limited. And the machine itself visibly shows that remote access is active, so nobody walks up to it uninformed.

Read that list again as a checklist for an autonomous agent and notice how much of it is unmet by current practice.

Alongside it sit the five safety rules, from DIN VDE 0105-100 and DGUV Vorschrift 3, in their fixed order: Freischalten. Gegen Wiedereinschalten sichern. Spannungsfreiheit feststellen. Erden und Kurzschließen. Benachbarte, unter Spannung stehende Teile abdecken oder abschranken. Isolate, secure against re-energisation, verify dead, earth and short, cover adjacent live parts.

Software stands in for none of them. The US formulation of the same principle is blunter and worth quoting to anyone who needs convincing quickly — OSHA 29 CFR 1910.147: "Push buttons, selector switches and other control circuit type devices are not energy isolating devices."

A software "off" is not a lockout. It has never been a lockout. A screen may show a lockout that was recorded elsewhere by a qualified person; it does not create one and it cannot clear one. Any product that lets a remote instruction re-energise equipment that someone has isolated for work is not a product with a bug. It is a fundamentally different and much worse thing.

What an agent inherits the moment it speaks

There is one more body of rules that arrives unannounced, and it catches teams late: if your agent raises alarms, it has joined a discipline with published performance targets.

ISA-18.2 and IEC 62682 define an alarm as something indicating a condition requiring a response — that qualifier is the whole standard in three words. The targets, non-mandatory but widely used, are specific: roughly one to two alarms per ten minutes per operator; fewer than five stale alarms — active for over 24 hours — on any given day; and zero chattering alarms.

Now consider an anomaly-detection agent watching a few hundred signals and surfacing everything it finds interesting. Against these numbers, an enthusiastic agent is not an improvement to the alarm system. It is an alarm flood with a language model attached, and the operator response to an alarm flood is well documented and always the same: people stop reading them.

The mature distinction is that command outcomes are events, and only a failed or disagreeing command is an alarm. Everything the agent notices is an event until something requires a person to do something. Most agent deployments have no such distinction, which is why their second month is quieter than their first — not because there is less happening, but because someone turned the notifications off.

Six questions to ask before anything is allowed to write

This is the part to take into your next vendor conversation, or your own architecture review. None of these questions is about the model.

1. Which transport would the command physically leave on — and is that transport read-only? If the honest answer is MTConnect, the answer to everything downstream is no, and that is a scoping fact, not a defeat.
2. When the machine refuses, what cause code comes back — from a fixed list, or free text? A refusal you cannot count is a refusal you cannot manage.
3. Whose name is on the command, and can that person edit the log that records it? A service account is not a name. An editable log is not a log.
4. What is the feedback timeout, and what does the screen show while the command is in flight? If there is no timer, there is no disagreement detection, and a command that quietly did nothing looks exactly like a command that worked.
5. Which actions require a second person, and who signed off that list? The list is per operation on the equipment, not per screen — and it should be signed by the customer's own control engineer, because only they know what this valve does on this plant.
6. If the selector at the machine is set to Local, does the software know — and does it say so? Silent failure at the last metre is how trust in a system ends.

The honest position

The move from monitoring to autonomy is real, and it is not hype. But it is being described as a capability question — can the agent decide well enough? — when it is almost entirely a permission and evidence question. Can it prove who asked, prove what the plant answered, prove that the safety layer was never in its path, and prove all of that to a works council, an insurer and eventually a regulator.

The industry that runs refineries and power systems worked this out and wrote it down, in documents with clause numbers, decades before anyone trained a transformer. The fastest route to an agent that is genuinely allowed to act is not a better model. It is reading what is already binding, and building the boring parts first: the enumerated refusal, the feedback timer, the personal account, the log nobody can edit, and the switch at the machine that beats everything.

The plants that get this right will not be the ones with the most autonomous agents. They will be the ones that can answer, for any command in the last twelve months, who asked and what the plant said back.