We’re opening a research preview of the Model Hardware Standard (MHS), a shared specification for AI agents to safely operate physical devices, to a first group of scientific research labs and advanced manufacturers. MHS enables AI agents to operate multiple lab and manufacturing instruments, such as microscopes, liquid handlers, and robotic arms, in parallel, and perform intricate tasks ranging from routine drug discovery experiments to laser calibration on a quantum computer. The development of MHS began as a collaboration between Anthropic and HHMI Janelia Research Campus.
It typically takes a lab or manufacturing facility weeks, if not months, to set up and integrate their hardware. Most devices don’t communicate with each other, instead requiring specialists to build bespoke integrations. MHS reduces this integration work to hours or minutes. And by incorporating AI into these tools, MHS also helps researchers and engineers more readily orchestrate autonomous, round-the-clock experiments and workflows, with agents able to reason through each step in an experiment, update parameters in real time, and, in some cases, recover from hardware errors without intervention.
We’re sharing an early version of MHS with partners across science, robotics, electronics, and manufacturing so we can collaborate to build safety evaluations and develop best practices for AI systems operating physical equipment, ahead of making the standard open source. MHS works with any device that has a programmable interface. It is also model-agnostic, and any agent harness can access it using standard protocols, such as the Model Context Protocol. To apply for access to the research preview, head here.
How MHS worksBefore and after the Model Hardware Standard (MHS).
Getting multiple devices in a lab or on a factory floor to communicate with one another can be challenging, even setting aside the added difficulty of integrating AI into the setup. Each device tends to have its own programming interface, and so far there has been no standardized way to integrate them. And once the devices are connected, there is no common way for them to share data with an AI agent, nor to let the agent operate them safely.
MHS addresses these challenges by introducing a standardized driver: software that translates between a computer’s operating system and a hardware device. The MHS driver uses a simple set of primitives—commands like “read” (for example, “get temperature”) or “write” (for example, “set temperature”)—that any hardware device can understand and act on. And it makes each device 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.
The MHS driver also helps an AI agent understand how to use a device it has never seen before, giving it information about machine characteristics that may not be discernable from code alone (for example, the weight of a robot arm, which is important for knowing how to manipulate it safely). To date, much of this information has been stored in paper manuals, on a user’s computer, or as tacit knowledge. But the MHS driver contains tags that let the user write this information directly in natural language (users can either do this themselves, or by chatting to an agent that interviews them about their hardware setup). With the information from these tags, the MHS driver then automatically produces a reference file with information about a device’s general characteristics, such as what it can measure, what can be adjusted, and what safety limits will be enforced. This file gives the agent everything it needs to know to operate the device.
After the devices are connected and the agent knows how to use each one, the agent needs a way to control the hardware. For MHS, there are three such mechanisms: MCP, the command line interface, and code files (APIs). These work together to enable orchestration across multiple devices via a single line of code.
Once the agent can control the devices, it’s able to receive operating data from each one and supervise and direct the work at a high level. The agent can sequence steps across instruments, monitor results, and adjust parameters as conditions change in real time. When the agent needs to execute long-running tasks or operate devices faster than its online reasoning would allow, it can chain together driver commands from one or more devices in code files. This allows the devices to carry out operations themselves, without the agent needing to reason at every step.
As we’ve tested MHS, we’ve found that Claude interacts with experiments and hardware in an exploratory manner, much as a scientist would. For example, we observed Claude make an adjustment to a laser, observe the results through a camera to assess how its adjustment moved the laser beam, and repeat the process, seeking to understand the sequence of events. Claude then packaged what it learned into code files, writing a deterministic script that let it align the laser without having to reason at each step, so the whole process could run as a single command.
Early examples from MHS
We are only just beginning to see what people can do with frontier models and MHS, but our hope is that the standard can be of use to researchers, engineers, and other practitioners in speeding up the process of discovery and experimentation in any domain that uses devices with a programmable interface.
As we developed MHS, we shared it with a handful of labs and hardware manufacturers in biotech, robotics, quantum computing, and other fields. Across these early projects, we saw MHS reduce the time it took to integrate devices, make it possible to iterate faster in a variety of experimental settings, and assist with the live operation of machines and real-time fault detection. Below, our partners share the details of some of their early projects involving MHS.
Genentech: Implementing MHS for lab automation
Researchers at Genentech implemented and tested MHS as a proof of concept for automating the BCA protein assay, a standard procedure to measure total protein concentration in a sample, which requires coordinating across a liquid handler, a robotic arm, and a plate reader.
Read moreGenentechGenentech: Implementing MHS for lab automation
Researchers at Genentech implemented and tested MHS as a proof of concept for automating the BCA protein assay, a standard procedure to measure total protein concentration in a sample, which requires coordinating across a liquid handler, a robotic arm, and a plate reader.
For half a century, Genentech has been tackling some of the most formidable challenges in science and medicine. In 1977, our scientists successfully produced somatostatin—a peptide hormone that regulates insulin and glucagon, growth hormone, and digestive tract functions in humans—in E. coli bacteria using recombinant DNA technology, proving that bacteria could be reprogrammed into bio-factories for medicines. Shortly thereafter, we synthesized recombinant human insulin, which in 1982 became the first genetically engineered therapeutic ever approved by the FDA. Since then, our commitment to basic research and patient care has pushed us to discover breakthrough therapies for cancer, multiple sclerosis, and other complex diseases.
This work requires rigorous experimentation in our drug discovery labs, often with large-scale automated systems capable of running high-throughput assays and testing many variables in parallel. These systems are made up of highly specialized lab robots—liquid handlers, robotic arms, microplate readers, and the like—that need to be carefully calibrated, iteratively tested, and supplied with complex programming logic in order to carry out experiments with precision. Currently, setting up these automated systems is a manual, time-consuming process that can take weeks or even months, limiting the number of scientific ideas our researchers can test.
To address this core bottleneck between experimental design and automated execution, we implemented MHS for lab automation with Anthropic. This open framework is designed to standardize AI-to-hardware communication, enabling scientists to interact with specialized lab robots using natural language and eliminating the need to write custom robotic code. Our ultimate goal is to build autonomous labs where AI handles the tedious, mechanical parts of experiment execution at scale so that our scientists can focus on the many creative aspects of accelerating drug discovery that rely on human judgement, such as experimental design, interpretation, decision making, and the invention of new lab approaches.
Automating the BCA assay as a proof-of-concept
We first implemented MHS on a large robotic workstation designed around a liquid handler. We wanted to see whether MHS could speed up the automation of the bicinchoninic acid (BCA) protein assay, a standard procedure used to measure total protein concentration in a sample. The procedure involves three instruments: a liquid handler to make precise fluid transfers, a robotic arm to move labware, and a microplate reader to measure optical absorbance, or how much light a sample absorbs at a given wavelength. We deployed MHS across all three devices, using Claude to orchestrate the protocol and act as a central communication hub for the hardware. All experiments were conducted in standard 96-well microplates, a staple of automated lab equipment.
The BCA assay involves handling liquids with different physical properties, ranging from simple aqueous reagents to viscous, foamy protein samples. In our setup, we used bovine serum albumin (BSA) at known concentrations as our protein sample to serve as a reliable standard. Because these fluids behave differently under pressure and flow, pipetting must be done extremely precisely to ensure that an exact volume of solution is transferred. For example, BSA solutions are viscous and form bubbles at high
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: