The Model Hardware Standard, explained: how MHS lets AI agents safely operate physical devices

The Model Hardware Standard (MHS) is a shared specification that Anthropic opened as a research preview on August 27, 2026, so that AI agents can safely operate physical devices, from microscopes and liquid handlers to robotic arms and the laser systems of quantum computers. This article is a section-by-section reading of the announcement (re-fetched and checked on September 13, 2026), reporting only what the announcement supports: how the standardized driver is designed, which three mechanisms agents use to control devices, what six partner institutions measured, and which hardware vendors are building support. On the relationship to the OpenAI ecosystem, this article makes no unsourced claims, and notes only the fact that MCP is one of the control mechanisms, and that MCP is a protocol GPTMap readers already use.

1. The problem MHS attacks: weeks-to-months device integration

The announcement opens with the status quo: setting up and integrating hardware in a lab or manufacturing facility typically takes weeks if not months. Each device has its own programming interface, devices do not talk to each other, and specialists must build bespoke integrations. Once connected, there is also no common way for devices to share data with an AI agent, or to let the agent operate them safely.

MHS answers with a standardized driver, the software that translates between a computer's operating system and a hardware device, reducing this integration work to hours or minutes. The research preview went to first partners across science, robotics, electronics, and manufacturing, with whom Anthropic says it will build safety evaluations and develop best practices ahead of open-sourcing the standard.

Two boundaries are worth remembering: MHS works with any device that has a programmable interface (purely mechanical devices are not covered yet, and Anthropic is working with manufacturers to build drivers in), and MHS is model-agnostic, accessible to any agent harness via standard protocols.

2. The standardized driver: a three-layer design

The announcement devotes a section to the MHS driver's construction, which breaks into three layers:

1. Read / write primitives: a simple command set, read to fetch state (get temperature) and write to set it (set temperature), that any hardware device can understand and act on;
2. Standard-format discoverability: each device is discoverable in a standard format, so devices and agents find and communicate with each other across networks without a bespoke translator program in between;
3. Natural-language tags and the reference file: machine characteristics that are not discernible from code alone, such as the weight of a robot arm, which matters for manipulating it safely, used to live in paper manuals, on a user's computer, or as tacit knowledge. MHS drivers provide tags where users write this information in natural language, themselves or by chatting with an agent that interviews them about the hardware. The driver then automatically produces a reference file with the device's general characteristics: what it can measure, what can be adjusted, and which safety limits will be enforced. That file gives the agent everything it needs to operate the device.

3. Three control mechanisms: MCP, the CLI, and code files

With devices connected and understood, the agent needs a way to control the hardware. The announcement lists exactly three mechanisms: MCP, the command line interface, and code files (APIs), which work together to enable orchestration across multiple devices via a single line of code.

Control comes with supervision: the agent receives operating data from each device and directs work at a high level, sequencing steps across instruments, monitoring results, and adjusting parameters as conditions change in real time. For long-running tasks or speeds beyond online reasoning, the agent chains driver commands from one or more devices into code files, letting devices carry out operations themselves without step-by-step reasoning.

For MCP practitioners, this is the announcement's most direct signal: MCP's control plane is now officially extended to physical devices. The protocol stays the same; the tools become instruments.

4. Six institutions, one table of measured numbers

The body of the announcement is six first-hand partner reports. The core numbers, all as stated in the announcement:

Three details deserve expansion:

