What Is the Model Hardware Standard (MHS)?

The short answer

A driver standard for agents, not a robot brain

On August 27, 2026, Anthropic opened a research preview of the Model Hardware Standard, or MHS: a shared specification that lets an AI agent discover, understand, and operate programmable physical equipment. Microscopes, liquid handlers, plate readers, robotic arms. If the Model Context Protocol (MCP) gave agents a standard way to reach software, MHS is an attempt to give them a standard way to reach machines.

Here is the short version. MHS is a driver standard, not a robot brain. It describes each device in a format an agent can read, exposes a small set of commands, and keeps the safety limits in the driver rather than in the prompt. It is not public yet, it does not replace the protocols labs and factories already run on, and Anthropic itself says the model still needs expert oversight around physical work.

The part we find most interesting is one sentence in Anthropic's own announcement: MHS "is model-agnostic, and any agent harness can access it using standard protocols." That sentence is the best public clue to where MHS sits in the agent stack, and it is the reason this article exists.

The mechanism

What MHS actually specifies

At its core, MHS is a standardized driver layer between an agent and a device. Anthropic compares it to the driver that sits between an operating system and a piece of hardware; the analogy in CNBC's coverage was a USB-C cable. Three pieces do the work.

• A small command set: devices expose read and write primitives (Anthropic's own examples are "get temperature" and "set temperature") plus discovery, so that devices and agents can find each other across a network without a bespoke translator program for every pairing.
• A reference file per device: the MHS driver carries natural-language tags describing a device's physical characteristics, such as what it measures, what can be adjusted, how much a robot arm weighs, and which safety limits are enforced. Much of this knowledge used to live in manuals or in the head of whoever set the instrument up. The driver compiles it into a reference file that an agent reads before it touches anything.
• Limits that live in the driver: Anthropic's design puts device-level safety limits in the driver rather than in the model's instructions. A vendor can bound the speeds and angles an arm may use; a lab can forbid a laser from running above a power threshold. That is a stronger place for a limit than a prompt. It is still software, and how strong it is depends on what is underneath it, which we come back to below.

An agent reaches an MHS device through three paths: MCP, a command-line interface, or code files. That is the first clue to the layering: MHS is something a harness calls, through the same protocols it already uses for software tools.

The evidence

What the early partners recorded

Anthropic developed MHS with HHMI Janelia Research Campus and ran the preview with a first group of labs and manufacturers, including Genentech, the University of Washington, Carnegie Mellon University, QuEra Computing, and Tetsuwan Scientific, alongside hardware vendors such as Tecan, QIAGEN, Danaher, Universal Robots, Doosan, and AWS. The results below are as reported in Anthropic's announcement. Each is specific to one partner's task, and they should be read that way:

• Carnegie Mellon reported bringing four instruments online in about eight hours, against several weeks for the usual vendor integration, and running a dose-response experiment about three times faster once the instruments were coordinated.
• QuEra reported automating the laser relock procedure on a quantum computer and, in a blind validation of 700 trials, succeeding in 695 of them, a 99.3 percent rate.
• The University of Washington reported integrating six instruments in under a week.

Anthropic's framing is that the integration work behind these results "typically takes weeks, if not months" and that MHS reduces it to hours or minutes. That is the claim under test in the preview, not yet a general fact.

The boundaries

What MHS does not do yet

Engineers who already automate labs and factories have raised several objections, and most of them are fair.

• The standard is not public. At launch you have to apply for access to read or implement MHS. Anthropic says it plans to open source the specification once safety evaluations are complete. Until then, independent implementations and interoperability checks are not possible outside the preview. As one Hacker News commenter put it, you should not need permission to read a standard.
• Labs and factories already have protocols. OPC UA connects industrial equipment, SiLA 2 covers laboratory instruments, and ROS 2 runs robots in labs and factories. Those were designed for machines talking to machines. MHS adds device descriptions written for a language model to read. It has not, so far, said how it maps onto or bridges those existing standards. Robotics engineers on the Open Robotics forum are already treating MHS as a layer-zero driver and description standard, in the same family as URDF, and asking how its reference files should line up with ROS 2 conventions. That is the right question, and it is open.
• An LLM is not a real-time controller. This is our engineering reading rather than anything Anthropic has said: read and write over a network is supervisory control. Fast, deterministic loops, interlocks, and certified safety controllers stay below the agent, where they are today. MHS does not change that, and the safest reading of the announcement is that it does not try to.
• Enforcement depends on what is underneath. "Limits in the driver" is better than "limits in the prompt." Whether the limit is enforced in software, in firmware, or in independent safety hardware is an implementation question the preview material does not settle.
• Anthropic's own caveats. The announcement says the model still struggles with physical, chemical, and biological constraints, that expert oversight is required, and that in testing the agent often stopped to wait for human confirmation before a risky action. Anthropic describes a physical safety roadmap as work in progress.

There is also a regulatory clock. The EU Machinery Regulation 2023/1230 applies from January 20, 2027, and, as The Next Web noted in its coverage of MHS, it is the first EU machinery rulebook to cover AI-based safety functions. Whatever MHS becomes, it will grow up alongside that rulebook.

None of this makes MHS small. It makes it early. The interesting move is architectural, and it is the same move the industry has been making all year.

The layer map

MCP, MHS, and UHP: three edges of the same shape

Go back to Anthropic's sentence: any agent harness can access MHS using standard protocols. An agent harness is the complete runtime around a model: the loop that plans, calls tools, keeps a session, works with files, and decides when the job is done. Codex, Claude Code, and Hermes are harnesses in this sense. Our definition page is What is an agent harness?

Once you name the harness, the three protocols fall into place as three edges of the same shape:

• MCP connects a harness to software: tools, APIs, data sources.
• MHS connects a harness to hardware: instruments, robots, manufacturing equipment, each described in a file the harness can read.
• UHP connects a product to a harness. The Unified Harness Protocol is the open contract for starting a task, following it, continuing the session, cancelling it, and collecting the files it produced, the same way across every harness.

We have written the software half of this before, in one sentence: MCP connects agents to tools; ACP, the Agent Client Protocol, connects agents to editors; UHP connects applications to harnesses. MHS adds a fourth line: MHS connects agents to machines. In this map, which is our proposal rather than a published Anthropic diagram, the harness is the node every line touches.

Side by side

What each protocol carries

The table describes the primary job of each protocol. A harness typically speaks MCP and, in the preview, MHS; a product speaks UHP to the harness. The layers compose; none replaces another.

Two things follow from the map. First, MHS is not "MCP for hardware" in the sense of a rival: it can be reached through MCP, a CLI, or code, and it sits one step closer to the device. Second, the harness is where the decision to act gets made, within the limits the driver enforces and with a person confirming the risky steps. The moment a harness can read a reference file that says what an arm weighs and which joint angles it never exceeds, the harness is the component turning that description into a plan. That is a lot of responsibility for a component most product teams still treat as a coding tool.

The product bridge

What changes for teams building products on agents

For most product teams, the immediate change is not that your app will run a centrifuge next quarter. Our reading is that the harness has become the unit that does the work, in software today and on the bench tomorrow, and the question shifts from "which model" to "which harness, with which model, for which task."

That is the problem HarnessRouter exists to answer. HarnessRouter is the world's first unified interface for agent harnesses: one Agent API that runs complete agent tasks on Codex, Claude Code, Hermes, and other supported harnesses, with task execution, sessions, files, streaming progress, and results behaving the same way across every one of them. Each task runs in an isolated, on-demand sandbox, and execution tracing records the run so you can compare how different harness and model configurations handle the same job and route each kind of task to the configuration that performs best.

We do not run MHS devices today, and this article does not claim otherwise. What we can say is that the direction Anthropic chose, a standard that any harness reaches through standard protocols, is the same direction UHP takes from the other side: standardize the edges, keep the harness swappable, and let the evidence pick the configuration.

Outlook

Where this goes

The honest summary of MHS on day four is this. It is a well-shaped idea, released early, gated for now, backed by real labs, and surrounded by open questions about safety enforcement, existing protocols, and what "open" will mean once the source is published. If MCP taught agents to use a computer, MHS is trying to wire hands and eyes onto the bench. Watch three things: the open-source release and its license, the first public mapping to ROS 2, OPC UA, or SiLA 2, and whether the safety limits move below software.

For anyone building on agents, the lesson does not depend on any of those. The harness is the actor. Choose it deliberately, measure it per task, and keep the contract above it stable so you can change your mind.

FAQ

Model Hardware Standard FAQ

Keep reading

Related HarnessRouter guides

• What is an agent harness? Definition, anatomy, examples
• The agent harness layer: the agent stack's missing contract
• From model layer to harness layer: AI product infrastructure
• The naming of the Unified Harness Protocol
• The Unified Harness Protocol specification