Anthropic introduced the Model Hardware Standard on August 27, 2026, as a shared interface for AI agents to operate programmable physical devices. MHS places a standardized driver between an agent and each microscope, liquid handler, robot arm, camera, or controller. The driver exposes simple read and write primitives, device metadata, state, and enforced safety limits. Agents can reach that layer through MCP, a command line interface, or code files.
MHS is closer to a hardware integration layer than a robotics model. It does not make an agent understand physics. It gives the agent a consistent way to discover devices and request bounded actions.
Our position is that MHS has the right separation of concerns for lab and factory agents. It is still a research preview, not an integration standard a production team can download and adopt today.
What is the Model Hardware Standard?
Most programmable instruments already expose something: a vendor SDK, serial commands, a network API, a desktop application, or a proprietary control library. The problem is that these interfaces describe the same basic operations in incompatible ways.
An engineer integrating six devices may need six languages, several processes, and custom point-to-point adapters. The orchestration cost rises again when the devices must share timing and state. Anthropic says MHS began with HHMI Janelia Research Campus to reduce this repeated integration work.
MHS normalizes a device behind a driver. Anthropic describes basic primitives such as read and write. A temperature controller might expose a read for current temperature and a write for the target. A robotic stage might expose its position, motion state, allowed range, and a write operation for a new position.
The driver also contains natural-language tags for characteristics that code may not reveal. A robot arm's weight, a laser's operating boundary, or the material constraints of a liquid handler can affect safe operation. MHS uses those tags to produce a reference file describing what a device measures, what can change, and which limits the system enforces.
This reference is important because a raw tool name such as set_position does not tell an agent whether a movement is physically safe. MHS tries to move that context from manuals and operator memory into a machine-readable interface.
The Model Hardware Standard architecture
The public announcement describes five practical layers:
AI agent or agent harness
|
MCP, CLI, or code-file control
|
MHS discovery, state, and orchestration
|
Standardized device drivers with safety limits
|
Vendor API, SDK, serial protocol, GUI, or controllerThe bottom layer remains device-specific. Someone still has to connect the MHS driver to the actual vendor interface. MHS does not eliminate driver work. It makes that work reusable and gives every integrated device a common shape above the adapter.
The state layer lets different programs observe a shared view of the hardware. In the HHMI microscopy example, variables, controls, and sensor values were recorded in a dictionary held in shared memory. Adding a camera then took minutes because its beam-location output could enter the same state model used by the motorized mirrors.
The control layer offers three paths. MCP lets an agent discover and call hardware tools through a standard agent protocol. The CLI gives an operator or agent harness direct commands. Code files let the system compose driver operations into deterministic routines.
That third path is the most important production idea in the preview. An online language model is too slow and variable for every low-level motion. Anthropic observed Claude exploring laser alignment through repeated adjustment and camera feedback, then packaging what it learned into a deterministic script. The script could execute the alignment as one command without asking the model to reason at every step.
This creates a useful division:
- Use the model for planning, diagnosis, parameter search, and exception handling.
- Use deterministic code for timing-sensitive or repeated sequences.
- Use the driver and controller for hard safety enforcement.
An agent should not be the final interlock. If a command can damage equipment or samples, the lower layer must reject it independently of what the model requested.
If your team is already connecting agents to software tools, our MCP adoption analysis explains why a common protocol only creates value when the underlying tool contracts are stable. Axentia's AI agent development work can help design that boundary before an agent receives authority over a real workflow.
What an MHS device contract needs
Anthropic has not released the MHS specification or official driver syntax publicly. Any configuration presented as copy-paste MHS code today would be invented. We can still define the contract a production evaluation should demand.
An illustrative device description might contain:
device:
id: incubator-03
kind: laboratory-incubator
capabilities:
reads:
- temperature_c
- door_state
- alarm_state
writes:
- target_temperature_c
limits:
target_temperature_c:
minimum: 20
maximum: 45
preconditions:
set_target_temperature:
- door_state == "closed"
- alarm_state == "clear"
emergency_stop: controller_managed
This is not official MHS syntax. It shows the information the driver boundary should make explicit: identity, readable state, writable controls, numerical limits, action preconditions, and the owner of emergency behavior.
The implementation behind write(target_temperature_c, 37) should validate the request again. It should reject an out-of-range value, stale device state, a disconnected sensor, or an active alarm before touching the vendor controller.
Every state value also needs a timestamp and quality signal. A temperature reading from ten minutes ago is not current device state. A camera frame that failed to update cannot prove a robotic path is clear. Agent tools should surface stale or uncertain data as an error, not as a normal value.
How MHS coordinates multiple devices
The early studies show why shared state and explicit sequencing matter. At the University of Washington, Claude Code coordinated a liquid handler and a robotic arm for plate handoffs. The arm moved only after the handler reported completion, and the handler did not restart before the arm cleared the workspace. Repeated tests reported no collisions, with the arm triggered about ten seconds after dispensing finished.
At Carnegie Mellon University, an MHS system coordinated a liquid handler, plate reader, robotic arm, and cameras across three computers. The team artificially introduced six conditions: a missing plate, rotated plate, busy reader, disconnected camera, unreachable device, and active emergency stop. The system blocked all six before a device moved.
Those results suggest an implementation pattern based on guarded state transitions:
if not all_devices_healthy():
stop("device health check failed")
liquid_handler.dispense(protocol)
wait_for(liquid_handler.state == "complete", timeout=300)
if camera.plate_pose not in allowed_pose:
stop("plate position is unsafe")
robot_arm.move_plate()
wait_for(robot_arm.state == "clear", timeout=60)
plate_reader.start()
This is architectural pseudocode, not the unreleased MHS API. The point is that orchestration should wait on verified state, include timeouts, and fail closed. A free-form model response should not directly trigger the next physical action.
The honest limitation: models lack physical intuition
The Genentech experiment exposed the central limitation. Claude initially chose one liquid-handling flow rate for water and viscous protein samples. That produced bubbles and inaccurate transfers. When retries caused more agitation, the model did not infer the physical mechanism on its own. Human guidance was required to use a clean well and gentler mixing.
After the cause was explained, the team encoded the lesson into reusable liquid-handling skills. That is encouraging, but it also shows where reliability came from: domain knowledge was converted into a repeatable constraint after a failure.
MHS can standardize observations and commands. It cannot guarantee that a general model understands fluid dynamics, collision geometry, sample contamination, or equipment wear. A production system needs domain-specific evaluators, hard limits, simulation where possible, staged authority, and a human approval path for high-risk decisions.
The preview also leaves procurement questions unanswered. The specification and drivers are not yet open source. There is no public compatibility suite, versioning policy, certification process, or stable driver API to evaluate. Access is limited to selected research and manufacturing partners.
When the Model Hardware Standard is worth evaluating
MHS is worth watching when a facility has many programmable devices, frequent protocol changes, and expensive custom integration. Carnegie Mellon's team reported building four drivers and an orchestration layer in about eight hours, compared with several weeks for a typical vendor setup. A University of Washington researcher connected six instruments in under a week.
It is not worth waiting for MHS when one fixed device already has a reliable vendor automation stack. A deterministic controller with a narrow API will be easier to validate than an agent layer.
It is also the wrong first project for safety-critical motion without existing interlocks. If the hardware cannot independently enforce travel limits, emergency stops, and safe states, adding an agent increases risk before it creates useful flexibility.
For software-only orchestration, start with a mature MCP integration and a constrained agent workflow. Our Agentic RAG implementation guide covers a lower-risk place to test planning, tool selection, and evaluation before extending the same patterns to physical equipment.
FAQ
Is the Model Hardware Standard open source?
Not yet. Anthropic opened MHS as a limited research preview on August 27, 2026, and says it plans to make the standard open source after working with partners on safety evaluations and operating practices. There is currently no public specification or official driver SDK for general installation.
Is MHS the same as MCP?
No. MHS standardizes the device driver, hardware state, capabilities, and safety constraints. MCP is one control path an agent can use to reach that hardware layer. MHS also supports command-line and code-file control, which can handle deterministic or timing-sensitive sequences without continuous model reasoning.
Can MHS safely run equipment without humans?
The preview demonstrates unattended workflows and automatic recovery, but it does not prove general safety. Physical reasoning failures still occurred. Safe deployment requires controller-level interlocks, fresh sensor checks, timeouts, bounded commands, domain-specific validation, audit logs, and human approval for actions with irreversible or hazardous consequences.
Build the safety boundary before the agent
The Model Hardware Standard gives hardware agents a promising shape: reusable drivers below, shared state in the middle, and flexible agent orchestration above. Its best idea is that exploratory model reasoning should compile into bounded, deterministic routines once the procedure is understood.
Teams evaluating lab, manufacturing, or robotics agents should start by mapping device states, commands, physical limits, failure modes, and approval points. If you need help designing that architecture, book a call with Axentia. We can prototype the agent and integration layer without confusing model capability with hardware safety.