On August 27, 2026, Anthropic opened a research preview of the Model Hardware Standard (MHS), a shared specification for AI agents to discover and operate physical devices such as microscopes, liquid handlers, robotic arms and lasers. The work started as a collaboration with HHMI Janelia Research Campus. The first participants are research labs and advanced manufacturers. Anthropic says MHS is model-agnostic, works with any device that has a programmable interface, and can be reached through the Model Context Protocol (MCP), a command-line interface, or code. It also says it will open-source the standard after it has built safety evaluations with partners.
This matters to builders because it is the first serious attempt by a frontier lab to define an agent-to-hardware layer in the way MCP defined agent-to-tool integration. The pitch is that integrating a device would take hours instead of weeks, and that a device's physical limits would be encoded in its driver rather than in the prompt. Nearly two months after launch, though, the spec still can't be read or implemented by anyone outside the program, and nearly every result comes from Anthropic or its partners.
What we checked
- Does the cluster point to a broader market or architecture shift that a single release note can't capture? partly confirmed. Architecturally, MHS proposes a distinct layer: standardized drivers with read/write primitives, device discovery, and machine-readable capability and limit files, reachable through MCP, a CLI or code. Instrument and robot vendors (Tecan, QIAGEN, Danaher, Universal Robots, AWS Strands Robots, Hugging Face LeRobot and others) have signed on at the testing or planned-support stage. Whether this becomes a market shift can't be judged yet: the spec isn't public, and no vendor has a shipping product. [1][5]
- (Added) Is the MHS specification publicly available or open-sourced as of October 2026? refuted. The official site describes a limited research preview with access by application. It links no spec, documentation or license, and gives no date for open-sourcing. I found no official open-source release; a GitHub project with a similar name appears to be an unaffiliated community effort. [2][1]
- (Added) Do safety limits really sit below the model, and do production artifacts run without the AI in the loop? partly confirmed. QuEra's own post says MHS enforces device-declared bounds, interlocks and emergency stops at the hardware interface, independent of the model. It also says the final relock controller is a deterministic script that runs without the AI. That is one partner's account from a dedicated testbed, not a live system, and the tuning workflow still keeps the AI in the loop. [3][4]
What we found
- The design has four parts: a standardized driver built on simple read/write primitives (for example, get or set a temperature); discovery in a standard format so agents can find devices across networks; natural-language 'device knowledge' tags, such as an arm's weight or its safety limits, which the driver turns into a reference file of what the device can measure, what can be adjusted, and what limits apply; and control through MCP, a CLI or code files. Agents can chain driver commands into scripts so that long-running tasks don't need a model call at every step. [1]
- Access is gated. The official site describes a limited research preview with a waitlist and a promise of eventual open-sourcing, but it links no specification or documentation and gives neither license terms nor dates. As far as I can tell, no official public spec or repository exists as of this writing. [2][1]
- The strongest result comes from QuEra's own technical post. A Claude-built laser-relock controller recovered the lock in 695 of 700 timed trials (99.3%) across seven disturbance classes. Recovery took 0.9 to 5.4 seconds for most faults and about 10 to 14 seconds for the hardest, compared with 5 to 10 minutes for a human expert. The laser also hopped modes on its own 43 times during the pilot, and all 43 were recovered automatically. The work ran on a dedicated testbed controlling about $0.7M of hardware, not on live machines. [3][4]
- One statistic that circulates widely, a 58% success rate for QuEra's earlier hand-written script, does not appear in QuEra's blog post or in the Interesting Engineering article I opened. QuEra describes the earlier baseline in terms of effort: four specialists spent two to three weeks writing a recovery script by hand. Until a primary source shows the 58% figure, treat it as unverified. [3][4]
- The pattern behind the QuEra result is a useful design lesson. The agent explores within bounds enforced at the hardware interface, then turns what it learned into a deterministic, inspectable program that runs without the AI. Anthropic describes the same pattern with its laser-alignment example, where Claude iterated using camera feedback and then wrote a single-command alignment script. [3][1]
- Anthropic is open about the model's physical-reasoning limits. In Genentech's protein-assay pilot, Claude treated foaming as a software failure, and R&D World reports that its response produced more foam until human experts stepped in. MHS also doesn't yet support devices without a programmable interface. [1][5]
- The partner list is broad, but the commitments are early-stage: AWS (Strands Robots), Automata (LINQ), Tecan (Fluent), QIAGEN, Danaher, Doosan Robotics, Universal Robots, MBF Bioscience, Hugging Face (LeRobot) and Raspberry Pi. Anthropic's own wording ranges from 'exploring' and 'testing' to 'adding support'. I found no standalone vendor press release from Tecan or Hugging Face. [1][5]
- Regulation may matter as much as the technology. TNW points out that the EU Machinery Regulation 2023/1230 replaces the Machinery Directive on January 20, 2027, and covers AI-based safety functions. TNW's own analysis argues that an MHS limit file restricting a robot arm's motion could count as a safety function. No regulator has confirmed this. [6]
What it means
For builders of agent systems, the lasting point is the architecture, whether or not MHS itself wins. Separate three things: discovery and capability description (machine-readable files listing what a device measures, what can be adjusted, and what limits apply); enforcement (bounds, interlocks and emergency stops at the driver or hardware level, never only in the prompt); and runtime (have the agent explore, then commit what it learned to deterministic code that runs without it). You can use this pattern today with your own MCP servers around instrument SDKs, without waiting for the spec. QuEra's results show the pattern can work on precision hardware, at least on a testbed.
Don't build a product roadmap around MHS compatibility yet. The spec is gated, there is no license or open-sourcing date, vendor support is mostly at the testing stage, and the headline numbers come from partners rather than independent evaluators. If you work in lab automation, robotics or manufacturing, applying to the preview is the only way to see the spec. Teams selling into the EU should get a view on whether agent-facing limit files count as safety functions under the Machinery Regulation before January 2027. Check partner statistics against the partners' own publications; the 58% baseline is one figure that didn't hold up.
Still open
- When will MHS be open-sourced, under what license, and who will govern it: Anthropic alone, or a neutral foundation, as some other agent protocols have done?
- How does MHS relate to existing lab and industrial standards such as SiLA 2 and OPC UA? Does it wrap them or compete with them?
- What safety evaluations is Anthropic building with launch partners, and what will the promised 'physical safety roadmap' contain?
- Has anyone independently evaluated the integration-time and reliability claims beyond partner-reported pilots?