On August 27, 2026, Anthropic announced the "Model Hardware Standard (MHS)," an interface that lets AI agents operate laboratory instruments and robots, and began a research preview. The early version, developed together with the HHMI Janelia Research Campus, is being made available to scientific research facilities and advanced manufacturers, with participants selected through applications. The goal is to wrap devices—each with different manufacturers and control methods—in a common description, so that AI can read their state, operate them, and coordinate multiple devices together.
However, MHS has not become a widely agreed-upon public standard. The specification and implementation remain unpublished. No licensing or conformance testing has been disclosed either, making this, for now, a framework that Anthropic and its participating companies are testing. Even so, this announcement gives concrete shape to what is needed to extend the connection point that MCP opened for software-based data and functions into the physical world—where things can break or people can get hurt.
Embedding Safety Limits Between Read and Write
At the core of MHS are standardized drivers prepared for each device. According to the public description, drivers unify a small set of basic commands—such as "read" to get temperature and "write" to set temperature—into a common form, and put devices into a format that can be discovered over the network. The target is any device with a programmable interface, regardless of which AI model or agent framework is used.
Common commands alone cannot make it safe to operate machinery. A robot arm's load capacity, a laser's allowable output, and the ranges that can be adjusted may not be readable from code. In MHS, users add such information to drivers as natural-language tags. The system also envisions agents asking equipment operators questions and building tags from the answers. Based on the tags, drivers generate reference files summarizing what can be measured, what can be changed, and which upper limits are enforced.
The prototype mechanism developed at Janelia goes further, collecting device states into a state dictionary in shared memory. Detectors running on MATLAB, cameras in Python, and measurement systems in C# can all read current values from the same format. Previously, researchers had to rewrite display screens and analysis code for each device, but now they can reuse components organized by data type.
There are three routes by which agents reach MHS: MCP, the CLI, and API code. MCP exposes devices to the AI side as tools. The CLI makes it easier for humans and agents to check the same commands together, and code files run long or fast processes as fixed procedures. MHS is not a replacement for MCP. It is a layer, sitting beneath MCP, that aligns the meaning, state, and safety boundaries of physical devices.
What 700 Validation Runs Revealed About AI's Actual Role
QuEra Computing's demonstration was not a setup in which AI remained resident inside a fast control loop. In the company's neutral-atom quantum computer, processing halts when a laser drifts from its target frequency. Relocking by a human expert takes 5 to 10 minutes, and a conventional dedicated script previously took about 150 seconds per attempt, with a success rate of 58%.
Claude read the state of the actual hardware via MHS and repeatedly tried recovery methods while inducing simulated failures. Separate Claude instances were assigned distinct roles—forming hypotheses, fixing code, executing, and evaluating logs—and ran hundreds of cycles overnight. The procedure, which had been linear, was rewritten into a decision tree that changed operations depending on the type of failure.
During development trials, the success rate rose to 96%, and the time required dropped to about 6 seconds. When the completed script was subjected to blind validation without AI involvement—testing seven types of disturbance, 100 times each, for 700 trials total—695 runs correctly restored the proper state. That is a 99.3% success rate. QuEra reports that simple failures were recovered in 0.9 to 5.4 seconds, while difficult failures involving large frequency deviations took about 10 to 14 seconds.
What AI handled here was the development of the experiment and control logic. After completion, relocking the laser is done by an ordinary, deterministic script whose contents can be inspected. The microsecond-scale servo loop remains within the existing control system, and the script supervises from a layer above it. Meanwhile, in a separate workflow that tunes multiple parameters, AI still remains in the loop, searching for values depending on conditions. How MHS is used changes the safety requirements—between tasks where AI can be removed during operation and tasks where AI must keep making decisions.
These numbers are promising, but they come from a company report obtained in QuEra's own test environment. They are neither peer-reviewed research nor a benchmark reproduced on a different quantum computer by a third party. Other case studies included in Anthropic's announcement should also be read as accounts of participating organizations trying out the early version.
Connecting Equipment in 8 Hours, Then Rerunning Experiments Under Changed Conditions
A team at Carnegie Mellon University (CMU) connected a liquid dispenser and a plate reader via a robot arm, added a surveillance camera, and automated a serial dilution experiment to derive dose-response curves for a drug. Although the devices were distributed across three incompatible computers, the process—from writing the drivers to a single autonomous rerun of the experiment—was completed in about 8 hours, according to the team. The participating researcher noted that having a vendor assemble such a system through conventional methods would take multiple weeks.
The time saved was not limited to writing code to operate the devices. In the first experiment, the concentration ceiling was too high, resulting in a poor fit for the dose-response curve, so the agent discarded the plate, narrowed the concentration range, and tried again. The second attempt produced a usable curve. What is new is that, beyond simply connecting the devices, the entire cycle—from measurement results to changing experimental conditions—was closed within the same interface.
CMU also tested fail-safe behavior. Six artificial conditions were induced: no plate present, wrong orientation, reader in use, camera disconnected, device unreachable, and emergency stop engaged. According to the published results, MHS halted processing before the device moved, under all conditions.
Even so, setup will not always take just 8 hours. In another Anthropic-affiliated lab, connecting six devices took less than a week, and the report notes that complex protocols require additional optimization. Older equipment without a programmable interface currently falls outside the scope, and creating and validating drivers remains necessary work. Whether the computing cost of running agents for extended periods is worth the resulting reduction in labor also varies by use case.
Entering a Market That Already Has OPC UA and SiLA 2
Standardizing equipment integration did not start with MHS. In factories, OPC UA; in laboratories, SiLA 2; and for robotics, ROS 2 already play the role of connecting different devices and software. MCP also provides a common connection for tool execution and context exchange. Evaluating MHS requires distinguishing the boundaries each technology covers.
| Technology | Primary Connection Targets | Scope Covered by Public Specification | Relationship to MHS |
|---|---|---|---|
| MCP | AI hosts and servers | resources, tools, prompts, session | Upper-layer route for reaching MHS devices |
| SiLA 2 | Laboratory instruments and software | Features, Commands, Properties, discovery, authentication | Functional overlap in laboratory automation |
| OPC UA | Factory sensors to enterprise systems | Information models, services, communication, discovery, secure exchange | Could serve as existing infrastructure in industrial fields |
| ROS 2 | Nodes composing a robot | topic, service, long-running action | Could handle communication within robots |
This comparison shows that MHS does not need to rebuild every communication technology for physical devices from scratch. ROS 2 separates the flow of sensor data from long-running actions, while OPC UA handles command/control along with information exchange that includes authentication and encryption. SiLA 2 has function-level commands, properties, and device discovery. If MHS is to expand into existing facilities, an adapter configuration that uses these underneath the drivers is realistic.
Competition has already begun. In April 2026, the OPC Foundation announced it would prepare more than 430 OPC UA Companion Specifications for RAG and MCP use. The plan is to convert existing industrial information models into a format that AI can more easily search and use—approaching the same connection point from the opposite direction as MHS. Where MHS chooses light-weight adoption through natural-language tags, OPC UA carries the rigorous semantic models and conformance that industry has built up over time.
A clear distinguishing feature MHS has added is that it built into its design, from the start, a flow moving from AI exploration to verifiable code. However, Anthropic has not yet disclosed how MHS maps to or bridges with OPC UA, SiLA 2, or ROS 2. If it merely adds one more common driver, integration work will remain necessary. If existing standards can be reused, MHS could have value as a thin upper layer for agents.
What Is Missing Before This Becomes a Safe Common Specification
With physical equipment, even correctly authenticated commands can cause accidents—for instance, an authorized agent setting a temperature beyond the permissible range, or moving a robot arm into a space where another device is working. MCP's authentication and user confirmation control who can call which tools. Beneath that, MHS explains that it keeps device bounds, interlocks, and emergency stops independent of the model, enforcing them on the hardware interface side.
Moving safety limits into the driver is a reasonable direction. But because there is no public specification, third parties cannot yet audit how enforcement actually works. How does the system stop if a natural-language tag value is wrong, if sensor data is stale, or if the network drops mid-operation? It is also unclear how priority is determined when multiple agents send commands to the same device, or how safety settings are preserved when a driver is updated.
Limits remain on the AI side as well. In an experiment at Genentech, when bubbles formed in a viscous protein sample, Claude needed guidance from researchers before it understood that this was a physical problem rather than a software glitch. At QuEra too, failures of the physical hardware itself could not be resolved by AI, and whenever an operation was judged even slightly risky, the system waited for human approval—sometimes halting an experiment overnight. A design that cautiously stops avoids accidents, but it trades off against the uptime achievable with unattended operation.
The research preview is the stage for surfacing these undetermined details on real hardware. Anthropic states that, after the preview, it plans to open-source MHS and publish a physical-safety roadmap and adoption guidance. What is needed there, before adding more success stories, is to make the driver schema, failure semantics, versioning, and conformance testing verifiable by anyone.
Whether MHS takes root as a common specification will not be decided by Anthropic's name or the number of participating companies. The conditions are that it demonstrate bridges with OPC UA and SiLA 2, that the same safety limits function with different models and third-party drivers, and that this be reproducible in independent testing. Once these conditions are met, agents will be able to carry researchers' instructions beyond software and safely repeat experiments across different pieces of equipment.