Describing a situation is one thing. Acting on it safely is another. The distance between the two is where most applied AI quietly stops, because in the physical world a wrong action has a real cost.
Every field session we publish ends in the same place. The engine reads the control logic, traces the dependency, names the bit that governs the thing, and then hands the decision to an engineer who makes the change. Writes by the engine: zero, in every study on this site. That boundary is deliberate, and the point of our Autonomy and Execution research is not to find a clever way around it. It is to work out what would have to be true around an action before an operator should let a system take it.
Being wrong about advice costs attention
A system that advises has a forgiving error profile. Bad advice gets read, judged, and discarded, and the cost is a minute of someone's day. That forgiveness is why advisory AI spread so fast: a person stands between the output and the world.
Acting removes that person, and the physical world does not offer a general undo. What that actually looks like is easiest to see in a change that was handled carefully. In the decommissioned lane study, an engineer wanted a retired sortation lane to show as not enabled, and asked for the least invasive option that would get there. Four options existed, and the useful work was ranking them by reach: an operator zone stop that reverses instantly but re-seals on the next area start, disabling the two zone enable bits, an online edit adding a maintained interlock, and a module inhibit that produces comms faults instead of the requested state and can take out neighbors sharing the roller gateway and network master.
One goal, four blast radii, in ascending order of what you cannot undo in a hurry. Recommending the wrong one of those costs a conversation. Taking the wrong one costs equipment that was never part of the request.
The question an engineer asks before anything changes
It is always the same question, and it is never about the model. It is "are you sure this will not hit anything else."
The four-lane OEE study is the cleanest example of why that question is load bearing. The obvious lever looked like the zone enable bit. A complete cross-reference on it came back with references across two routines, most of them driving the roller zone instructions for the whole merge zone, plus a fifth reporting lane nobody in the conversation had mentioned. The finding that mattered was not the switch to use. It was the switch not to touch, and it was only visible because the reference list came back untruncated.
That is the shape of the evidence an acting system needs. Not a confidence score, and not a sample of references that looked representative. A complete enumeration of everything the change reaches, in a form the engineer can re-run in their own editor before they believe it.
Acting changes the evidence you are reading
Here is the property that separates acting from advising most sharply, and it gets discussed the least.
An advisory system reads a world that is only being changed by other people. A system that acts is changing the world it is about to read next, and the side effects of its own actions land in its own evidence.
The palletizer stop is a five hour demonstration of this. The operator cycled the controller mode to diagnose the first root cause, which was correct and which worked. That mode cycle also fired a first-scan rung that conservatively assumes every pallet position is full, because after a restart the controller cannot know what is stacked on a pallet and must never place onto an unknown build. Good design, working exactly as intended. It also armed the second root cause, and nobody noticed for thirty-eight minutes, because nothing in the cell reads out pallet counts until moves start succeeding again.
A human made that change and a human missed the consequence. An autonomous system would have to do better on both counts: predict which of its own diagnostic actions perturb state, and re-read the perturbed state rather than the state it remembers. That is a harder requirement than accuracy, and no benchmark asks for it.
What would have to be true to cross
From the field work so far, the list keeps coming back the same, and none of it is about model confidence.
- The blast radius is established from a complete enumeration, not a sample, and the enumeration is reproducible by the person responsible for the area.
- Reversibility is ranked before the action rather than discovered after it, so the least invasive option that achieves the goal is the one taken.
- The action is verified afterward against the same source that justified it. In the decommissioned lane, the engineer disabled both bits and confirmed every listed unit turned solid grey, which is the requested state and also the receipt.
- The system models the effect of its own action on the state it will read next, and re-reads rather than assuming.
- Every action leaves a record of what was done, when, and on what basis, cited to the logic that justified it.
Autonomy an operator can stand behind comes from the verification and accountability around the action, not from the confidence of the model taking it.
Where a first crossing should be studied
You do not learn anything safe by handing a system a wide, irreversible action space and watching. The place to study this is where the action is narrow, reversible on a timescale a person can tolerate, and verifiable immediately against the same evidence that justified it.
The published field work points at what that looks like. A change like disabling two zone enable bits has the right properties: it is surgical, it is reversible by re-enabling them, it leaves I/O and safety live so nothing propagates outward, and the requested end state is directly observable within seconds. A module inhibit has none of those properties. The gap between those two options is not a difference in difficulty. It is the difference between a change you can study and a change you can only regret.
We are not doing that crossing yet, and it would be easy to write a paragraph implying otherwise. What we have instead is several sessions' worth of evidence about what engineers demand before they act, gathered from a read-only position, which is a reasonable place to be early.
Where we actually are
Nexus reads. On premise, air gap capable, read-only in every field session published here, with the engineer making every change. That is the correct boundary for a running plant today, and it means the loop closes on a person rather than on the tool.
Forge is the research into what crossing would take, and it is in development rather than shipping. We are not going to pretend otherwise or attach a date to it. Names and shapes will change; the questions will not.
The near-term work is less romantic than autonomy and more useful. It is making the pre-action evidence complete enough that a human decision is fast and well founded, which is what evaluating a system that acts actually measures, and what the engineering around unreliable inputs has to hold up under. The frontier is not a system that acts as widely as possible. It is a system that acts exactly as far as its evidence justifies, and is honest about where that line sits.