Rohit Ghumare · August 27, 2026 · 10 min read

The Model Hardware Standard: Read, Write, and the Plate That Must Be There

On August 27 Anthropic opened a research preview of the Model Hardware Standard, a specification for agents that operate lab and factory equipment: liquid handlers, robotic arms, microscopes, centrifuges. The sentence in the announcement worth reading twice is not about model intelligence. It is about a plate. In a case study the team induced six faults, a missing plate, a rotated plate, a busy reader, a disconnected camera, an unreachable device, an active emergency stop, and the system blocked all six before any device moved. That describes a protocol decision, not a model capability: the check runs in the driver, against declared device state, before a write is allowed to happen. MCP standardized the verbs an agent can call. A2A standardized the task between two agents. MHS standardizes the state of a thing that can break.

Three protocols, three nouns

Every agent protocol standardizes one noun, and you can read its design from which noun it picked. MCP picked the tool: a server publishes a schema, the client calls it, the server validates the arguments and returns a result. When that goes wrong you get a bad result, and the cost is a few thousand tokens and a retry. A2A picked the task: a state machine with submitted, working, input-required, and a set of terminal states, passed between two agents that do not share a runtime. When that goes wrong you get a stuck task, and the cost is a timeout and a human looking at a dashboard.

MHS picked the device. A device has state (a plate is or is not at position 3, a lid is open or closed, the block is at 37 degrees) and it has procedures (aspirate, spin, expose). When a device write goes wrong, the cost is a sample, a bleached fluorophore, or a robotic arm driven into a plate reader that was still busy. The unit of the standard moves with the cost: MCP validates the call, A2A validates the transition, MHS validates the precondition. That is the whole shape of the thing, and it explains why the announcement leads with faults rather than benchmarks.

The three are not rivals. Anthropic lists MCP as one of the three surfaces through which an agent reaches an MHS driver, so in practice a model will call a device the way it calls any other tool. What changes is what sits behind the tool: not a function that trusts its arguments, but a driver that knows what the world currently looks like and refuses writes the world does not allow.

The driver is the standard

The announcement is unusually plain about what MHS is: "a standardized driver: software that translates between a computer's operating system and a hardware device." Not a new transport, not a new agent runtime. A driver, with three properties the model can rely on.

First, a small vocabulary. The driver exposes "a simple set of primitives," commands like read ("get temperature") and write ("set temperature"), "that any hardware device can understand and act on." A centrifuge, a microscope, and a liquid handler do not share an API, but they can all answer a read and accept or refuse a write. Second, discovery. The driver "makes each device discoverable in a standard format, so that devices and agents can find each other and communicate across networks without needing a bespoke 'translator' program in between." That is the part that turns a lab full of vendor SDKs into something an agent can enumerate. Third, a reference file the human writes in prose. The driver "contains tags that let the user write this information directly in natural language," either by hand or "by chatting to an agent that interviews them about their hardware setup." The reference file describes "a device's general characteristics, such as what it can measure, what can be adjusted, and what safety limits will be enforced."

Read that last sentence as three columns. What it can measure is the read surface. What can be adjusted is the write surface. What safety limits will be enforced is the set of writes the driver will refuse regardless of what the model asks for. In MCP terms, tools/list tells the model what it can call; the MHS reference tells the model what the device is, what state it holds, and where the driver will say no. The announcement frames the device as states, conditions like a plate sitting at position 3, and procedures, operations like aspirating, and the reference file is where those get named.

The line that made me read the whole thing twice is from a case study run with Carnegie Mellon. To test that the system "would operate safely and correct itself like a human operator would," the team "artificially induced six different conditions: missing plate, rotated plate, reader busy, disconnected camera, unreachable device, and active emergency stop. The system correctly blocked all six before any device moved." Six faults, six refusals, zero motion. The figure below is that sentence as a machine you can drive.

Six faults, zero moves

The interesting property of that figure is where the check lives. The model still decides what to do: transfer 50 microliters from A1 to B1, load the plate, spin it. It no longer decides whether the world allows it. The plate is either at position 3 or it is not, the emergency stop is either latched or it is not, and those facts gate the write inside the driver, at the last moment before a motor turns. A model can be confidently wrong about the deck layout and the arm still does not move.

Compare that with what a tool server does today. An MCP server validates that your arguments match the schema. It does not know, and cannot know, whether the plate you named is actually on the deck. A2A validates that a task moves from working to completed and not from canceled back to working. Neither validates the world. MHS makes the world part of the contract: the reference file declares the states and the limits, the driver reads the states before it honors a write, and the refusal is a normal protocol response the agent can reason about, not an exception in a vendor SDK.

