Physical AI is the phrase the industry has settled on for AI that perceives the world, reasons about it, and acts on it. NVIDIA uses it for robots and autonomous machines. The demos are humanoids folding laundry and warehouse arms picking totes. That is one end of it, and the models behind it are moving fast. But most of the physical world that a business runs on is not a robot. It is a fridge, a compressor, a truck, a pump, a door sensor, a building management system. Those things already have sensors and actuators, and nobody is looking at them well.
This article is about that second kind of physical AI: an agent that watches the sensors, knows the procedures, fixes what it safely can, and asks a person before it touches anything. We built one for a cold chain and measured it. The pattern is more general than the demo.
Two loops, two timescales
Physical systems run on layered loops, and the layering matters more than any model choice.
At the bottom is the control loop. A PLC holds a compressor setpoint, a motor controller keeps a conveyor at speed, a robot controller drives joints. These loops run at hundreds or thousands of hertz, are certified, and must never wait on a network call to a language model. Vision-language-action models are pushing into this layer. OpenVLA runs at roughly 6 hertz on a desktop GPU, pi0 uses action chunking to reach 50 hertz, and Gemini Robotics On-Device and GR00T target on-robot hardware. That is real progress, and it is not where enterprise operations are today.
Above it is the supervisory loop. Someone reads the alarms, decides what they mean, follows a procedure, and dispatches people or work orders. That loop runs in minutes. It is staffed by a duty manager with a dashboard and a phone, or it is not staffed at all overnight. It is where the money is lost: the compressor that failed at 2 a.m. and was found at 7, the reefer that ran warm for three hours because the alert went to an inbox.
The supervisory loop is a language problem. The inputs are readings, alarms, and procedures written in prose. The outputs are tickets, calls, holds, and reroutes. It tolerates latency of seconds to minutes. It is exactly the shape of work a language model agent is good at, and it needs none of the real-time guarantees that make robot control hard.
What the agent has to be
An agent in this layer needs four things, and each one is an ordinary platform feature rather than a research problem.
The world as tools. Every sensor read and every actuator write is a tool call with a typed input and a logged result. We expose the physical system as an MCP server: get_overview, list_alerts, get_fridge, hold_order, lock_fridge, reroute_truck, create_ticket, page_engineer. The server is the boundary. It is where you put rate limits, allow lists, and an audit log with the agent's thread id on every write. The model never talks to a device. It talks to a server that talks to a device, and that server is code you control.
Procedures as knowledge. Operations already have SOPs: temperature bands, excursion limits, escalation ladders, what to do in a power cut. Put them in a knowledge base and the agent retrieves the relevant one for each situation instead of carrying a thousand-line prompt. When a procedure changes, the document changes, not the agent.
A pause. The agent needs a tool that stops the run, records a question, and resumes from the same state when a human answers. Without it the only safe agent is one that cannot act, and the only capable agent is one you cannot trust. With it you can draw a line through the action list and put the physical side behind a question.
A schedule and a trace. The agent runs every hour, or every ten minutes, without being asked, and every run is a trace you can replay: what it read, what it retrieved, what it called, what it asked. In a regulated facility, the trace is the record.
The escalation ladder
The design decision that makes this workable is a ladder. We wrote the cold-chain agent's permissions in three levels and put them in both the knowledge base and its instructions.
- Level 1, it acts. Acknowledge an alert, open one ticket per incident, correct a wrong setpoint back into band, hold an order that has not left the warehouse, page an engineer during working hours. Reversible, cheap, or already what the procedure says.
- Level 2, it asks first. Lock a fridge, reroute a truck, page someone at night. The question carries the unit, the reading, how long it has been out of band, the stock at risk and its value, what the agent proposes, and what happens if nothing is done. The human answers yes or no. They do not have to go and look.
- Level 3, it only recommends. Destroy stock, recall a loaded truck, stop a site. The agent can write the recommendation and the evidence. A person signs.
The ladder is a policy, so it has to be enforced, not hoped for. Levels 2 and 3 live behind the pause tool and behind the MCP server's own checks. An agent that "decides" to lock a fridge without asking still cannot, because the tool refuses without an approval token. Guardrails on the model's output are the last line, not the first.
What it did
Meridian Foods is a fictional distributor with two chilled warehouses, 20 fridge units, six reefer trucks, and a day of deliveries. It is a simulator that ticks once a simulated minute, derives alerts from the sensor readings, and exposes the actuators through the MCP server above. In the demo, a compressor fails on a frozen unit.
Within one cycle the agent opened a maintenance ticket, paged the site engineer, put a hold on the orders whose stock was in that unit, and then stopped to ask the duty manager whether it may quarantine the unit, with the reading, the time out of band, and the value at risk in the question. The manager answered from the monitoring screen. The run resumed and the fridge locked. Nothing in the loop is special-cased. It is a normal agent with a knowledge base, an MCP tool, a pause tool, and an hourly schedule.
Measuring it
An operations agent is only as good as its worst decision, so we wrote the tabletop situations down as an eval suite: eight scenarios like "compressor stopped 20 minutes ago, now -12 C and rising, two orders still picking," each scored on whether the agent followed the ladder. Same prompt, same tools, three models:
- claude-haiku-4.5 scored 0.97, at 4.1 s per case and $0.037 for the suite,
- gpt-4.1-mini scored 0.94, at 3.2 s and $0.005,
- gpt-4o-mini scored 0.75, at 2.3 s and $0.002.
The cheapest model was fastest and skipped escalations it should have made. It acknowledged the alert and opened the ticket, then failed to hold the orders or ask about the quarantine. That is the failure mode to fear in this layer: not a wild action, but a quiet omission that looks like calm. The agent runs on gpt-4.1-mini, and the suite runs again before any prompt or model change ships.
Two things follow from those numbers. Latency of a few seconds is fine for a loop that runs every hour, so the fastest model is not the right one. And the cost of the whole supervisory layer is cents per day, which changes the economics of watching things that were never worth a person's attention.
Test on a twin, then connect the real thing
Nobody should connect an agent to real actuators first. The simulator existed before any of the agents did, and it has a director endpoint for scripting incidents: a compressor failure, a door left open, a truck stuck in traffic, a power cut at one site. Every procedure was exercised against the twin, the eval suite was written against the twin, and the ladder was tuned there.
The real integration is then a substitution. The MCP server that fronts the simulator gets a sibling that fronts the building management system or the telematics API, with the same tool names and the same permission checks. The agent, the knowledge base, the evals, and the schedule do not change. This is the same move software teams make with a staging environment, and it is the reason to keep the device boundary as a tool server rather than wiring the model to the hardware.
Where this applies
The pattern transfers to anything with sensors, actuators, and a procedure manual. A plant with hundreds of alarms a day and a control room that has learned to ignore most of them. A fleet where dispatch is a phone and a spreadsheet. A building where the management system emails warnings nobody reads. A lab with freezers and incubators and a night shift of one. In each case the control loop already exists and works. What is missing is the layer that reads everything, follows the book, and knows when to ask.
It also transfers to the robots when they arrive. A fleet manager for AMRs is another MCP server. A humanoid that runs a VLA model on board still needs someone to decide which task it does next, whether it is safe to send it into that aisle, and who to call when it is stuck. The supervisory loop does not go away because the actuator got smarter. It becomes more important, because there are more actuators and fewer people watching them.
What it comes down to
Physical AI is not one thing. There is a control layer, where the frontier is models that act at tens of hertz on the hardware, and there is a supervisory layer, where the frontier is trust. The second layer is ready now. Expose the world as tools you control, write the procedures down as knowledge, put every physical action behind a question or a signature, run it on a schedule, and measure it against the situations you are afraid of. What comes out of that is the shift that never goes home.
