Two days ago I wrote that any step that can't be called by a program gets squeezed out. Today Anthropic turned "can be called" into a standard.
On August 27, Anthropic released the research preview of MHS — the Model Hardware Standard: a shared specification for AI agents to safely operate physical devices. If MCP is how agents reach data, MHS is its hardware sibling. A standardized driver on the device side abstracts an instrument into primitives like read and write ("get temperature," "set temperature"), with natural-language self-description so agents can discover devices on their own. It's callable over MCP, the command line, or an API; model-agnostic, not tied to Claude; open-sourcing is announced.
Two numbers from the first cohort, picking the hardest ones. Carnegie Mellon went from bare equipment to a completed dilution curve in eight hours — the vendor-integration route runs in weeks. On QuEra's quantum computer, recovering a titanium-sapphire laser's lost lock used to take a human 150 seconds with a 58% success rate; now it takes 6 seconds, succeeds 99.3% of the time, and no one touches anything.
Why I'm watching: for the past year in Novi I've been building the dialect version of this — one command model for industrial machines, exposed as both CLI and HTTP/gRPC, so any agent can drive the system without a GUI. When I saw MHS list MCP, the command line, and APIs as its three control mechanisms, I'll admit I laughed. Convergent evolution.
And because I've built this wheel, I don't want to write the "a giant has entered, the future is here" piece. Last Tuesday, in Is Manufacturing at Dusk or Dawn?, I gave three tests for whether a step can enter the agent loop: can it be called by another program, can it hand over state mid-task, does it get a check that isn't its own. Conveniently, I can now grade the new standard on my own exam.
Question one — can it be called: answered. That is MHS's definition. And there is one line in the official limitations worth reading twice: MHS "doesn't yet work with hardware that lacks a programming interface." That is exactly the line I meant by "dawn lights only half the floor" — now written into the standard's scope. The machine on your floor with a touchscreen and no API just moved one step further from the loop.
Question two — state handover: half credit. The rudiments exist. Janelia's microscope rig keeps its entire state in a standardized dictionary in shared memory, and in Genentech's error-recovery case the agent carried the context — "this error code comes from physical bubbles" — through the rest of the run. But that is device state, not task state. When one agent has done half the job and another takes over, where is the standard slot for the handoff? Nothing in the preview materials yet. Most production work doesn't finish in one breath; until this is answered, manufacturing can use MHS only for short, single-shot tasks.
Question three — an independent check: half credit. The right pieces are there: safety limits enforced at the device level, not the agent level — the laser-power cap belongs to the device, and the agent can't exceed it even if it wants to; in testing, six injected faults (missing plate, rotated plate…) were all blocked before any device moved; risky actions stop and wait for a human. All correct. But look at the other scene in the closed-loop experiments: the party that judged "this fit is too poor — discard the plate and rerun" was the agent itself. The builder is still its own verifier. In a lab, that's efficiency. On a production line, that's an audit problem. A lab can owe this answer. A factory can't.
Plug it into a robot arm, and here is what happens. One disclosure first: the standard's text is not available — the research preview runs on a waitlist (modelhardwarestandard.com), there is no public schema, and open-sourcing has no date. So what follows is the primitives the announcement disclosed, plus a year of my own time spent driving arms.
A moving arm has three loops inside it. The servo loop: kilohertz, torque and position, living in the drives. The motion-control loop: 125–500 Hz, trajectory interpolation, living in the vendor controller — UR's RTDE interface runs at 500 Hz. The task layer: single-digit hertz and below, program steps and waypoints. MHS's read/write primitives live in the task layer: write a target pose, set a speed, read the joint states. The two real-time loops below, MHS doesn't touch — and can't. An agent sitting behind MCP is hundreds of milliseconds per round trip at best, two to three orders of magnitude too slow.
From that, day one falls straight out. What works: machine tending, palletizing, positioning for inspection, multi-device orchestration — Doosan's preview tests are exactly "automated quality assurance plus multi-robot coordination" — and the most interesting class of all: the agent rewrites parameters while the device closes its own loop. QuEra's 99.3% is that template. The PID loop runs locally; the agent only tunes it. What doesn't: grinding, deburring, welding — contact tasks. Force response has to close at millisecond timescales, and the agent is three orders of magnitude behind. On day one under MHS, an arm is still a position-controlled arm.
But contact tasks contain one slow loop, and it happens to be the agent's home turf: drift. Burr distributions drift batch to batch as dies wear; the veteran compensates by hand every day, and nobody records the compensation — it evaporates at the end of the shift. I wrote about this in the burr piece. Leave the fast loop to local force control; the slow loop — read last batch's corrections, write next batch's parameters — is exactly what read/write primitives can standardize. If MHS wants a future on factory floors, this is the direction it should grow.
And one seam the announcement leaves open. Safety limits are device-level: speed, force, workspace caps the agent can't exceed even if it wants to. Right design. But crashing into a fixture takes only a semantically legal write — a target pose inside every limit. A device-level cap doesn't know where your tooling sits; a production line's interlocks have always been cell-level. The layer between the device driver and the cell's safety model is, for now, empty in the standard.
One list that's easy to skim past: among the first hardware vendors building MHS support are Universal Robots and Doosan. The cobot makers have moved. That is not a lab-curiosity signal.
The practical part. If you buy equipment: add one line to your checklist — does it have a programmable interface, and does the vendor have an MHS roadmap. Over the next five years that line will outweigh most of the specs on the datasheet. If you build industrial AI: the interface layer is being standardized and will be open-sourced. The window for "I can connect to the machine" as a business is closing, and the value is moving to the two ends — agent-readiness on the device side, and the independent-verification layer above it, which still has no standard answer. That second end is still empty.
Forward this to the engineer you know who is still writing their Nth proprietary driver for one machine — the next one might follow a standard instead.
First Principles Manufacturing — Dispatches from a Novi robotics lab.