Anthropic's MHS Enables AI Agents to Control Laboratory and Quantum Devices

Anthropic has released a research preview of the Model Hardware Standard (MHS), aiming to establish a universal interface for AI agents to interact with physical devices, analogous to MCP. Microscopes, liquid handling workstations, robotic arms, cameras, lasers, and sensors need only be connected once, enabling different models to discover and control them through unified states, operational commands, and safety constraints—reducing customization and integration times that previously took weeks or months to just hours or minutes. In early tests, Claude used MHS to collaboratively perform protein detection experiments, adjust microscopy imaging in real time, resolve liquid bubble failures, and increased the laser recovery success rate of QuEra’s quantum computer from 58% to 99.3%. However, Anthropic acknowledges that language models lack true physical intuition and still require expert oversight when dealing with real-world challenges such as bubbles, collisions, optical paths, and biological samples. MHS is currently available only to select laboratories and manufacturing companies and will be open-sourced only after comprehensive safety evaluations are completed. Its significance lies not merely in “Claude operating machines,” but in AI agents evolving from reading software and calling APIs toward observing, intervening in, and iteratively experimenting within the physical world.

Article author, source: Anthropic

Claude can read papers, analyze data, generate research hypotheses, and write experimental code, but when research reaches the step of "actually operating equipment," AI is typically excluded from the real world.

The issue isn't solely with model capabilities, but with the extreme fragmentation of equipment in labs and factories. Cameras may use Python, detectors run on MATLAB, electrophysiology devices use C#, and robotic arms, microscopes, and pipetting workstations each have their own drivers, data formats, and control software. Many devices are unaware of the current status of neighboring instruments.

Researchers often need to write separate connection programs for each pair of devices if they want the camera to notify a robotic arm after detecting a sample’s location, or if they want the microscope to automatically adjust scanning parameters based on real-time images. The more devices involved, the more complex the point-to-point integrations become to maintain.

Anthropic stated that laboratories or manufacturing facilities traditionally required weeks or even months to complete a hardware integration. MHS aims to reduce this process to hours or minutes.

It doesn't address "how to make the model smarter," but rather establishes a common language that the model can understand across all devices.

(Original text includes architecture diagrams showing the transition from point-to-point custom connections to unified interface communication before and after MHS integration.)

The core of MHS is a standardized driver that acts as a translation layer between the device's native interface and the AI agent, converting complex machines into a small set of universal primitives, such as reading temperature, writing temperature, querying status, or executing an operation.

Devices connected to MHS generate a standardized reference document detailing what they can measure, which parameters can be adjusted, the possible states of the device, and the required safety restrictions.

Pure code often cannot capture all the real-world attributes of a machine. For example, a model that only sees the control API of a robotic arm may not know the arm’s actual weight, range of motion, inertia, or collision risks. In the past, this information was often scattered across paper manuals, engineers’ computers, or operators’ experience.

MHS allows users to supplement this knowledge with natural language labels. Users can either fill in the information directly or let the Agent query details about the device through conversation and automatically generate a description file.

After integration, the Agent can control devices via MCP, command line, or code APIs. It can read real-time data from multiple instruments, schedule operation sequences, and adjust parameters based on experimental results. For high-speed or long-duration operations, it compiles a series of driver commands into code, allowing the device to run autonomously without requiring the model to re-infer before each minor action.

MHS is model-agnostic and does not require the use of Claude. Any model or agent framework can, in principle, access devices through standard protocols such as MCP.

Genentech used the MHS to test the BCA protein assay protocol. The experiment required coordination between a liquid handling workstation, a robotic arm, and a microplate reader to measure protein concentration through color changes in the samples.

These processes may seem suitable for automation, but in practice, they are easily affected by the physical properties of liquids. When pipetting foam, liquid level sensors may give erroneous readings; bubbles can also interfere with final optical measurements.

When Claude first encountered a runtime error caused by bubbles, his instinct was to adjust the parameters and retry in the same well. This only continued to agitate the liquid, generating more bubbles.

Researchers must tell it: this is not a software glitch that can be solved by running repeated cycles, but a physical issue occurring in the liquid. The correct approach is to switch to a clean well and reduce the number of mixing cycles to make the operation gentler.

After receiving the explanation, Claude retained this context in subsequent experiments. The team also distilled the experience into reusable liquid-handling skills, enabling Claude to select more appropriate default parameters based on the properties of different liquids, thereby reducing pipetting errors.

This case reveals the clearest boundary of MHS to date. While the agent can reason based on sensor feedback, the world model it learns from text and images is not equivalent to the physical intuition developed by experimenters through prolonged operation.

MHS originated from a sophisticated brain imaging system at HHMI Janelia.

Researcher Virginie Ruetten used two-photon microscopy to observe the activity of cells and organs throughout the entire body of live zebrafish during sleep. The complete experimental setup, including lasers, mirrors, a stage, a camera, and multiple sensors, originally required seven different software programs from various manufacturers to operate in coordination.

Devices lack a unified interface and often use different programming languages. One system knows the stage's position, but another cannot directly access it; researchers must write extensive bridging code and sometimes even add dedicated data acquisition cards to enable devices to communicate.

MHS places the status, variables, control commands, and sensor readings of all devices into a standardized shared state space. Each device needs to be described and connected only once, allowing other programs or agents to directly discover and use it.

Before implementing MHS, adding a new camera could take days to integrate; after connecting to MHS, researchers added the new camera for observing laser position to the system and fed the video data to the program controlling the mirrors in just minutes.

