Anthropic's Model Hardware Standard took a laser relock from 58% to 99.3%
Contents
On August 27, Anthropic announced a research preview of the Model Hardware Standard (MHS), a shared specification for AI agents to operate physical devices.
It targets research and manufacturing equipment such as microscopes, liquid handlers (robots that move exact volumes of liquid) and robotic arms, and an agent drives several of them at once.
The spec is model-agnostic, so any agent harness can reach it over a standard protocol like MCP.
Development started as a collaboration between Anthropic and HHMI Janelia Research Campus, a neuroscience research campus.
For now it is an application-only research preview, and neither the specification nor a driver implementation is public.
Open sourcing comes after Anthropic and its partners build out the safety evaluations.
What MHS standardizes
Every device has its own control interface to begin with, and until now there was no standard way to wire them together.
Even once they are connected, there is no common format for devices to exchange data. A way to let an agent operate them safely is further still from any standard.
MHS unifies that layer with a standard driver. It translates between the OS and the device, and its commands come down to simple primitives like read and write. Reading a temperature is a read, setting one is a write.
The driver publishes device information in a standard format. Agents and devices find each other across the network, with no bespoke translator program in between.
The example Anthropic gives is the weight of a robot arm: information you need to move it safely, but which code alone may not reveal. If anything, this kind of information has lived in paper manuals or in an operator’s head.
The MHS driver takes that kind of information as natural-language tags. Users can fill the tags in themselves, or have an agent interview them about their hardware setup and write them.
From those tags the driver generates a reference file, covering what the device can measure, what can be adjusted, and which safety limits it will enforce.
When an agent actually drives a device, it goes through MCP, the command line interface, or code files (APIs). Combine the three and an agent can orchestrate several devices from a single line of code.
graph TD
A[AI agent] --> B[MCP]
A --> C[Command line]
A --> D[Code files/API]
B --> E[MHS driver]
C --> E
D --> E
E --> F[Liquid handler]
E --> G[Robotic arm]
E --> H[Plate reader]
E --> I[Microscope]Per-device safety limits are enforced by the driver.
HHMI Janelia, the co-developer, uses this on a two-photon microscope. An agent cannot push the laser hard enough to bleach the fluorescent molecules and damage the sample.
Where MCP fits
| MCP | MHS | |
|---|---|---|
| Connects to | Software tools and data | Physical devices with a programming interface |
| Primitives | Tools and resources a server exposes | read and write |
| Device information | Returned by the server implementation | Reference file generated from natural-language tags |
| Safety enforcement | Left to implementors, not the protocol | Driver enforces per-device limits |
| Call path | Client and server over JSON-RPC | MCP, command line, or code |
MCP, then, is one of three ways to reach MHS, and discovery, safety limits and reference-file generation are handled by the MHS driver behind it.
The MCP specification 2026-07-28 defines the base protocol as “stateless, self-contained requests” and leaves security to implementors rather than enforcing it at the protocol level. I covered that revision in MCP 2026-07-28 drops the initialize handshake and session IDs.
Freezing an agent’s exploration into a script
Anthropic writes that during MHS testing, Claude handled hardware the way a scientist would: exploring it.
Nudge the laser, check on a camera how the beam moved, decide the next adjustment from that. Then fold what it learned into a code file, write a deterministic script that aligns the laser without reasoning through every step, and run the whole thing as one command.
QuEra Computing, which builds neutral-atom quantum computers, did exactly this for laser relocking.
In that architecture a laser has to hold its frequency to roughly one part in a trillion. Temperature, vibration or a pressure shift can knock that “lock” loose, and the computation goes wrong.
QuEra already had an automated recovery script before MHS. A laser-systems engineer, a software engineer, an algorithms specialist and a tester spent several months building it, and it reproduces the human procedure step for step. It worked about 58% of the time and took around 150 seconds per attempt.
Handing the same problem to Claude through MHS split the agent loop into four roles.
One proposed ways to make recovery faster and more reliable, one wrote the change into the script, one ran it against the live laser and logged every step, and one read the log and decided what to change next. Each role ran as a separate Claude instance.
The cycle repeated unattended, hundreds of times through the night, and by morning recovery took about six seconds at a 96% success rate.
Anthropic’s account is that Claude got there by rebuilding the script as multi-stage conditional branching.
The original script traced the same sequence from the top no matter what disturbance came in. Claude’s version reads each instrument first, builds up conditions from those values, and picks what to move based on the specific disturbance.
If the frequency has barely drifted, most controls will not change anything, so the script touches one or two and leaves the rest alone. A human operator ends up checking all of them just to be sure they are right.
The finished script was then run without any agent, against the same set of induced disturbances. It recovered the correct lock 695 times out of 700, a 99.3% success rate, taking 10 to 14 seconds when the frequency had jumped far and 0.9 to 5.4 seconds for the easy cases. A human at the bench needs 5 to 10 minutes.
QuEra then pointed the agent at the quality of the lock itself.
This is knob-turning work: how far you can suppress the laser’s jitter. The control loop that holds the laser on its target frequency has 12 interdependent PID parameters (the proportional, integral and derivative coefficients), and you turn them to squeeze the jitter down. Less jitter means more accurate quantum operations and fewer dropped locks.
Measuring that jitter properly means capturing an oscilloscope trace and running a Fourier transform on it. Doing that after every one of 12 adjustments is not realistic by hand, so a specialist tunes against the approximation the servo reports.
With the specialist’s tune in place, jitter measured 15.7 mV. Claude captured a trace and measured the jitter after every change, and over 363 experiments and 16 unattended hours brought it to 1.55 mV.
To check that, the specialist retuned the same laser from scratch and both settings went to a phase noise analyzer (an instrument that measures signal jitter frequency by frequency). Across the band they came out about the same, except at a roughly 220 kHz resonance where the manual tune left about a thousand times more jitter than Claude’s.
Over a 19-hour run Claude’s settings never lost the lock. The specialist’s settings dropped it about 1.6 times an hour.
Unlike the relock script, though, this tuning workflow keeps the agent in the loop. When conditions change, it moves the parameters again on the spot.
Numbers partners reported
| Organization | Task | Result |
|---|---|---|
| QuEra Computing | Laser relock on a quantum computer | 695 of 700 recoveries (99.3%) with no agent involved. The previous script managed 58% at about 150 seconds |
| Carnegie Mellon University | Dose-response curves by serial dilution | Drivers written from scratch across three incompatible control PCs. About 8 hours to integrate (weeks with a vendor build), experiments about 3x faster |
| Genentech (drug discovery) | Automating the BCA protein assay | Explored flow rates on its own and converged on ~140 µL/s for water and 10 µL/s for viscous protein solution (BSA), at RMSE 0.016 and 0.181 |
| HHMI Janelia | Integrating a two-photon microscope rig | Seven vendor programs collapsed into one shared-memory state table. Adding a camera takes minutes, starting an experiment went from seven steps to one click |
| University of Washington (de novo protein design) | Remote monitoring, qPCR stop calls, arm coordination | Six instruments connected in under a week, driver writing included |
| Tetsuwan Scientific (lab automation) | qPCR workflow and compiler tuning | 9,143 dispenses tested; multi-dispense precision prediction beat the manufacturer spec by about 12% (31 of 45 runs, sign test p ≈ 0.001) |
CMU’s robotic arm runs when you drop a job file into a watched folder. The liquid handler is driven from an old Windows scripting interface. The plate reader has no way to be operated from a program at all, only buttons on a screen. The control PCs are split three ways as well.
Writing one MHS driver per device turns each of them into a list of states (plate at position 3, sample at 25 °C) and available operations (aspirate, shake).
From Claude’s side all three run on the same read and write. Drivers plus the orchestration layer above them took about 8 hours, against the several weeks a vendor-built setup usually needs.
The dose a drug works at is found by diluting a strong solution at a fixed ratio and measuring the response at each concentration. That gives a curve from onset through saturation.
On the first run the top concentration was too high, the upper end saturated, and the fit fell short of the R² 0.9 bar. Claude judged that itself, discarded the plate, dropped the top concentration from 200 µg/mL to 100 µg/mL and measured again.
The second run came back above R² 0.98. No human input at any point.
CMU also induced six conditions on purpose: missing plate, rotated plate, reader busy, disconnected camera, unreachable device, active emergency stop. All six stopped before any device moved.
Tetsuwan Scientific rents out an automated biology lab over an API.
The qPCR reagent (a reaction that copies DNA while measuring how much there is) is a soap-like viscous liquid that foams when pipetted. Bubbles throw the volume off by however much air they take up, and that distorts the final reading.
A camera and computer vision were watching for foam, and bubbles showed up in a tube held by the robotic arm. The arm has no way to get rid of them.
ResearchOS scanned the network instead, found a centrifuge among the MHS-connected devices, and Claude proposed a brief low-speed spin over Slack before issuing the command to the centrifuge itself.
The protocol only specifies the force required. For a machine that accepts rotor speed instead, Claude divides by the rotor radius. Which centrifuge was used never enters the protocol.
Vendors adding support
| Vendor | Product | What they are doing |
|---|---|---|
| Amazon Web Services | Strands Robots | Private pre-release package for research preview participants |
| Automata | LINQ | Adding MHS support for instrument error handling in autonomous labs |
| Danaher | Smart instruments, autonomous labs | Exploring scope with Anthropic |
| Doosan Robotics | Robotic arms | Testing MHS for automated QA and multi-robot coordination |
| MBF Bioscience | ScanImage | Building an MHS driver for laser-scanning microscopy software |
| QIAGEN | QIAsymphony Connect | Working proof-of-concept on its nucleic acid purification platform |
| Tecan | Fluent | Adding support so agents can operate its liquid handlers directly |
| Universal Robots | Robotics platform | Early access, support planned |
Danaher is a holding company for measurement instruments, Automata does lab automation, and MBF Bioscience writes microscopy software. No consumer hardware makers on the list.
Current limits
At Genentech, foam during liquid handling returns an error code. Claude retried in the same well with different parameters, agitated the liquid further and made more bubbles.
Once it was told the cause was physical, and shown the fix of moving to a clean well and reducing mix cycles, Claude kept doing it that way. Genentech turned this into reusable skills so Claude picks sensible defaults for liquids of different properties.
At QuEra, Claude could not handle physical hardware faults. It knows the rig as a program, not as an object, so it cannot tell what is going wrong physically.
It also stops and waits for human confirmation before anything it judges even slightly risky, which left overnight experiments sitting on an approval until morning. An overly cautious agent still beats an insufficiently cautious one, QuEra writes.
The team also reports having to supply a lot of context about what the experiment was for and how Claude should run it.
What Claude has to judge with is text and images. The weight or the feel of a machine does not reach it, and spatial and physical judgment tops out there. Expert oversight is still required, Anthropic writes.
The standard has its own limits. Hardware without a programming interface is still out of scope, and Anthropic says it is working with those manufacturers to build drivers in.
That said, CMU’s plate reader has no API and MHS drove its GUI the same way a person would. Verification there rests on whatever is visible on screen.
Can you use it on your own hardware
Hugging Face is adding MHS support to LeRobot, its robotics library, and Raspberry Pi is rolling MHS integration across several products after successful tests with its Camera MHS Driver. Extending the standard to the devices developers actually build on is the next phase.
The University of Washington demo also ran MHS on an open-source LeRobot arm, handing plates to a liquid handler without a collision.
Consumer IoT devices are not on the research preview list.
Products like SwitchBot, which ship a cloud API and an official MCP server, already run on MCP alone, as covered in SwitchBot ships an official CLI with an MCP server and MQTT streaming. MHS picks up the layer beneath that, standardizing drivers that differ per device and carrying physical characteristics like weight through to the agent.
Access is by application through a form at modelhardwarestandard.com, and that page carries only an overview, the application link and a link to Anthropic’s announcement.
Anthropic says findings from the research preview and guidance on deploying safely will land alongside the open source release. Neither the site nor the announcement currently links to an MHS specification, a driver format, code samples or a repository.