There is a second loop, and the announcement is careful to keep it separate. During the case study "Claude encountered several unexpected errors, including tip pickup failures and fluid detection errors, but managed to recover on its own," which the team calls "a capability that current scientific instruments mostly lack." So two loops: a fast, deterministic refusal loop in the driver that never lets a bad write through, and a slow, judgment-bearing recovery loop in the model that decides what to try next after a tip fails to seat. The design does not ask the model to be the interlock. It asks the driver to be the interlock and the model to be the operator.

One quote from a researcher in the announcement says why that division matters in practice: "Because MHS enforces device-level safety limits, I don't need to worry about the agent accidentally using excess laser power, for example, which risks bleaching the fluorescent molecules and degrading the sample." The limit is a number in the reference file. The agent can request forty percent. The driver answers with the ceiling.

Three surfaces, one driver

An agent needs a way to reach the driver, and the announcement names three: "MCP, the command line interface, and code files (APIs)." The reason for three is timing. A model reasoning turn is seconds long. A control loop that watches an incubator and moves a plate the moment it hits temperature may need a read every second, and a camera capturing ten frames does not want a language model between each frame. So "when the agent needs to execute long-running tasks or operate devices faster than its online reasoning would allow, it can chain together driver commands from one or more devices in code files." The three surfaces "work together to enable orchestration across multiple devices via a single line of code."

The important word is driver, singular. Whether the write arrives as an MCP tool call, a shell command, or a line in a script the agent wrote, it hits the same validator with the same reference file. The surface changes how fast the agent can issue calls and how much of its own judgment sits between them. It does not change what the device will refuse. That is the property that lets you hand an agent a script surface at all: batching does not bypass the interlock.

The second figure compiles a sentence into calls and shows the two decisions the surfaces force: which writes wait for a human, and when a loop is too fast for a reasoning turn.

Who is writing drivers

A device standard is only as real as the drivers behind it, and this is where the announcement is concrete. Tecan is adding MHS support to its Fluent liquid handlers. MBF Bioscience is building a driver for ScanImage, the microscopy control software. Doosan Robotics is testing MHS on its robotic arms and Universal Robots has had early access. Automata is adding support to LINQ, its lab automation platform, and AWS says it will support MHS through Strands Robots. QIAGEN is experimenting and Danaher is exploring. Two names outside the lab matter more for readers of this site: Hugging Face is adding MHS support to LeRobot, its open robotics library, and Raspberry Pi is enabling integration. If those two land, the standard reaches hobby arms and single-board computers, not only instruments with six-figure price tags.

The origin is a two-person collaboration: Alek Kemeny on Anthropic's Beneficial Deployments team and Arco Bast, a postdoctoral scientist at HHMI Janelia Research Campus. The device list in the announcement reads like Janelia's floor plan: liquid handlers, robotic arms, microscopes, plate readers, thermocyclers, cameras, centrifuges, incubators, galvanometer mirrors, photomultiplier detectors, translation stages, lasers. The standard grew out of one lab's instruments, which is the right way for a device standard to grow, and also the reason to read the partner list before assuming it covers your bench.

What is not public yet

The specification is closed during the research preview. Access is by application at modelhardwarestandard.com, the stated goal of the preview is to "build safety evaluations and develop best practices for AI systems operating physical equipment, ahead of making the standard open source," and Anthropic says that when it open-sources MHS it "will release findings from the research preview as part of our guidance for deploying the standard safely." So what you can read today is a design, not a wire format, and the figures above are drawn from the design.

The open questions are the ones any protocol reader would ask. What does the discovery format look like on the wire, and is it a manifest a crawler can index the way a server card is meant to work for MCP? Who signs the reference file, and can an agent that has write access to the filesystem rewrite the safety limits it is supposed to be bound by? Are approvals in-band, a protocol state the way A2A has input-required, or out-of-band in a vendor console? How does an MHS procedure compose with an MCP Task when a spin takes sixty seconds and the model wants to do something else meanwhile? None of that is in the announcement. It will be in the spec, and the spec is what to read when it opens.

Why the timing matters

The preview opened the day after OpenAI published its report on models that escaped an evaluation sandbox and reached third-party systems, and four days before Anthropic's own post on hardening evaluation environments after incidents of its own. Both are about agents acting past the boundary someone thought they had drawn. MHS is a statement about where to draw the boundary when the other side of it is physical: not in the prompt, not in the model's judgment, but in a driver that reads the plate before it moves the arm. Whether that holds up is exactly what a research preview is for.

What to do with this

If you build agent infrastructure, the design transfers even if you never touch a centrifuge. Model anything with side effects as state plus procedures, and write the states down where the agent can read them. Split reads from writes at the primitive level, mark the writes that cannot be undone, and gate those on a person. Put preconditions in the thing that executes, not in the instructions the model was given; instructions are advice, a driver is a wall. Give the agent a batch surface for loops and make sure batching hits the same validator. And write the reference file in plain language, versioned next to the file that tells the agent how you work, because the announcement's best idea is that the human describes the limits once and the machine enforces them every time.