Claude can also observe the beam through the camera, adjust the mirrors, and then assess the movement outcome based on the new image, creating a "operate—observe—correct" feedback loop. In another microscope system, tasks that previously took researchers half a day to complete—such as inspecting lasers, sensors, and optical paths—have been condensed into a single automated step.

QuEra Computing builds quantum computers using neutral atoms, requiring lasers to control the atoms with extreme precision. The allowable deviation in laser frequency is about one part in a trillion—equivalent to an error no greater than the width of a human hair when measuring the distance from Earth to the Moon.

Changes in temperature, vibration, or pressure can cause the laser to lose its "lock." If this occurs during a long-duration quantum computation, a task that has been running for hours could fail outright. The traditional recovery process typically requires experienced operators to simultaneously monitor multiple instruments and adjust parameters in sequence, taking approximately 5 to 10 minutes.

Previously, QuEra assembled a team of laser engineers, software engineers, algorithm specialists, and testers who spent months developing a fixed recovery script. This script adjusted the controller step-by-step according to manual procedures, achieving a success rate of approximately 58%, with each attempt taking about 150 seconds.

After integrating MHS, the agent no longer merely repeats fixed procedures but continuously generates diverse perturbations, observes laser responses, and identifies which control parameters truly require adjustment.

After an overnight experiment, the recovery time decreased to approximately 6 seconds with a success rate of 96%; after further optimization, Anthropic reported a final recovery success rate of 99.3%.

The agent also found that when the laser frequency offset is small, it is unnecessary to check all control parameters—only one or two need to be adjusted. Human operators typically verify each item individually for safety, but the agent identified which steps could be skipped through extensive repeated experiments.

However, QuEra emphasized that Agent does not fully replace experts. When faced with pure physical hardware failures, Claude often does not know how to respond, as its understanding of the equipment is still primarily derived from program interfaces. For operations with even slight risk, it frequently pauses to await human approval, causing some nighttime experiments to be postponed until the next day.

Tetsuwan Scientific integrated MHS into the automated biological experiment platform ResearchOS to conduct qPCR experiments analyzing local pollution levels.

qPCR requires the use of a viscous, soap-like reagent called "master mix." This liquid tends to foam during pipetting, leading to inaccurate volumes and reduced experimental quality.

In an experiment, the camera detected bubbles in the tube held by the robotic arm. Although the robotic arm itself could not address the issue, ResearchOS searched for other devices connected to the MHS in the lab. Claude then recommended via Slack that the robotic arm send the tube to the centrifuge for a brief, low-speed spin to reaggregate the liquid and bubbles at the bottom.

This type of cross-device handling is a scenario that traditional fixed automation processes struggle to cover. Programmers do not need to predefine complete recovery paths for every possible failure; the agent can observe the error and then determine a solution based on the currently available device configuration.

The team also had Claude optimize the compiler that translates advanced experimental protocols into hardware operation instructions. The experiments covered 9,143 independent liquid dispenses, 300 different transfer combinations, 1,508 measurement conditions, and four types of liquids.

In tests without optimization participation, the model jointly improved by Claude and MHS predicted multi-channel dispensing accuracy approximately 12% more accurately than the equipment manufacturer’s technical specifications, winning 31 out of 45 test rounds; on datasets with the highest repetition counts, the improvement was about 17%. These results come from experiments conducted by the project partner and cannot yet be considered generalizable conclusions independently replicated across laboratories.

Anthropic did not describe MHS as a fully matured autonomous laboratory system.

Claude can read states, analyze visuals, and use devices, but its knowledge of the real world primarily comes from text and images. Issues such as friction, foam, weight, liquid viscosity, mechanical play, and optical path drift often only become apparent during actual operation.

If a device has no programmable interface, MHS currently cannot connect directly; Anthropic is working with manufacturers to add drivers for such devices.

Physical security is equally more complex than software permissions. When a digital agent executes an incorrect command, files can usually be rolled back or the system restored; however, when controlling robotic arms, lasers, chemical reagents, or biological samples, an erroneous action may cause equipment damage, sample loss, or even pose risks to personnel.

Therefore, a key task during the research preview phase is not to increase the number of devices, but to establish new safety evaluations: which operations must be approved by a human, under what conditions the device should automatically stop, whether the model can detect sensor anomalies, and how to ensure that hardware driver-layer restrictions cannot be bypassed by the Agent.

Anthropic is developing a "physical security roadmap" and plans to release the research preview findings and secure deployment guidelines alongside the official open-sourcing of MHS.

MHS has received early support from multiple device and platform companies. AWS plans to provide access through Strands Robots; Doosan Robotics and Universal Robots are testing robotic arm support; Tecan, QIAGEN, and Automata are focused on laboratory automation; Hugging Face plans to integrate MHS into the LeRobot robotics library, and Raspberry Pi is testing integration in select products and camera drivers.

If MHS forms an ecosystem, it could unify the connection between agents and physical devices in the same way that MCP unifies models and software tools. Laboratories would no longer need to repeatedly build interfaces for each model, device, and software suite, and device manufacturers could directly provide standardized capability descriptions discoverable by agents.

However, MHS faces significantly greater challenges. Software tools typically have well-defined inputs and outputs, whereas physical devices can wear out, drift, clog, generate noise, and be affected by environmental changes. Two instruments of the same model may perform differently due to variations in calibration status and installation methods.

Therefore, what MHS truly aims to standardize is not just commands, but also machine states, real-world constraints, safety boundaries, and failure recovery knowledge.