When AI Starts Moving Atoms: Anthropic's Model Hardware Standard

On August 27, 2026, Anthropic released a research preview of the Model Hardware Standard, or MHS, a common interface that lets an AI agent discover a piece of laboratory or factory equipment, read its sensors, and send it commands [1]. It does for physical devices what the Model Context Protocol (MCP) did for software tools: it replaces a separate custom integration for every target with one standard interface [2]. I talked through it on the latest episode of IBM's Mixture of Experts podcast.

In the demonstration people quoted most, a team at Carnegie Mellon connected a liquid handler, a plate reader, a robotic arm, and cameras across three computers with incompatible interfaces, and had the whole stack running in about eight hours instead of the weeks a vendor integration usually takes [1]. The eight-hour integration result is useful, but I am more interested in how the system decides which commands are allowed to reach the hardware. A model can propose an action, but it should not be the component responsible for deciding whether that action is safe. That distinction becomes important when a mistake can contaminate a sample, damage an instrument, or interrupt an experiment.

What MHS actually is

Connecting an AI agent to a new tool has usually meant writing custom glue for each target. MCP standardized that glue for software, giving an agent one interface to reach files, databases, and web services. MHS does the same thing one layer down, for hardware.

It helps to keep four things separate:

MHS is the specification. It defines how an agent and a device talk, using a small command vocabulary built mainly on read (get a temperature, a position, a level) and write (set a temperature, move an arm, dispense a volume), plus a way for agents and devices to discover each other on a network [1][3].
A driver implements that specification for one specific instrument. Someone writes and validates a driver for each supported device. Take a liquid handler: its driver might expose read for the current tip position and remaining volume, and write to aspirate, to dispense into a named well, or to move to a coordinate. When the driver is installed, it produces a reference file that lists what the device measures, what can be set, and the safety limits it will enforce, such as a maximum volume a well can hold [1].
MCP, a command line, or plain code files are how an agent reaches the driver. MHS is model-agnostic, so the device does not depend on which model is driving it [1].
The hardware controller is the device's own firmware, which drives the motors, valves, and lasers in real time. MHS sits above it and does not replace it.

MHS began as a collaboration between Anthropic and HHMI's Janelia Research Campus, and it grew from a simple idea: put the whole state of an experimental rig into one standardized dictionary in shared memory, so every instrument reads and writes against the same picture of the setup [1].

The integration results

At Carnegie Mellon, a Claude Opus 4.8 agent ran a CyBio Felix liquid handler, a Varioskan LUX plate reader, a robotic arm, and cameras, spread across three computers whose interfaces did not match. One used a watched directory for scheduling, one spoke Windows ActiveX and COM, and one had a graphical interface with no programmatic access at all. Writing the drivers and the orchestration on top took about eight hours, against the several weeks Anthropic says a vendor-built setup usually needs, and the finished system ran serial-dilution dose-response experiments about three times faster [1][3].

Other labs reported the same pattern. A University of Washington group used MHS for agent-supervised qPCR and to hand plates between a robotic arm and a liquid handler, and Janelia unified a microscopy rig that had needed seven separate vendor programs into a single interface [1].

Fig. 1 — Integration before and after MHS. On the left, each instrument needs its own vendor tool and a piece of custom glue. On the right, the same instruments share one driver interface. The eight-hour and multi-week figures are Anthropic's reported comparison from the Carnegie Mellon preview, not a controlled benchmark.

I read these as reported case-study results, not a controlled benchmark, and MHS does not make integration free. Someone still writes and validates a driver for each device, and the eight-hour figure comes from a preview that only a handful of partners can access [4]. What makes it credible is the range of independent labs describing similar gains and the list of hardware makers already building support, which includes Tecan, QIAGEN, Danaher, Universal Robots, Doosan Robotics, and Automata, alongside AWS, Hugging Face's LeRobot, and Raspberry Pi [1][4]. When the equipment makers build to a spec, that spec tends to become the default.

The safety boundary

The number that matters most here is not a model benchmark. In the Carnegie Mellon dose-response work, the allowed error on a dispensed volume was only 5 percent before the curve became unusable, and a single dispense cycle took four to five minutes [1]. A software agent that makes a mistake returns an error you can retry. A lab agent that makes the same mistake can contaminate a plate, waste a day of reagent, or move a robotic arm into an expensive instrument.

So the design question that matters is where the limits are enforced. Four things are easy to blur together, and physical AI depends on keeping them apart:

A model instruction is a command the agent proposes, such as dispense 50 microliters into well A1. It is a suggestion, and it can be wrong.
A driver-enforced bound is a software check the MHS driver runs before it forwards a command. The reference file declares the limits, and Anthropic says MHS enforces device-level safety limits, so a command that breaks one is rejected before the device moves [1].
An independent hardware interlock is a physical mechanism built into the instrument, such as an emergency stop or a limit switch, that halts motion no matter what the software says. MHS does not provide this. In the Carnegie Mellon fault tests, an active emergency stop was one of the conditions the system checked and refused to move against, which means MHS respects an interlock it does not itself supply [1].
A deterministic control loop is the device's firmware, which handles microsecond timing and repeatability. The model is never inside this loop.

MHS's real contribution to safety is the driver-enforced bound, plus the discipline of checking conditions like an active emergency stop before any motion. In the Carnegie Mellon run, engineers induced six fault conditions, a missing plate, a rotated plate, a busy reader, a disconnected camera, an unreachable device, and an active emergency stop, and the system blocked all six before anything moved [1]. That is a good result for the software layer. It says less about the independent hardware interlocks, which still protect the equipment when a software check fails, and Anthropic is careful here: the preview makes no claim of formal safety certification, stresses that physical tasks still need expert oversight, and describes a physical safety roadmap that is still being built [1].

Fig. 2 — The safety boundary. The MHS driver checks each proposed command against the limits declared in the reference file and rejects the ones that violate them before the device moves. The emergency stop and other hardware interlocks are separate physical mechanisms that MHS respects but does not provide.

This lines up with the separation-of-concerns argument I make about hardware and software co-design. A flexible model is good at planning and adapting. A hardware controller is better at timing and hard bounds. You want the model proposing routines and the firmware and interlocks enforcing limits, and you never want the model inside the loop that keeps a laser from burning through a sample. It is the same instinct behind DeepView, the accelerator-debugging tool my group built, where the goal is to catch the earliest point at which behavior diverges instead of waiting for a failure to surface downstream. For a physical agent, the equivalent is a hard check at the first illegal command.

Exploration and execution

The QuEra example shows how the split works in practice. A quantum-computing setup has to keep a laser locked to a reference. The lab's existing hand-written script recovered the lock about 58 percent of the time, at roughly 150 seconds per attempt. Claude explored the problem and produced a recovery routine as a deterministic decision tree, which in this case was a fully inspectable script that runs in production without an agent controlling it [1]. In a blind test of 700 disturbances it recovered the lock 695 times, a 99.3 percent success rate, with the hardest cases taking 10 to 14 seconds against the 5 to 10 minutes a human needed. Over a 19-hour run the routine did not lose the lock once, while the expert-tuned baseline unlocked about 1.6 times an hour [1].

I want to be careful about what this does and does not show. The agent does not automatically compile every task into a script. It produced one here, and the routine earned repeated use only after it was validated. In the Carnegie Mellon dose-response work, the first automated run was rejected because its fit fell below an R-squared of 0.9, and only the second run, above 0.98, was accepted [1]. The model is also not always out of the loop: the QuEra agent often paused to wait for human confirmation before anything it judged risky [1].

Fig. 3 — Exploration versus execution, using the QuEra laser-lock example. The model explores with live feedback and proposes a routine. Once the routine passes a validation check, a deterministic controller repeats it, escalating back to the model or a person on faults it cannot handle.

Where the durable value might sit

There is a business question people jumped to as soon as MHS appeared. If the interface is open and model-agnostic, does the model on top become a commodity? My answer is: partly, and not automatically.

The commoditizing force is real. If every instrument speaks one protocol, swapping Claude for a cheaper open-weight model or an in-house fine-tune gets easier, because the drivers do not change. I have written about the same dynamic in software, where standard interfaces push value toward the layer that routes each request rather than the model serving it.

But an open standard lowers switching costs without deciding on its own where the money ends up. Writing and validating reliable drivers, certifying instruments, engineering interlocks, and running orchestration software a lab can trust are all hard problems, and durable value could settle in any of them. Some of it may stay with the model, since better physical reasoning is exactly what the preview says is still missing. Anthropic is sharing MHS ahead of open-sourcing it [1], which reads to me as a willingness to make the model more replaceable in exchange for defining the interface. Where the value lands after that is an open question, and I would not bet the whole answer on the model becoming a commodity.

What I am watching

The clear limitation today is the model's physical reasoning. At Genentech, researchers had to guide Claude to treat foaming in a well as a physical failure rather than a software bug; its instinct was to retry in the same well with different parameters, which only produced more bubbles [1]. Anthropic's own position is that an overly cautious agent is preferable to one that is not cautious enough, and that a physical safety roadmap is still in progress [1].

Three things I will be watching:

Generalization. Does the explore-then-compile pattern hold for messier, less repeatable tasks than a laser relock or a dilution curve?
The safety boundary. Do driver-enforced limits hold when a model actively works around them, the failure mode the industry saw this year when an agent broke its sandbox? And do labs keep independent hardware interlocks in place instead of trusting the software check?
Accountability. Who answers when a lab agent damages an instrument or ruins a batch of samples?

MHS shows that a common interface can reduce the work of connecting AI agents to laboratory equipment. The harder work is making those connections dependable. Drivers need to be validated, hardware interlocks need to remain independent, and recovery routines need clear limits and human oversight. Better models will help, but they do not replace that engineering work. I will be watching whether these systems can move beyond controlled demonstrations into labs where failures are expensive and reliability matters every day.

References

[1] Anthropic, "Previewing the Model Hardware Standard," August 27, 2026.

[2] Anthropic, "Introducing the Model Context Protocol," November 25, 2024.

[3] MarkTechPost, "Anthropic Opens a Research Preview of the Model Hardware Standard (MHS)," August 29, 2026.

[4] Fortune, "Anthropic makes first move into physical AI with universal standard for scientists, manufacturing," August 27, 2026.