Model Hardware Standard: Anthropic's MHS Preview 2026

The Model Hardware Standard (MHS) is a shared specification, previewed by Anthropic on August 27, 2026, that lets AI agents discover and operate physical devices — microscopes, liquid handlers, robotic arms — through one standard driver interface instead of a bespoke integration per machine.

TL;DR

MHS is in an application-only research preview for scientific labs and advanced manufacturers. It is not open source and not generally available.¹

The pitch is integration time: Anthropic says setups that take "weeks, if not months" drop to "hours or minutes."¹ Carnegie Mellon reported the sharpest version of that — raw instruments to a finished dose-response curve in about eight hours, against the several weeks a vendor-built setup typically takes.¹

MHS is model-agnostic and reachable over standard protocols including MCP, so it is not a Claude lock-in play.¹

What it is not is the first attempt at this. SiLA 2 shipped Release 1.0 on October 2, 2019, the OPC Foundation completed OPC UA LADS v1.0 on December 14, 2023, and an academic agent-to-instrument protocol called LAP was posted to arXiv on June 2, 2026.^{2 3 4} What is new is a frontier lab writing the spec with eight hardware vendors publicly building against it.

What you'll learn

• What MHS actually is, and the primitives its driver exposes
• How MHS relates to MCP — and why it is not "MCP for robots"
• What the six launch partners measured, including the one fault-injection test
• Where the agents failed, in Anthropic's own words
• How MHS compares to SiLA 2, OPC UA LADS, and LAP
• What is gated, what is promised, and what is still unpriced

What MHS is

MHS addresses one problem: every instrument has its own programming interface, and there is no common way to hand an agent control of it safely.¹

It does that with a standardized driver — software that translates between an operating system and a hardware device.

The driver exposes a deliberately small vocabulary. Anthropic describes primitives like "read" (for example, "get temperature") and "write" (for example, "set temperature") that any device can act on.¹

Discovery is the second half. Each device is made discoverable in a standard format, so devices and agents can find each other across a network without a bespoke translator in between.¹

The part that is less obvious is the documentation layer. An agent needs facts about a machine that are not in its code — the weight of a robot arm, for instance, which matters for handling it safely.¹

That knowledge has historically lived in paper manuals or in a technician's head. MHS driver tags let a user write it in natural language, either directly or by chatting to an agent that interviews them about the setup.¹

From those tags the driver generates a reference file describing what a device can measure, what can be adjusted, and what safety limits will be enforced.¹

Control then happens through three mechanisms: MCP, a command line interface, and code files (APIs).¹

The code-file path matters more than it sounds. When a task runs long, or needs to move faster than the model can reason, the agent chains driver commands into a script and lets the hardware execute without a model turn per step.¹

Anthropic's own example: Claude nudged a laser, watched the beam move through a camera, repeated until it understood the relationship, then wrote a deterministic script that aligned the laser in a single command.¹

MHS and MCP are not the same layer

The easy shorthand is "MCP for hardware." It is close enough to be useful and wrong enough to be worth correcting.

MCP, which Anthropic open-sourced on November 25, 2024, standardizes how a model reaches tools and data sources.⁵ MHS standardizes how a device describes and exposes itself, along with the safety envelope around it.

They compose rather than compete: MCP is listed as one of three ways an agent reaches an MHS device, alongside the CLI and code files.¹

The practical difference is the reference file. An MCP server tells an agent what it can call. An MHS driver additionally tells it what the machine physically is and what limits will be enforced regardless of what the agent asks for.

That is the same separation of concerns we covered in how agents discover MCP servers and skills in the first place — discovery, invocation, and enforcement are three jobs, and conflating them is how agent stacks get brittle.

What the partners actually measured

Six partners published results. The numbers are integration-time and reliability numbers, not agent-capability benchmarks — a distinction worth holding onto.

The QuEra result is the one to read closely, because it is the only one that states a human-operator baseline for the task itself rather than an integration-time comparison.

