MHS: how AI agents connect to physical equipment

A lab can have a programmable liquid handler, a robotic arm and a plate reader, yet still depend on someone carrying a plate between them. Making each instrument work is one problem. Getting the whole sequence to finish correctly is another.

Anthropic announced the Model Hardware Standard (MHS) on 27 August 2026. MHS describes a common way for AI agents to operate physical equipment. The official project site identifies its origins with HHMI Janelia Research Campus and describes an application-only research preview.

The useful question is what a shared device contract would let a researcher reuse—and which judgments still depend on the people who understand the experiment.

How MHS connects an agent to a device

Anthropic describes discoverable drivers with read/write operations and descriptive tags. A generated reference file describes measurable properties, adjustable settings and enforced limits. Agents can use the Model Context Protocol (MCP), a command line or code; command sequences can execute without model reasoning at every step. Anthropic also describes MHS as model-agnostic. This is the announced mechanism, rather than a published driver schema.

Read operations inspect device state; write operations request a change. A driver translates the operation into whatever control mechanism the instrument supports. Its description also needs to explain what an observation means. A temperature value without units, a completion flag without a definition, or an error without recovery context leaves the agent guessing.

That makes the description part of the operational contract. Our interpretation is that a useful contract must explain both the permitted action and the observable result that establishes whether it finished. Discovering a device is only the beginning of coordinating it.

Where MCP fits

The MCP architecture guide describes an AI application connecting to servers that expose tools, resources and prompts. It separates the message protocol from the transport and leaves the application’s use of the model to the host.

For this use case, MCP can carry the agent’s request and the result. MHS supplies the device-oriented description and control conventions announced above. These responsibilities complement each other: a delivered tool call does not itself establish that a plate arrived at its destination.

A developer therefore needs to distinguish the communication result from the physical observation. The program might receive a successful response while still needing a sensor reading, an image or a device status to decide whether the next step is appropriate. This is a design implication, not a claim about an unpublished MHS field.

Explanatory workflow — Qentrah interpretation

From an approved goal to an observed result

1. 1Researcher defines the approved goal and required observations
2. 2Agent inspects device descriptions and current state
3. 3Driver translates the requested operation for the instrument
4. 4Instrument reports state and observations
5. 5Agent checks the outcome before choosing the next step

Walk through a plate handoff

Illustrative workflow. The following example is Qentrah’s explanation of the coordination problem. It specifies no MHS method names and reflects no hardware test performed by Qentrah.

Imagine moving a prepared plate from a liquid handler to a reader. The researcher first defines the approved sequence and the observations required at each handoff. The agent obtains the available device descriptions and examines the current state.

Before requesting a transfer, it needs an observation that the liquid handler has finished and the reader can receive the plate. After requesting the move, it needs evidence that the plate is seated. Only then should the next measurement proceed.

A fixed delay is a weak substitute for those observations. If the first instrument takes longer than expected, waiting the usual interval can still leave the second action too early. A completion signal helps only when its meaning and freshness are clear.

Suppose the network connection drops after a transfer request. The operator now has an uncertainty problem: was the request rejected, still running, or already completed? Repeating it immediately could repeat a physical action. A useful recovery path would inspect the actual state and resolve that uncertainty before choosing a retry. That is an evaluation scenario we propose, not an observed MHS failure.

What the early failure teaches

In Genentech’s case study, retries of a bubble-related pipetting failure worsened the bubbles. Researchers explained the physical cause and supplied recovery guidance, which was then retained in reusable skills.

The lesson is that an error message and a sensible-looking retry can still produce a poor physical outcome. Coordinating tools does not automatically supply knowledge of the sample or the cause of a fault.

For an evaluation, we would separate completion, physical correctness and experimental usefulness. Did the sequence finish? Did the devices actually perform the intended operations? Does the resulting measurement answer the research question? Each requires its own observable evidence.

The reported example motivates those questions. It does not give Qentrah an independently measured reliability rate. We have reviewed the published account and have not operated an MHS-connected instrument.

Qentrah’s view: the contract is the long-term opportunity

Our assessment is that MHS’s most useful potential lies in reusable device contracts. An agent demonstration can show that one workflow succeeds. A well-specified contract could make the next integration easier to understand, test and transfer between teams.

We would judge that promise by the quality of the eventual public artifacts: precise state definitions, explicit units, documented refusal behavior, recovery examples and tests that manufacturers can run against their own drivers. A model-independent interface also needs evidence that different agents can interpret the same device description consistently.

Natural-language descriptions can help expose knowledge that code leaves implicit. For enforcement and verification, teams still need conditions that can be checked. The important practical question is which limits the system actually enforces, where enforcement occurs, and what evidence is recorded when an operation is refused.

A limited first evaluation should answer a concrete operational question, such as whether an interrupted handoff can recover with a trustworthy record of what happened. That provides more useful evidence than a polished demonstration of the successful path alone.

What to examine before joining the preview

The MHS preview site invites access applications while partners develop safety evaluations and practices ahead of planned open-sourcing. The linked announcement supplies no runnable SDK or public driver schema.

For a preview discussion, these are the questions we would bring:

For a preview discussion, bring one device and a specific recovery scenario. Ask the project team which observations establish that each operation completed, and which records would let another researcher review the result.