Anthropic opens a research preview for AI-run lab hardware

Anthropic has opened a research preview of the Model Hardware Standard (MHS) — a shared specification that lets AI agents operate physical lab and manufacturing hardware directly: microscopes, liquid handlers, robotic arms, laser rigs on a quantum computer. It's rolling out first to a small group of research labs and manufacturers, built with HHMI Janelia Research Campus, with early testing at Genentech. The pitch is direct: agents that already reason through multi-step software tasks should reason through multi-step physical ones too, given a safe, standardized way to touch the hardware.

The integration bottleneck

Anyone who has spent time near automated lab equipment knows where the real friction lives. It's rarely the assay design — it's getting a liquid handler, a robotic arm, and a plate reader to speak to each other. Each device ships with its own programming interface, so wiring up three instruments usually means a specialist writing bespoke glue code, then more glue code to let an AI system call any of it safely. Anthropic says this integration work typically takes a lab weeks, sometimes months, per facility. That's the bottleneck MHS targets — not adding more intelligence to the loop, but removing the plumbing tax that keeps intelligence from reaching it.

What the driver actually does

At the center of MHS is a standardized driver — software that translates between an operating system and a device. It exposes hardware through a small set of primitives, essentially "read" (get temperature) and "write" (set temperature), that any programmable device can implement. Devices become discoverable in a standard format, so agents and hardware find each other over a network without a bespoke translator in between.

The harder problem is knowledge that never made it into code: the weight of a robot arm, a safety limit, what a given dial controls. MHS handles this with natural-language tags — a user, or an agent that interviews the user, describes the device once, and the driver compiles that into a reference file the agent reads before it touches anything. Control then runs through three layers: MCP for interactive reasoning, a command-line interface, and compiled code files for steps that need to run faster than an agent can reason about them.

Before MHS, every device gets its own custom integration. The driver collapses that into one shared read/write layer between the agent and the hardware.

Genentech's proof of concept

Genentech tested MHS on the BCA protein assay, a standard measurement of total protein concentration spanning a liquid handler, a robotic arm, and a microplate reader. In an early run, Claude used one generic flow rate for both a plain aqueous reagent and a viscous, foaming BSA protein solution — the viscous sample bubbled, corrupting the transfer. Told to optimize rather than just execute, Claude ran a closed loop: set a flow rate, transfer dyed liquid, read absorbance, score its own transfer against an expert baseline, adjust, repeat. It converged on roughly 140 µL/s for water and 10 µL/s for the viscous BSA, then compiled the working procedure into a deterministic script so the tuned loop wouldn't need to re-reason on every run after that.

Why this is worth watching

Two design choices stand out to me. First, the three-tier control model — MCP for exploration, code files for repetition — mirrors a pattern I rely on in production agent systems: let the model reason expensively once, then compile the result into something cheap and deterministic to run again. Genentech's flow-rate tuning is that pattern applied to hardware instead of an API call. Second, natural-language driver tags answer a problem that has quietly limited lab automation for decades: safety-relevant knowledge that lives in a PDF manual or a technician's head, not in any machine-readable form.

The open question is safety at scale. Anthropic is explicit that evaluations and best practices are still being built with this first group of partners before MHS goes open source — the right order of operations for a spec whose failure mode is a robotic arm doing the wrong thing at full speed, not a malformed API response.