• CMU's autonomous rerun: the first run was rejected by the system itself because the fit came in below 0.9 with saturation at the top of the concentration range. The agent independently decided to discard the plate and rerun on a fresh one with the top concentration compressed from 200 to 100 ug/mL; the second run produced a fit above 0.98 with no human input at any point. Driving the three incompatible interfaces (a directory-watcher scheduler, an ActiveX/COM scripting interface, and a GUI-only plate reader with no API) took about eight hours from scratch.
• QuEra's baseline: a four-person team had previously spent months building a bespoke recovery script that worked about 58% of the time at roughly 150 seconds per attempt. Working through MHS, Claude ran a four-role loop (propose a hypothesis, write the change, run it on the live laser and log every step, read the logbook and decide what to change next) for hundreds of unattended iterations overnight, converging on a deterministic, fully inspectable production script that needs no agent in the loop.
• Genentech's boundary case: when bubbles caused runtime errors, Claude's default instinct was to retry in the same well with different parameters, which only agitated the fluid further. Once researchers explained that the errors were physical, not software bugs, the model kept that context for the rest of the run, and the takeaways were codified into reusable liquid-handling skills. Anthropic draws the lesson explicitly in the announcement: LLMs learn the physical world through text and images, and spatial and physical reasoning still requires expert oversight.

5. The vendor support surface: eight announced

The announcement closes with vendors building MHS support into their products:

• AWS: will support MHS through Strands Robots, its library for connecting AI agents to physical devices, providing preview participants a private pre-release package;
• Automata: adding MHS support to LINQ, its lab automation platform, for intelligent error handling of instruments in autonomous labs;
• Danaher: actively exploring with Anthropic how MHS-supported capabilities could scale biomedical R&D through smart instruments and autonomous laboratories;
• Doosan Robotics: testing MHS with their robotic arms, including automated quality assurance and coordinating tasks across multiple robots;
• MBF Bioscience: building an MHS driver for ScanImage, the software running laser-scanning microscopes in hundreds of neuroscience labs worldwide;
• QIAGEN: experimenting via a working proof of concept on its QIAsymphony Connect nucleic acid purification platform;
• Tecan: adding MHS support for its Fluent liquid handling platforms;
• Universal Robots: has had early access and plans to add support to its robotics platform.

Two developer-ecosystem early adopters: Hugging Face is adding MHS support to LeRobot, its robotics library, and Raspberry Pi is enabling MHS integration across a number of its products after successful tests with its Camera MHS Driver.

6. Limits and the safety roadmap

The announcement is frank about limits, three hard ones:

1. Physical reasoning has a ceiling: LLMs learn the physical world through text and images, and their spatial and physical reasoning still requires expert oversight, with Genentech's bubble case as the documented example;
2. Devices without a programming interface are not covered: Anthropic is working with the manufacturers of such devices to build MHS drivers in;
3. Agents can be overly cautious: QuEra observed Claude stopping to wait for human confirmation before actions it deemed even slightly risky, pausing experiments overnight; their verdict was that an overly cautious agent is preferable to one that is not cautious enough.

Safety and open-source roadmap: Anthropic will use the research preview to build additional safety evaluations with launch partners and to strengthen protections for AI in the physical world; it is developing a physical safety roadmap to expand safeguards policy and enforcement coverage; and when MHS is open-sourced, findings from the preview will be released as part of guidance for deploying the standard safely. Access is via the official waitlist.

7. What this means for GPTMap readers

Keeping to the announcement's facts: MHS is an Anthropic-led standard, announced as destined for open source, with MCP in its control plane, and six institutions have demonstrated the full engineering loop of agents operating hardware: discover the device, read the reference file, orchestrate, recover from errors, and codify the result into deterministic scripts. For MCP developers, the tool surface extends from software APIs to instruments. For readers tracking agent capabilities, the QuEra and CMU cases offer a new benchmark shape: physical-world tasks scored against a human-expert baseline. GPTMap's world state now records MHS key facts (updated September 13, 2026); for the OpenAI side of agent infrastructure, see the related reading below.

8. Next steps

• The protocol itself and its three transports: Model Context Protocol: how MCP works and how to build on it
• OpenAI's agent resource model: The Agents API appears in the OpenAI SDK (beta): /agents CRUD, environments, sessions, and vaults
• Anthropic's enterprise security line in the same period: EFS Explained: How Anthropic Squares Zero-Retention Privacy with Safety Monitoring