A four-person team — laser-systems engineer, software engineer, algorithms specialist, tester — had spent several months building a bespoke relock script. It worked about 58% of the time and took around 150 seconds per attempt.¹

QuEra pointed Claude at the same problem through MHS. The loop ran four roles, each a fresh Claude instance: one proposed a hypothesis, one wrote it into the script, one ran it against the live laser and logged every step, one read the logbook and decided what to change next.¹

That cycle repeated hundreds of times overnight. By morning, recovery took about six seconds at 96% in the development run; a later blind test over 700 trials recovered the correct lock 695 times, for 99.3%.¹

Two details keep this honest. A human at the bench takes 5 to 10 minutes for the same recovery, so the comparison is favourable but the human number is QuEra's own estimate.¹ And the end product was a deterministic, inspectable script that runs in production without an agent in the loop.¹

The mechanism is legible: Claude replaced a linear sequence with a decision tree, reading instruments and touching only the controls the specific disturbance implicated, rather than working through all of them the way an operator must.¹

On a separate task — tuning 12 interdependent PID parameters — Claude took a specialist's standing tune from 15.7 mV of residual error to 1.55 mV over 363 experiments and 16 unattended hours.¹ Over a 19-hour run its parameters never lost lock, against roughly 1.6 unlocks per hour for the expert tune.¹

The safety result nobody is quoting

Of the six partner reports, only Carnegie Mellon's includes a fault-injection test — and it is the most interesting number in the release.

The team artificially induced six conditions: missing plate, rotated plate, reader busy, disconnected camera, unreachable device, and active emergency stop. The system blocked all six before any device moved.¹

That is a small test — six conditions, one rig — but it is the right shape of test, and it is the kind of evidence that agent-hardware claims will live or die on.

The same run produced an unprompted correction. The agent evaluated its dose-response curve, found the fit too poor to accept (R² below 0.9, driven by saturation at the top of the range), discarded the plate, and reran with the top concentration cut from 200 µg/mL to 100 µg/mL. The second run fit at R² above 0.98, with no human input.¹

CMU's own next steps are the tell: more safety checks, responsiveness monitoring, and refined protocols for when human approval is required on high-risk decisions.¹ Nobody involved thinks this is finished.

For readers tracking the containment side of this, it rhymes with the kill-switch and containment patterns already being built for software agents — except a bad write here moves a robot arm.

Where it broke

Anthropic published the failures, which is the part most coverage skipped.

At Genentech, Claude hit runtime errors caused by bubbles in a viscous protein sample. Its default instinct was to retry in the same well with different parameters — which agitated the fluid further and made more bubbles.¹

The model did not understand the physics of the failure. Researchers had to tell it the error code meant physical bubbles, that it needed a clean well and fewer mixing cycles. Once told, it held that context for the rest of the run, and the lesson was codified into a reusable skill.¹

At QuEra, Claude could not troubleshoot physical hardware problems at all — its understanding of the rig was programmatic, not physical.¹ It also stopped frequently to wait for human confirmation on anything it judged slightly risky, sometimes pausing overnight for approval.¹

Anthropic's framing of that is fair: "an overly cautious agent is preferable to one that is not cautious enough."¹

Anthropic states the general limit plainly. Claude learns about the physical world through text and images, so its spatial and physical reasoning have limitations that still require expert oversight.¹

This is a familiar ceiling. It is the physical-world analogue of what OSWorld-2 exposed about long-horizon computer use: agents are strong at the reasoning and weak at the parts that need a model of what is actually happening.

MHS is not the first agent-to-instrument standard

This is the claim most coverage got loose with, so it is worth being precise.

Lab interoperability standards predate MHS by years. SiLA 2 reached Release 1.0 on October 2, 2019 and is generally described as the most mature open standard for laboratory instrument connectivity, built on gRPC over HTTP/2 with mDNS-based discovery.^{2 6}

The OPC Foundation completed OPC UA LADS v1.0 on December 14, 2023, after a four-year development phase, as an official companion specification for laboratory and analytical devices.³

