Short answer: the Model Hardware Standard (MHS) is a research-preview specification designed to give AI agents a common way to discover, understand, and operate programmable physical equipment. Instead of every lab or factory building a unique integration for each microscope, robotic arm, liquid handler, camera, or other instrument, MHS proposes a standardized driver layer with device descriptions, basic commands, and safety limits. Anthropic opened the preview on August 27, 2026, after the project began as a collaboration with HHMI Janelia Research Campus.
For agent developers, the most important change is not a “new brain for robots,” but an integration contract between software and hardware. An agent can receive a consistent description of equipment capabilities, read state, execute operations, and coordinate multiple devices through mechanisms such as the Model Context Protocol (MCP), the command line, and code files/APIs. The caution is equally important: MHS is not yet a final open standard, preview access is limited, and Anthropic itself says current models still have physical and spatial reasoning limitations that require expert oversight.
What the Model Hardware Standard is
Anthropic defines MHS as a shared specification for AI agents to safely operate physical devices. The official announcement cites laboratory and advanced-manufacturing instruments including microscopes, liquid handlers, and robotic arms, as well as tasks ranging from routine drug-discovery experiments to laser calibration on a quantum computer. Development began through a collaboration between Anthropic and HHMI Janelia Research Campus.
The problem the standard is trying to solve is familiar in automation: each piece of equipment often comes with its own API, software, language, or driver. To make machines from different vendors work together, teams end up writing glue code and bespoke adapters. Anthropic says that work can take weeks or months; in the early tests presented by the company, MHS reduced some integrations to hours or minutes. That reduction is a developer claim based on the preview, not a guarantee for every environment.
The practical flow: device → MHS driver → agent → controls
| Stage | Role in MHS | What changes for the agent |
|---|---|---|
| Physical device | Needs a programmable interface and controllable functions | The hardware can be integrated without relying only on a human-facing interface |
| MHS driver | Translates the equipment into a standardized interface and simple commands such as read and write | The agent does not need to learn a completely different API for every machine |
| Description and discovery | Organizes characteristics, capabilities, parameters, and safety limits in a machine-readable form | The agent can discover the device and understand how to use it, including physical information that may not appear in code |
| Control layer | Allows operation through MCP, the command line, or code files/APIs | The same agent or harness can combine conversational control, direct commands, and deterministic routines |
| Orchestration | Coordinates states and actions across multiple instruments | The agent can sequence steps, monitor results, and adjust parameters during a workflow |
1. A standardized driver instead of a bespoke adapter for each device
The core of MHS is the driver. In the preview material, Anthropic describes simple primitives such as read — for example, getting a temperature — and write — for example, setting a temperature. The goal is not to erase the differences between machines, but to provide a consistent way to expose what each one can measure, change, or execute.
2. The agent receives context about physical characteristics and limits
The driver also includes natural-language tags for information that is often scattered across manuals or held as tacit operator knowledge. One example from Anthropic is the weight of a robotic arm, which matters for safe manipulation but may not be obvious in a conventional API. From this information, MHS produces a device reference containing capabilities, adjustable settings, and limits that should be enforced.
This matters because operating hardware is not the same as calling a purely digital API. Errors can move parts, damage samples, exceed laser power, or cause collisions. The MHS proposal therefore combines discovery and control with explicit information about equipment constraints.
3. MCP is an access path, not a replacement for MHS
The announcement lists three control mechanisms: MCP, the command line, and code files/APIs. This helps separate the roles. The Model Context Protocol is a protocol for connecting applications and agents to external systems; in the MHS context, it can be one way for a harness to access devices already described by the hardware standard. MHS itself addresses the hardware-specific layer: the driver, discovery, device characteristics, and equipment commands.
In practice, an agent can reason about a high-level goal and, when a task needs to be fast, repeatable, or long-running, generate or invoke deterministic code that chains driver commands. Anthropic describes one test in which Claude adjusted a laser experimentally, observed the effect through a camera, and then converted what it learned into a deterministic script that could run as a single command.
What changes for agent developers
- Fewer point-to-point integrations: the promise is to write or adopt a compatible driver instead of maintaining a custom connector for every agent-device combination.
- Hardware discovery: devices can advertise capabilities and state in a common format, reducing dependence on manual harness configuration.
- Physical context in the contract: equipment characteristics and operating limits no longer need to live only in prompts, external documentation, or operator memory.
- Multi-instrument orchestration: an agent can read completion signals, trigger the next step, and coordinate different machines inside one workflow.
- Separation between reasoning and execution: the model can decide what to do while critical, fast, or repetitive routines can be encapsulated in deterministic code.
- Model independence: Anthropic says MHS is model-agnostic and can be accessed by different agent harnesses, not only Claude.
Early examples show the kind of problem MHS is trying to solve
At HHMI Janelia, a microscopy setup combined components and programs from seven vendors without a common interface. With MHS, researchers worked over a shared state and unified interface to coordinate acquisition and analysis. In another case, in the Baker and Pinglay labs at the University of Washington, the standard was used for remote instrument monitoring, qPCR supervision, and coordination between a robotic arm and a liquid handler for collision-free plate handoffs.
Anthropic also presented proof-of-concept work at Genentech for protein-assay automation and cited support or experimentation from vendors and platforms including AWS Strands Robots, Automata, Doosan Robotics, MBF Bioscience, QIAGEN, Tecan, and Universal Robots. Hugging Face and Raspberry Pi are listed as early adopters. These examples show ecosystem interest, but they remain preview and pilot results rather than evidence of general maturity.
What is still preview — and where the limits are
As of September 2, 2026, MHS remains a research preview. The official site says access is application-based and the goal is to develop safety evaluations and best practices with partners before making the standard open source. It is therefore not accurate yet to treat it as a final public specification with a stable implementation and guaranteed broad compatibility.
There is also a concrete limitation: MHS depends on a programmable interface. Anthropic says the standard does not yet work with hardware that lacks one, although it is working with manufacturers to expand support.
The other limit is the model itself. Anthropic notes that Claude learns about the physical world through text and images and still has spatial and physical reasoning limitations. In tests with protein samples, for example, researchers had to guide the model to recognize that failures caused by foam were physical problems rather than software bugs. That is a warning for any real deployment: driver and control-system limits are necessary, but they do not remove the need for expert supervision, interlocks, permissions, and human procedures appropriate to the risk.
Is MHS “ready-made” hardware safety? No
Safety was presented as a design requirement, but the preview stage itself shows that this work is ongoing. Anthropic says it is using the current phase to build additional evaluations, strengthen protections, and develop a physical-safety roadmap. Partners also describe plans to add checks, monitor device responsiveness, and define when higher-risk decisions require human approval.
The correct reading is therefore: MHS provides a structure for declaring capabilities and limits and for standardizing access; it does not replace independent physical controls, procedure validation, permissions, emergency stops, or expert oversight.
How to assess MHS today in an agent project
Teams outside the preview can still prepare their architecture without pretending the specification is already open. A prudent path is to inventory which devices have programmable interfaces, separate read and write operations, document states and physical limits, identify actions that require human approval, and distinguish decisions that need agent reasoning from routines that should be deterministic.
Once the standard is opened, that preparation will make it easier to compare the actual MHS contract with an existing architecture. For teams that want to participate now, the official path is the Model Hardware Standard site, which hosts applications for the research preview.
In summary
MHS is an attempt to turn programmable physical equipment into resources that agents can discover and operate through a common interface. The practical shift for developers is to move part of the work from bespoke integrations into a standardized layer of drivers, descriptions, limits, and control mechanisms. That creates room for workflows in which an agent coordinates multiple instruments and hands repetitive operations to deterministic code.
But the August 27, 2026 announcement should be read as the beginning of a specification, not a finished product. The standard is still in preview, does not cover hardware without a programmable interface, and still depends on expert oversight given the physical-reasoning limitations of current models. The potential gain is significant precisely because the boundary is no longer just software: once agents can act on real machines, the quality of the hardware contract and the safeguards become a central part of the architecture.
