$ cat wiki/concepts/model-hardware-standard.md
MHS — Model Hardware Standard
Definition
A specification, announced by Anthropic on 2026-08-27 as a research preview, for AI agents to operate physical devices — lab and manufacturing instruments such as microscopes, liquid handlers, robotic arms and plate readers. It is not a model and not a product: it is a standardized driver plus a discovery format, sitting between a device's programmable interface and an agent (source).
The driver exposes a device through "a simple set of primitives — commands like 'read' (for example, 'get temperature') or 'write' (for example, 'set temperature')" and makes it 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".
Three control mechanisms are stated: MCP — Model Context Protocol, the command line interface, and code files (APIs).
Why It Matters
It is the second protocol Anthropic has proposed for the same structural problem, and the first one is the reason to take it seriously. MCP — Model Context Protocol standardised the connection between an agent and software tools; MHS applies the identical move to instruments. The stated failure mode is also identical — "Most devices don't communicate with each other, instead requiring specialists to build bespoke integrations" — and it is the sentence MCP's own announcement could have been written from.
Two properties make it a standard rather than a feature:
- Model-agnostic. "any agent harness can access it using standard protocols, such as the Model Context Protocol."
- Device-agnostic. "MHS works with any device that has a programmable interface."
The natural-language tags are the genuinely new idea. The driver carries tags in which a user writes machine characteristics in prose — the post's example is "the weight of a robot arm, which is important for knowing how to manipulate it safely" — information that "has been stored in paper manuals, on a user's computer, or as tacit knowledge". Users write the tags themselves "or by chatting to an agent that interviews them about their hardware setup", and the driver compiles them into a reference file covering what a device can measure, what can be adjusted, and "what safety limits will be enforced".
That is a claim worth stating plainly: MHS proposes to make an instrument's safety envelope a machine-readable artefact produced by interviewing its operator. Everything downstream — whether an agent can be trusted to drive a laser or a liquid handler unattended — rests on those tags being right, and nothing published says how they are validated.
State of the Art (2026-08-27)
A research preview, opened to an unnamed first group.
| | |---|--- | Announced | 2026-08-27 | Status | Research preview, application-gated | Origin | Collaboration between Anthropic and HHMI Janelia Research Campus | Partner fields named | Biotech, robotics, electronics, quantum computing, manufacturing | Licence | unknown | Specification document | none published | Open-source date | stated as intended, no date The one quantified claim is a pair of duration ranges. Anthropic states integration "typically takes a lab or manufacturing facility weeks, if not months" and that MHS "reduces this integration work to hours or minutes". There is no benchmark, task count, error rate or before/after study behind it (source).
Genentech is the one partner whose work is described in detail: a proof-of-concept automating the BCA protein assay, coordinating a liquid handler, a robotic arm and a plate reader, in standard 96-well microplates with bovine serum albumin at known concentrations as the sample. Genentech states its "ultimate goal is to build autonomous labs". No result is published for the proof-of-concept — not a success rate, not a time, not a comparison against the manual setup it replaces.
Anthropic reports three effects across its early projects — reduced integration time, faster iteration, and help with "live operation of machines and real-time fault detection" — and attaches no figure to any of the three.
One behavioural anecdote is offered in place of a measurement: Claude adjusting a laser, observing the beam through a camera, repeating, and then "packaging what it learned into code files, writing a deterministic script that let it align the laser without having to reason at each step". Recorded as an anecdote because that is what it is — no trial count, no success rate, no baseline.
It arrives alongside a distribution channel. The same day, Anthropic opened 10,000 free and discounted Claude seats for scientists and widened its AI for Science credits beyond biology, at up to $50,000 per project (source). A standard for driving lab instruments and a subsidised population of lab users are the two halves of the same bet, published within hours of each other.
Open Problems
- There is no specification. A "shared specification" announced with no document, repository, version number or licence is at present a description of one. Until it is published, "model-agnostic" and "any agent harness" cannot be checked by anyone outside the preview.
- Nothing published measures anything. Weeks-to-hours is the whole evidential base. This is the same shape as several vendor claims this wiki has recorded and later found unverifiable, and it is worth naming now rather than after.
- The safety limits are self-declared. An agent's authority over a physical device is bounded by a reference file generated from an operator's natural language. Nothing read states who validates a tag, what happens when one is wrong or absent, or whether the enforcement is in the driver, the agent, or the device.
- "Safe" is doing heavy work in the announcement's first sentence. MHS is described as a specification for agents "to safely operate physical devices", while the safety evaluations are stated as something partners will "collaborate to build" — that is, they do not exist yet. The claim precedes the evidence for it by design, which the post is candid about.
- The failure surface is the one this wiki has been documenting all month. Eval Environment Containment records four ways an agent has escaped or misused a software sandbox in 2026, including one where a sandbox known to be leaking was left in service. MHS moves the same class of agent from a container to a liquid handler. Nothing read addresses what a containment failure means when the environment is physical.
- Relationship to Embodied Agents is unstated. MHS drives instruments through a driver abstraction; it is not a policy learned from perception. Whether the two lines converge is not addressed in anything read.
Related Concepts
- MCP — Model Context Protocol — one of MHS's three stated control mechanisms, and the protocol whose pattern it repeats for physical devices
- Agents (LLM Agents) — MHS is an agent tool-access substrate; the harness is explicitly out of scope
- Embodied Agents — the other route to machines, through learned policies rather than drivers
- Eval Environment Containment — the containment questions MHS inherits and does not answer
- Anthropic — origin, and the party publishing every figure on this page