And an explicitly agent-oriented protocol beat MHS to publication. LAP — the Lab Agent Protocol — was submitted to arXiv on June 2, 2026, roughly three months before the MHS preview.⁴

So what is genuinely new?

The LAP authors frame the problem in a way that is worth borrowing. An agentic ecosystem has three edges: MCP standardizes agent-to-tool, Google's A2A standardizes agent-to-agent, and neither models the agent-to-instrument edge, where operations are stateful, safety-critical, exclusively owned, and produce measurements carrying units and uncertainty.⁴

The critique of the older standards is not that they lack capability descriptions. It is that they were built for deterministic software clients rather than probabilistic, goal-directed agents — telling an agent what an instrument can do, without expressing what is safe to do right now.^{4 6}

MHS's natural-language tags and generated safety-limit reference file are a direct answer to that gap. So are LAP's signed InstrumentCards and safety-fence handshakes.⁴ The design pressure is real and more than one group felt it.

Notably, LAP positions itself as encapsulating rather than replacing SiLA 2 and OPC UA.⁴ Anthropic makes no equivalent statement about how MHS relates to the incumbent standards, which is the most conspicuous gap in the announcement.

What Anthropic brings that the others do not is distribution. Eight hardware vendors and platforms are publicly building MHS support:

• Amazon Web Services — through Strands Robots, with a private pre-release package for preview participants¹
• Automata — MHS support in its LINQ lab automation platform¹
• Danaher — exploring MHS for smart instruments and autonomous labs¹
• Doosan Robotics — testing with robotic arms, including multi-robot coordination¹
• MBF Bioscience — a driver for ScanImage, which runs laser-scanning microscopes in hundreds of neuroscience labs¹
• QIAGEN — a proof-of-concept on its QIAsymphony Connect purification platform¹
• Tecan — support for its Fluent liquid handling platforms¹
• Universal Robots — early access, with support planned¹

Hugging Face is adding MHS support to LeRobot, and Raspberry Pi is enabling integration across several products after tests with a Camera MHS Driver.¹

That list, not the spec, is the actual news. A standard with a frontier model behind it and eight vendors implementing it is in a different position from a standard with better ergonomics and no distribution.

What is gated, and what is unpriced

MHS requires a device with a programmable interface. Anthropic says it does not yet work with hardware that lacks one, and is working with manufacturers to build drivers in.¹

Access is by application through modelhardwarestandard.com, limited at launch to scientific research labs and advanced manufacturers.¹

Pricing is not publicly disclosed as of September 3, 2026. Anthropic's announcement does not state a cost for MHS, and the standard is not yet open source.

One partner did flag the running cost. The University of Washington researcher noted that running an agent continuously over long monitoring windows has compute costs that need to be weighed against the researcher time saved.¹

Anthropic's stated sequence is: build safety evaluations with launch partners, develop a physical safety roadmap, then open-source the standard and publish research-preview findings as deployment guidance.¹ No date is attached to any of that.

Bottom line

The interesting thing about MHS is not that it exists — three prior standards already tried to solve instrument interoperability, and one of them explicitly targeted agents three months earlier.

It is that Anthropic shipped the spec together with eight vendor commitments and six partners willing to publish numbers, including the failures. QuEra's 58% to 99.3% is a real result. So is Claude making more bubbles by retrying in a dirty well.

Read the results for what they measure. These are integration-time and reliability wins on narrow, well-instrumented tasks, achieved with expert supervision and, in QuEra's case, distilled into a deterministic script that runs without an agent at all. That last detail is the most transferable lesson in the release: the agent's job was to find the controller, not to be it.

The open question is the one Anthropic named itself. A model that learns the physical world through text and images will keep mistaking physics for software bugs, and MHS moves that failure mode from a chat window to a robot arm. The safety evaluations promised before open-sourcing are the part worth waiting for — and CMU's six blocked fault conditions are, so far, the only published evidence that the envelope holds.