Progression

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 works

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 more

Genentech

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.

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 flow rates—the speed at which a liquid moves through a pipette tip—which directly impacts how accurately the solution is pipetted into the plate. Virtually all automated scientific experiments start with optimizing such fluid dynamics for each protocol.

As a starting point, we gave Claude the standard BCA assay protocol to establish a baseline against which to assess improvements. In this first test, Claude executed the protocol steps, but it selected generic liquid handling parameters with the same flow rate for both aqueous and viscous solutions, which caused bubbles to form in the viscous solution, resulting in inaccurate liquid transfers. We then asked Claude to autonomously optimize fluid dynamics for both plain water and viscous protein samples (BSA). We prompted the model with an experimental design to optimize the liquid transfer flow rate, asking it to explore our expert-defined range of flow rates by conducting trial transfers with dyed liquid and taking absorbance readings with the microplate reader to determine the optimal flow rate for each liquid type. Claude also had access to a “ground truth” transfer, performed by an expert in the same plate, and we asked it to minimize the difference between the expert’s results and its own. After performing the transfers, Claude calculated the root mean square error (RMSE) to quantify how accurate it had been (the lower, the better, with zero being the perfect score; if it aimed for 100 microliters but dispensed 98, that 2-microliter miss would count against the score).

Claude independently executed these trial runs and analyzed the resulting plate reader data to get closer to the expert-performed transfers. For water, Claude concluded that a flow rate of ~140 µL/s was optimal (0.016 RMSE); for BSA, it arrived at 10 µL/s (0.181 RMSE)—parameters that our automation experts confirmed were reasonable for our setup. Ordinarily, performing this optimization requires an automation specialist to write custom programming logic for every single parameter set, iteratively analyzing the data until they find the right parameters.

Autonomous error recovery and the limits of current AI models

During the experiment, Claude encountered several unexpected errors, including tip pickup failures and fluid detection errors, but managed to recover on its own—a capability that current scientific instruments mostly lack. However, these experiments also highlighted the current limits of AI models. Although they excel at general-purpose reasoning, they still struggle with physical, chemical, and biological constraints, particularly when troubleshooting errors that call for real-world physical intuition.

An example of this type of limitation is the formation of bubbles during liquid handling. Although they may seem benign, bubbles create a cascade of challenges: if a protocol calls for aspirating 40μL of reagent but there are air bubbles in the liquid, the actual liquid volume transferred will be lower due to the space occupied by air. Furthermore, liquid-level sensors can trigger hardware errors when a pipette tip encounters foam instead of liquid; bubbles also distort the optical readings that are the final readout of the experiment.

When it encountered runtime errors caused by bubbles during mixing, Claude’s default instinct was simply to retry the operation in the same plate well with different parameters. But this only agitated the fluid further and created more bubbles. Because Claude did not yet understand the underlying physics of the failure, we had to guide it towards parameters that handled the liquid more gently.

Once Claude was informed that the error code stemmed from physical bubbles in the liquid and that it needed to move to a clean well and reduce the number of mixing cycles in order to correct the error, it maintained that context for the rest of the run. We subsequently codified these takeaways into reusable liquid handling skills for Claude, which allowed it to select sensible default parameters for liquids with varying physical properties, reducing the number of liquid handling errors. These experiments highlighted the sorts of reasoning limits we can address by refining Claude’s software harness for lab automation.

Towards autonomous discovery

Although there is more work to be done to improve how Claude reasons about physical lab manipulations, this study proved to be a highly promising proof-of-concept. By assessing Claude’s decisions against our own domain expertise, we are generating the datasets we need to continuously improve models’ performance in automating lab experiments.

Going forward, we plan to evaluate Claude and MHS to orchestrate broader, end-to-end autonomous workflows in our drug discovery labs. We aim to build an autonomous discovery engine where scientists set the high-level biological intent, and AI agents help them coordinate the physical pipeline—generating hardware instructions, executing experiments autonomously, running closed-loop analysis, and delivering screen-ready models and screening data.

To expand our scope and impact, we’ll need to implement MHS on additional hardware, such as centrifuges, automated incubators, analytical instruments, and sensors. We’ll also need to tune the agent harness so it understands the nuances of working across drug discovery from molecules to live, sensitive cells. And we’ll have to integrate other, custom models that monitor and adaptively optimize experiments around the clock based on real-time data. With AI handling the routine tasks of maintenance, quality control, and environmental monitoring, our scientists can focus more on high-level experimental design, reasoning, and invention—moving us one step closer to accelerating the discovery of life-saving medicines.

Acknowledgements

We’d like to thank the Genentech scientists who contributed to this work, including Anupriya Tripathi, Matthew Bucci, Justin Nicola, and Corinne Gullekson.

University of Washington Baker and Pinglay labs: Bringing AI agents to the bench

Zihao Song, a PhD student in the University of Washington Baker and Pinglay labs, used MHS to build a dashboard to remotely monitor his instruments; an AI agent-supervised qPCR (which copies a target DNA sequence through repeated cycles of heating and cooling) that watches amplification curves and halts the procedure at the right moment; and an integration between a robotic arm and a liquid handler for collision-free plate handoffs.

Read more

University of Washington Baker and Pinglay labs

University of Washington Baker and Pinglay labs: Bringing AI agents to the bench

Zihao Song, a PhD student in the University of Washington Baker and Pinglay labs, used MHS to build a dashboard to remotely monitor his instruments; an AI agent-supervised qPCR (which copies a target DNA sequence through repeated cycles of heating and cooling) that watches amplification curves and halts the procedure at the right moment; and an integration between a robotic arm and a liquid handler for collision-free plate handoffs.

De novo protein design—building proteins that have never been seen in nature from scratch—has found a steadily increasing number of applications in medicine, environmental protection, and more over the past several years. Two things have held it back, however: cost and throughput. These days, designing a protein like PETase (the enzyme that breaks down plastic) can cost as little as $0.01. But testing that protein at the bench is slow and expensive, costing around $100 and requiring a week of labor per candidate—which adds up, given that we test 1,000 candidates at a time.

As a PhD student in the Baker and Pinglay labs at the University of Washington, I am working to develop high-throughput methods to reduce the cost per experiment and dramatically increase the number of de novo protein designs that we can screen at once. But working at that scale comes with costs of its own. Every round I run, whether a multiplexed design assay or an active learning campaign on enzyme activity, presents the same two challenges: monitoring status and capacity. Currently, our monitoring instruments sit in different corners of the lab, so I can’t easily see how a run is going without physically walking over to each one to check. When something fails partway through the run—the HPLC halts on an error, for example, or a liquid handler misfires and ruins a plate—I seldom discover it right when it happens. By the time I notice, hours may have passed, and the experimental sample is unusable. And I own only one of most instruments, so a single machine sets the pace for a whole round of testing, and I spend hours feeding it by hand. The PCR step is the worst culprit in this capacity crunch: it only handles one plate at a time, and I have to change the plates every 90 minutes (which is how I sometimes end up moving plates at 4 a.m. instead of sleeping).

The obvious fix is automation. But a research lab runs on flexibility, and that’s the one thing traditional automation cannot incorporate. A typical factory line might run one protocol 10,000 times, but my lab runs dozens of protocols a year, half of them new, which I must revise mid-run when the protein yield comes back far below what we assumed or a DNA assembly fails. Plus, my instruments come from different vendors, each with its own software, data format, and driver. Wiring them together is an integration problem that takes months to years and can cost anywhere from thousands to millions of dollars, putting it out of reach for most labs. There is no standard workflow to automate a protocol, and no affordable way to connect the instruments in most academic labs.

To explore a low-cost, low-effort route around both, I combined MHS with an AI agent and ran a few demos in my lab. MHS essentially gave the agent eyes, hands, and a sense of timing: it could see the status of every instrument, run each one, and coordinate them to work together.

Case study 1: Taking the lab remote

Prior to MHS, I had to rove around the lab to monitor instruments. With MHS, instruments report their status to one dashboard, so I and my colleagues can check on the whole lab from a laptop, or even ask an AI agent from a mobile phone without setting foot inside (Figure 2).

This remote monitoring is especially helpful for experiments that demand sustained attention. Quantitative PCR (qPCR) is a good example. qPCR amplifies (i.e., copies) a target DNA sequence through repeated cycles of heating and cooling, with a fluorescent reporter that brightens as copies accumulate. DNA amplification follows an S-shaped curve: the copying doubles the target each cycle, so the signal stays flat while it is still faint, climbs steeply once there is enough to detect, then flattens again at the top of the curve as reagents run low and the copies stop doubling (the plateau). Letting the reaction run into that plateau distorts the DNA library, such that I can no longer glean accurate data about the final quantity of amplified DNA sequences. To avoid that, I need to watch the curve and halt the reaction at the right moment. This can take many hours and requires that I actively monitor the instrument’s screen.

MHS addresses this tedium, monitoring and analyzing the amplification curves as they come in and reporting back in real time. It identifies the curve pattern and, at precisely the right junctures, asks the researcher whether to stop or continue. When told to stop, it halts the reaction and advances the instrument to the next step: a 4 °C hold, which keeps the DNA from degrading so it stays usable for downstream work (Figure 3). With an AI agent and MHS watching the curve, we can now focus on setting up downstream sequencing reactions at the bench or analyzing library enrichment data from other experiments in the office.

Case study 2: Coordinating instruments through a plate handoff

Other experiments don’t need real-time monitoring, but they do require me to repeatedly load samples into a machine and take them out (for example, high-throughput DNA amplification, protein purification, and plate-based assays like ELISA). Loading a sample only takes a few seconds, but each run takes an hour or two, so I end up returning to the lab every hour just to swap plates.

In an effort to free ourselves from full days tethered to the bench, we used an open-source robotic arm built on LeRobot, instrumented with MHS, to safely coordinate sample loading across multiple instruments. As a demo, I reproduced one routine handoff for a high-throughput experiment run. In this process, a liquid handler dispenses reaction reagents into a plate; the robot arm then lifts the finished plate off the deck and moves a fresh one into place, and the liquid handler dispenses again into the new plate. Claude Code controls and coordinates both instruments through MHS, running each step only once the previous one finishes, so the two instruments never collide during the handoff.

The demo worked as intended. After the liquid handler finished dispensing, the AI agent picked up the completion signal and, about 10 seconds later, triggered the arm’s next move, lifting the plate off the deck. Across repeated tests, the two instruments never collided: the arm never moved before dispensing had finished, and the handler never started before the arm had cleared the plate. Meanwhile, I watched the whole run on my office computer without touching anything. Handing off this kind of coordination to an AI agent, within the safety standards built into MHS, points to a future where an agent chains many such steps overnight while the bench runs unattended.

Looking ahead

Setting MHS up was faster and easier than I expected, especially given how my earlier automation attempts had gone—weeks spent evaluating platforms, chasing vendor support, learning and building glue code between instruments, and finally giving up. Connecting six instruments through MHS took under a week, including the time I spent writing drivers for them. Once they were connected, the AI agent worked with the instruments without much fussing on my part: it discovered each device, read its status, and called its operations without my having to hand-hold the interface. For someone who has spent years working around instruments that don’t talk to each other, that changed my day-to-day more than I anticipated. The time I used to spend monitoring qPCR curves now goes to planning experiments, reading papers, and analyzing data, or sometimes just taking a nap and spending an hour in the sun.

These demonstrations are still just proofs-of-concept. More complicated experimental protocols will require significant optimization to work reliably, as well as the integration of broader and more complex physical manipulations. Running an agent continuously over long monitoring windows also has compute costs that need to be weighed against the researcher time saved.

These considerations aside, we are excited to continue to experiment with how MHS might help us run a fully autonomous design-build-test-learn round. Every round of de novo protein design or optimization currently stalls at the handoffs, where I carry results from one stage to the next; in the future, with MHS giving an agent a stable interface into every instrument, that cycle could run on its own. I can envision an agent proposing a set of designs, running the builds and assays, reading the results back through that same interface, and using what it learns to plan the next round. A lab that can generate its own scientific data in this way, round after round, is beginning to look reachable, even on an academic budget.

Acknowledgements

We thank peer reviewer Pushya Krishna as well as Xander Balwit, Rebecca Hiscott, Ethan Dyer, Conor Kelly, and Siddharth Mishra-Sharma for providing helpful feedback. We are grateful to Alek Kemeny and Bailey Bova for helping us set up MHS. Special thanks to Dr. Sudarshan Pinglay for his contributions, support, and guidance on the blog, and for Dr. David Baker’s mentorship in my research.

Carnegie Mellon University: Determining dose-response curves through rapid automation

Researchers at Carnegie Mellon University used MHS to run serial dilution dose-response experiments about three times faster than before, with an AI agent orchestrating a liquid handler, a plate reader, a robotic arm, and monitoring cameras spread across three computers with fundamentally incompatible interfaces.

Read more

Carnegie Mellon University

Carnegie Mellon University: Determining dose-response curves through rapid automation

Researchers at Carnegie Mellon University used MHS to run serial dilution dose-response experiments about three times faster than before, with an AI agent orchestrating a liquid handler, a plate reader, a robotic arm, and monitoring cameras spread across three computers with fundamentally incompatible interfaces.

Sina Barazandeh, Arth Banka, Gün Kaynar, Jiayi Li, Peneeta Wojcik, Carl Kingsford, Jose Lugo-Martinez, Joshua Kangas

A key component of drug development is determining dosage. Once we have identified a drug candidate, we need to understand how much of the drug is necessary to be effective—too much can be costly, or even toxic, and too little is ineffective. The appropriate dosage is usually determined through a process known as serial dilution. We start with a strong solution and dilute it by the same ratio each time, using the last dilution to make the next one. For example, mix one part solution with nine parts solvent to get a 10x-diluted sample; take one part of that sample and dilute it again, in the same way, and repeat. Each step lowers the concentration by a fixed amount, giving us an even, predictable range to test.

The process is time-consuming and error-prone, typically requiring multiple iterations to determine the right maximum concentration and the appropriate step size between dilutions. Too high a maximum concentration risks saturation, meaning that the signal maxes out and the curve flattens at the top, so those high doses stop providing any useful information about the response. Too small a step size doesn’t cover a wide enough range; too large a step size skips over the transition region entirely, missing the point at which the response actually changes.

When done by hand, setting up and conducting a set of serial dilution experiments can take weeks. Already onerous in traditional drug development, this is even more impractical in the high-throughput screening of AI-directed drug development, where the aim is to determine the dosages for numerous candidates at a time. It comes as little surprise, then, that serial dilution experiments are a prime target for robotic laboratory automation.

Unfortunately, setting up such automated experiments is itself complex and time-consuming. It requires coordinating multiple pieces of experimental equipment across several rounds of experimentation to obtain a usable dose-response curve. Even with access to an automated laboratory (a non-trivial requirement, given the need for multiple automation-compatible instruments and costly integration software), it can take weeks of automation engineering and protocol development to develop a procedure to carry out these experiments.

Our solution

MHS enabled us to run these experiments roughly three times faster by allowing AI to programmatically control several pieces of laboratory equipment. Our system combines a CyBio Felix liquid handler (a robot that moves precise volumes of liquid between wells, tubes, and plates), a Varioskan LUX plate reader (the instrument that measures an optical signal, such as fluorescence, in every well of a microplate), a robotic arm to move 96-well plates, and monitoring cameras with an AI-controlled orchestrator to automatically and dynamically measure dose-response curves.

Individually, each of the components is challenging to control programmatically, requiring a unique interface and specific operation modes. An engineer normally has to learn and hand-code a separate integration for every instrument before they can work together. Using MHS, however, we were able to develop drivers from scratch for each of these instruments and an orchestration layer that lets a Claude Opus 4.8 agent run the full protocol autonomously. This took about eight hours, versus the several weeks a vendor-built setup typically takes.

Hardware, setup, and workflow

Our setup uses three computers. Computer 1 runs the robotic arm, controlled through scheduling software that takes job files dropped into a submission directory instead of a normal API. Computer 2 runs the liquid handler through an older Windows ActiveX/COM scripting interface, plus the monitoring cameras over USB. And computer 3 runs the plate reader, which has no programmatic interface at all, only an on-screen GUI. MHS turns each of these into one manifest of states (the conditions a system can be in; for example, plate at position 3, sample at 25°C, well filled) and procedures (the operations it can perform, such as aspirating or shaking), so the model works from a single, consistent interface, no matter which of the three computer control styles is running underneath.

The workflow itself is identical to what it was before MHS, only it’s now agent-driven: the liquid handler prepares a dilution series, a camera check confirms the plate is present and correctly oriented before any transfer is allowed, the arm moves the plate to the reader, the reader takes the measurement, and the model looks at the resulting curve and decides whether to adjust the concentration range and run it again or accept the result. To test it, we used a colorimetric dye (a dye whose color intensity tracks its concentration) as a stand-in for the actual drug candidate. This kept the experiment safe and easy to visualize while still requiring the same decision-making a real dose-response run would need.

Each instrument’s interface brings its own challenges. The arm’s scheduler is based on a directory watcher that generates two different files per submitted XML file, which MHS must reconcile to get one clean result, typically within a second of submission. The liquid handler only exposes COM scripting with no modern SDK, so each usable method had to be worked out either from vendor documentation or from a Claude Opus 4.8 agent exploring the interface to write a functional driver. A single dispense cycle takes about four to five minutes, and the allowed error margin on dispensed volume is only 5% before the resulting curve becomes unusable. The version of the plate reader software we use has no API of any kind, so MHS drives its GUI the same way a person would, with nothing to check its work against except what’s visible on screen.

Before this, a person had to sit through each of these steps: watching the arm’s log for failures, checking that the plate was seated correctly, and deciding whether a resulting curve was informative enough to keep or whether the concentration range needed adjusting and the whole thing needed to be rerun. MHS and the agent now handle all three of these decisions directly and automatically.

What we have achieved with MHS

To verify that MHS would operate safely and correct itself like a human operator would, we artificially induced six different conditions: missing plate, rotated plate, reader busy, disconnected camera, unreachable device, and active emergency stop. The system correctly blocked all six before any device moved. Then we asked the agent to run the serial dilution experiment to achieve an acceptable curve. The model evaluated the resulting curve, but found a fit too poor to accept (R² < 0.9, driven by saturation in the upper concentration range) and decided independently to discard the plate and rerun on a fresh plate with a compressed concentration range (200 µg/mL top concentration reduced to 100 µg/mL). The second run produced a strong, usable fit (R² > 0.98 with 3.4 variation across repeated measurements) with no human input at any point.

The most impressive thing about MHS was the integration speed. The time from raw, non-automated equipment readiness to a completed dilution curve, including one autonomous rerun, was eight hours. By contrast, engaging a vendor to deliver a working automated setup typically takes multiple weeks. The instruments run their own native software as usual; MHS adds an orchestration layer on top, with no additional automation software required. Any device with an API, SDK, or GUI interface can be integrated. The drivers developed for each instrument have been standardized and will be made publicly available, so others can reuse them rather than repeating the integration work from scratch.

What’s next

Future work in our lab will focus on validating the system with real drug candidates and replacing the dye’s color signal with readouts that capture actual biological effects. We also plan to expand MHS support to instruments such as qPCR and microscopes, and to integrate MCP-based agents with the MHS fleet. We also hope to reduce the integration time per instrument so we can scale the system for larger workflows.

We are also making sure this automation can be carried out safely. We plan to add more safety checks, monitor instrument and device responsiveness throughout our experiments, and refine our protocols for when and how human approvals are required for high-risk decisions. We’re looking forward to further exploring how else we can speed up the automation of our experiments, as MHS helps our researchers move faster, safely.

HHMI Janelia: Using MHS to accelerate microscopy research

At HHMI Janelia Research Campus, researchers are using MHS to speed up a range of microscopy-related projects. Here, Virginie Ruetten, a scientist in the Ahrens lab who studies how sleep helps the body recover from stress, shares how she used MHS to unify and orchestrate a rig that previously involved seven different vendor programs without a shared interface.

Read more

HHMI Janelia

HHMI Janelia: Using MHS to accelerate microscopy research

At HHMI Janelia Research Campus, researchers are using MHS to speed up a range of microscopy-related projects. Here, Virginie Ruetten, a scientist in the Ahrens lab who studies how sleep helps the body recover from stress, shares how she used MHS to unify and orchestrate a rig that previously involved seven different vendor programs without a shared interface.

A few nights of disrupted sleep are enough to cause widespread impairment: altered cognition, dysregulated metabolism, a weakened immune system. If this goes on long enough, sleep loss can even prove fatal. Yet we still don’t fully understand why. Part of the reason sleep is so hard to study is that it isn’t localized to any one organ. Because sleep is a whole-animal state, developing a mechanistic understanding of it requires measuring many parts of the body at once.

Microscopy offers a way to do this. Cells engineered to express fluorescent sensors emit light that signals their activity; microscopes can image these signals with high temporal and spatial resolution, letting us observe what these cells are doing. However, most animals are too large or too opaque for such imaging to function across the body. My work thus uses young zebrafish. This model organism is popular for its small size and transparency, and its organs and many aspects of its sleep physiology are similar to those of mammals, including humans.

These properties, combined with an experimental approach I developed called WHOLISTIC imaging, allow us to use two-photon microscopy to capture cellular activity throughout the brain and body of a living zebrafish. Rather than taking snapshots of isolated tissues, we can watch how cells and organs respond and interact from moment to moment across the entire animal, giving us a better understanding of the cellular players and underlying mechanisms behind physiological processes.

Controlling and coordinating devices through a unified interface

The instruments needed to carry out my experiments fill an entire room. As is common in many advanced microscopy setups, my rig is cobbled together from many components, each of which has been bought separately, from a different manufacturer, and wired up by hand: powerful femtosecond lasers; fast galvanometer mirrors, which sweep the microscope’s laser beam across the sample; super-sensitive photomultiplier detectors, which collect the returning light; and two precise translation stages, which position the fish relative to the sample holder, and the sample holder relative to the microscope.

These devices have to operate on a tight, shared schedule: the laser must be gated in step with the mirrors that scan it, and the stage must compensate if the animal moves or the sample drifts out of the focal plane. However, these devices were not designed to work together. Each comes with its own vendor control software, with no common interface. They often run in different programming languages, too: the detectors run in MATLAB, the cameras in Python, the electrophysiology in C#. A quantity held by one program, such as the position of the stage, is therefore unknown to the others. Yet the devices need to communicate—for example, each stage needs to know the other’s location for the system to know the absolute location of the sample.

The consequence of this incompatibility is that I spend a lot of time figuring out how to get devices to talk to each other, writing bespoke code to bridge two programs—or, in some cases, resorting to adding yet another device, a digital acquisition board (DAQ), a card that physically routes and transforms electrical signals, so the devices can communicate. Once everything is wired up, I still need to launch seven programs in a fixed order just to start an experiment, an error-prone process where getting the launch order wrong can cost the whole session.

MHS replaces those point-to-point connections with a single interface. Each device is now described and onboarded once, and its variables, controls, and sensor values are recorded in a single dictionary that lives in shared memory, a region of the computer’s memory that the operating system lets many programs access.

The benefit is that the cost of hardware integration stops scaling with the number of devices. Before MHS, integrating new pieces of hardware into the system was a multi-day project. Since implementing it, however, when I added a new camera to image the laser beam, it took me only a few minutes, and I could seamlessly feed the camera’s output—the location of the beam—back to the mirrors steering the beam, allowing me to more precisely align it. Starting an experiment now involves one click on the MHS dashboard instead of seven separate steps.

Quantitative monitoring and online analysis

Even after the hardware is wired up, I still need to run a plethora of checks and parameter adjustments before and during experiments to ensure I’m acquiring high-quality data. This includes monitoring the fish’s health, ensuring the camera is focused on the heart to measure heart rate variability, and surveying the quality of the fluorescence image to ensure that the cells I want to record are visible at high resolution. Each check involves computing a derived quantity from one of the many data streams the rig produces, such as the signal-to-noise ratio of the fluorescence data or the fish’s heart rate.

Such quantitative monitoring used to be laborious, as each data stream was collected by a separate program, and the values each program held in memory could not be easily read by any other program while the recording ran. Before MHS, I had three options, none of them optimal. First, I could collect the data and analyze it afterward, iterating on parameters between runs once it was saved to disc. But this took hours, and sometimes ended with the discovery that the recording was unusable. Second, I could judge the data by eye in the vendor viewer. This was fast, but it only gives an impression, not a precise measurement that can be compared across runs. Third, I could bolt analysis code onto the program doing the recording. But this was a pain because the code had to be rewritten for every program producing a data stream. Displaying the data streams was similarly time-consuming, because each application needed its own bespoke viewer, written in whatever language the recording program used.

MHS unified that fragmented process and removes the per-program rewrite. With MHS, each data stream is stored in shared memory in the MHS state dictionary, in a documented format that is readable by any process that attaches to it. Because each data stream is presented in the same way, analysis or visualization code can now be reused across devices and written in any language.

This allowed me to write a modular online analysis framework that guides the data through a chain of processing steps: data enters from a slot (an entry in the MHS state dictionary), passes through reusable transforms (operations on the data), and the result is written back to another slot or to disk. For visualization, I wrote a set of viewers—one per data type, rather than one per device—for images, time series, spectra, etc. Now, any data stream can be inspected while it’s being acquired, and I don’t need to rewrite any code to inspect a new one. When I became interested in how the zebrafish’s heart rate changes across the sleep-wake cycle, I could add a transform to compute the spectral content of the heart activity, as recorded by a camera, to estimate its heart rate; I could then reuse the code to compute the spectrum of the concurrent neural activity acquired by a different device, in a different language. Effort now compounds in one codebase rather than being split across one per device.

Running smarter experiments with agents

Experiments always involve tradeoffs. In imaging, for instance, I have to trade speed against coverage: I can scan a single plane—one thin optical slice through the brain—quickly, or many planes, to cover more of the brain, slowly. Finding the cells with the oscillatory activity I care about requires coverage, but measuring that activity requires speed.

Today, most experiments are ballistic: I select one set of settings at the start, one condition, and launch the run. So I have to pick a point on that tradeoff before the data tells me which point I need. Experiments last hours, so staying at the rig throughout is impractical—and biology is too variable and messy to have a simple deterministic algorithm do the searching for me. Ideally, I wouldn’t have to trade one for the other; I’d be able to search broadly, find the population of cells with the oscillatory activity I care about, then sample that precise region fast enough to resolve phase relationships between cells.

Agentic microscopy is the obvious way to get there: let an agent identify a region of interest and zoom in on it. But historically, that’s been easier said than done. The hard part isn’t getting the agent to iterate on writing analysis code to figure out where to zoom; it's getting it to reliably control a rig where commands move real devices, and where failure means a crashed objective, or an agent losing the few hours the sample preparation holds to the quirks of half a dozen vendor programs.

This is where I found MHS particularly helpful. With the entire rig’s state in a shared, standardized dictionary, agents can read and write every variable through a single interface, instead of seven vendor APIs, which removes the failure modes specific to each of them. I wrote a simple harness that made my rig operable by an AI agent. The core deterministic loop iterates between acquisition and analysis, and each result feeds the next decision. The agent enters at decision points, choosing the acquisition parameters (for example, what region to image) and what analysis to run, online and offline, in service of a user-stated goal. And because MHS enforces device-level safety limits, I don’t need to worry about the agent accidentally using excess laser power, for example, which risks bleaching the fluorescent molecules and degrading the sample. I'm still developing the framework and supervising experiments, but it has already allowed me to find the oscillatory population that a fixed setting would have missed, so I need fewer repeat runs and fewer animals to get the same number of usable recordings.

Going forward, I want to understand how these oscillations in the brain contribute to sleep and arousal so that my colleagues and I can identify targets for drugs that deliver restorative sleep, not just sedation. This requires mapping which cells are coupled to the oscillation, then running perturbation experiments phase-locked to it, to uncover the mechanism by which these cells shape global brain state. Doing this involves fitting models to the activity of thousands of cells as the data streams in, then triggering light-based activation of specific neurons—a technique called optogenetics—while the recording is running.

Such closed-loop experiments are hard because of the need to coordinate so many devices at speed, on a rig assembled from several vendors’ hardware that share no low-latency interface. MHS supplies the speed and adaptability, while still being easy for both humans and agents to comprehend. It doesn’t dispense with the tradeoffs that come with cellular activity imaging—such as speed versus coverage or how bright the signal is versus how long it lasts—since those are set by physics. But it does change how quickly I can explore the parameter space, home in on the right set, and iterate through experimental conditions and hypotheses. With MHS, I now look forward to the day when hardware control no longer limits the questions I can ask.

Virginie Ruetten’s is just one of a handful of projects incorporating MHS at Janelia. Another team, led by Arco Bast in the Spruston lab, images neurons and their dendrites deep in the brains of living mice as they learn to navigate a virtual environment, watching memories form in real time. MHS grew out of Arco’s idea of putting the entire rig’s state in a standardized dictionary in shared memory, and his custom microscope was the first rig to run on it. Every laser, mirror, and sensor in his rig is exposed through MHS, so Claude can align the beams, tune the optics, and check its own results against the sensors, turning a half-day of manual setup into a single step. Another team, co-led by Magdalena Schneider and Hari Shroff, is using MHS to enable agentic control of a light-sheet microscope. This allows Claude to act as an orchestrator, deciding in real time how to image developing C. elegans embryos, and how to make trade-offs between competing imaging parameters. Across all projects, MHS has helped the researcher compress integration times, and made it possible for AI agents to control complex combinations of instruments, data visualization, and analysis, paving the way for faster discovery across a range of domains.

QuEra Computing: Using MHS in quantum laser stabilization

QuEra, a company that builds quantum computers using neutral atoms, used MHS to give an AI agent control over parts of the laser system inside its quantum machines. The agent developed a controller that recovers the laser’s “lock”—the ultra-precise frequency the lasers must hold to interact with the atoms—99.3% of the time without human intervention.

Read more

QuEra Computing

QuEra Computing: Using MHS in quantum laser stabilization

QuEra, a company that builds quantum computers using neutral atoms, used MHS to give an AI agent control over parts of the laser system inside its quantum machines. The agent developed a controller that recovers the laser’s “lock”—the ultra-precise frequency the lasers must hold to interact with the atoms—99.3% of the time without human intervention.

The promise of quantum computing lies in its ability to harness the properties of quantum mechanics to perform calculations that are out of reach of even the largest supercomputers. QuEra’s neutral-atom approach uses the naturally occurring quantum mechanics observable in a single atom as the foundation for these calculations. Nearly all aspects of the control, operation, and readout of these atomic qubits—the quantum bits that hold the computer’s information—are done through the controlled interaction of a laser with atoms.

For that to work, each laser has to hold its color (its frequency, measured in Hz) to an astonishing precision, roughly one part in a trillion. That’s equivalent to measuring the distance from the Earth to the Moon to within the width of a human hair. Physicists call a laser “locked” when its frequency is held this tightly. Everyday disturbances, such as temperature, vibration, or a shift in pressure, can push the laser off the desired frequency and “unlock” it, causing quantum operations to start to fail. As quantum computers perform long, error-corrected programs, a laser that ends up off its target frequency mid-run can spoil a computation that took hours to build up.

The laser at the center of this work is a titanium-sapphire laser, a tunable workhorse that atomic physics and quantum technology have relied on for more than 20 years. Traditionally, these lasers were controlled by hand, tuned for one-off experiments by experts. In QuEra’s quantum computers, those experts are aided by software that can detect and correct the most common disturbances before the lock is lost. But the potential sources of failure are so dynamic and varied that they cannot all be planned for in advance, so new or uncommon failures still need expert intervention. That requires an experienced operator, who must watch several instruments at once and judge what moved, what to correct, in which order, and when to trust the result. It typically takes 5 to 10 minutes to recover the frequency.

In university labs, this skill is handed down from one graduate student to the next, and when the lock drops at 2 am, someone has to wake up and drive in to perform the recovery. For a university lab, that is an inconvenience and an inefficiency. At the fleet scale of a quantum-computing company, it is simply untenable to keep this skill set in the hands of just a few people.

Given the vast and variable problem space, the complexity of the hardware to be controlled, and how critical this laser system is to the operation of the quantum computer, the team at QuEra identified automated laser recovery as a good first test case for MHS (Figure 3).

What we achieved with MHS

Making laser recovery automatic was not a new idea at QuEra. Before MHS, a team comprising a laser-systems engineer, a software engineer, an algorithms specialist, and a tester spent several months building a bespoke script to automate it. That recovery script reproduced what a human does at the bench, step for step: disarm the function holding the lock, work through the laser’s tuning controls in order, check the frequency after each tune, start over if the frequency is still off, and reengage the lock once it’s correct. But it only worked about 58% of the time, and it took around 150 seconds per attempt.

Because the script automates exactly what an expert does, it also inherits the same shortcomings. A linear sequence cannot absorb a change midway through, so when a shift in temperature or air pressure (for example, from somebody opening the door to the lab) undoes a step that had already succeeded, the recovery procedure must start over. This is the case both for an engineer at the bench and for the script, which is part of why a human recovery takes 5 to 10 minutes. Automating the steps made the sequence faster, but not fast enough to outrun the disturbances. This explains both the 150 seconds per attempt and the 42% failure rate.

QuEra handed the same problem to Claude through MHS. The team began by populating the agent’s context with a goal—write a standalone Python script to relock the laser—and a definition of success—relock on the first attempt, then hold for 30 seconds. The first time we attempted this, it took a day or two; now it only takes a few hours. We then induced disturbances for the agent to recover from: blocking the beam, cutting power to instruments to imitate a surge, and pushing the frequency off target by varying amounts. MHS supplied the access to Claude so it could read the instruments and move the controls as a human operator would.

Having set that up, the agent loop ran as four roles, each a fresh instance of Claude. One proposed a hypothesis for making recovery faster or more reliable; one wrote that change into the recovery script; one ran the updated script against the live laser and logged every step; and another read the logbook and decided what to change next (Figure 4). That cycle repeated hundreds of times, unattended, throughout the night, with each pass iteratively improving the script. By morning, recovery was taking about six seconds and working 96% of the time, against the 150 seconds and 58% it started from (Figure 5).

This improvement was the result of Claude rewriting that linear sequence as a decision tree. Instead of one path for every disturbance, the script it converged on reads each instrument, builds up if-then conditions from what the instruments show, and makes adjustments based on the specific physical disturbance and the pattern Claude learned from encountering it repeatedly. For example, if the frequency has barely moved, most of the laser’s controls will not change anything, so the script touches only one or two, leaving the rest alone. A human operator would still have to work through all of them, because the only way to be sure a control is right is to check it. Claude found the shortcut by running disturbances over and over again until the pattern in the lock’s behavior became clear. Claude’s advantage was its ability to do this exceedingly quickly, at a pace no operator could match.

We then tested the finished script against the same randomized set of induced disturbances with no agent involved. Across 700 trials, it recovered the correct lock 695 times, a 99.3% success rate. The hardest disturbances, where the frequency had hopped far from target, took 10 to 14 seconds, compared to the 5 to 10 minutes for a human at the bench, and the simpler ones took 0.9 to 5.4 seconds (Figure 5). The end product was a deterministic, fully inspectable script capable of running in production without an AI agent controlling it.

With the laser locking working significantly better, we then pointed the agent at the quality of the lock—that is, how often it unlocks. That’s set by 12 interdependent parameters (known as PID) inside the servo loop (shown in Figure 3). Tuning them well strips residual noise out of the lock, which sharpens the computer’s gates and makes unlocks rarer. Measuring that noise precisely requires capturing an oscilloscope trace and running a Fourier transform on it, which is not realistic for a human after every small change across 12 parameters. Instead, a specialist generally tunes against the root mean square (RMS) error the servo reports, which is a good enough approximation for lock quality. The PID parameters drift with temperature and pressure changes, so the goal is a tune that is good enough to hold for a while, followed by a retune when the lock starts slipping. The video below shows what just three of those parameters do.

The team pointed Claude at that same RMS number, but after every single adjustment it also captured a trace and computed the full spectrum hundreds of times over the course of the night. That is the part a human cannot match. Minimizing the RMS error usually does produce the lowest noise across the whole band, and a specialist who has done it for years is typically correct to trust it. But Claude did not have to trust it; instead, it could confirm the exact amount of residual noise after every change, and keep scouring through the search space until it could guarantee it had found the lowest realistic noise possible.

The laser’s parameters had already been set by a QuEra specialist, and that standing tune measured 15.7 mV of residual error. Over 363 experiments and 16 unattended hours, Claude brought it to 1.55 mV, roughly t10 times quieter on the RMS measure it was optimizing against (Figure 7). To verify that independently, the specialist retuned the same laser from scratch by his usual method, without seeing what Claude had found, and both sets of parameters went to a phase noise analyzer—a rare, specialized instrument used to measure absolute phase noise ( how much fluctuation is present at every frequency). This check also served as a way to fairly compare each PID parameter set. The agent’s tune matched the specialist’s across the band, with one exception: a roughly 220 kHz resonance where the manual tune had left about a thousand times more noise than Claude’s—exactly the kind of error that can occur when using the RMS heuristic, and what Claude’s method was able to avoid). The final check was the one that matters most in practice: how long each tune holds. Over a 19-hour run, Claude’s PIDs did not lose the lock once, while the expert tuned PIDs unlocked about 1.6 times an hour. Unlike the relock controller, this tuning workflow keeps the agent in the loop to adjust the parameters as conditions change.

What’s next

The relock controller was built for a single laser system. But a quantum computer holds many laser systems with similar potential points of failure—not to mention many other subsystems that serve different functions but are similarly precise, fragile, and complex, and which require the same meticulous attention from a scant pool of experts.

In the pilot, MHS and AI agents did not replace such expertise completely. During the experiments, if something went wrong with the physical hardware, Claude didn’t know how to troubleshoot, as its understanding of the rig was programmatic rather than physical. Claude also often stopped to wait for human confirmation before performing an action it deemed even slightly risky, meaning experiments would sometimes pause overnight while Claude waited for approval. Still, an overly cautious agent is preferable to one that is not cautious enough. Finally, the team needed to provide a ton of context to Claude about what they wanted from the experiment and how Claude should carry it out for it to perform the tasks correctly.

Even with these limitations, the pilot showed that an AI agent can meaningfully improve how such systems are controlled, and some of these limitations should ease as models become more capable and build up a more sophisticated understanding of hardware. Next, QuEra aims to deploy the relock recovery system on live quantum processors, package the tuning workflow as a standalone tool, and apply the lessons from this experiment to other subsystems—working towards a fleet of machines that increasingly look after themselves.

Read more about the pilot experiment on the QuEra blog.

Tetsuwan Scientific: Using MHS to run qPCRs to profile local pollution

Researchers at Tetsuwan integrated MHS with its automated biology lab platform, ResearchOS. MHS helped orchestrate a qPCR workflow to contribute to citizen science efforts to characterize pollution in California’s San Pedro Creek.

Read more

Tetsuwan Scientific

Tetsuwan Scientific: Using MHS to run qPCRs to profile local pollution

Researchers at Tetsuwan integrated MHS with its automated biology lab platform, ResearchOS. MHS helped orchestrate a qPCR workflow to contribute to citizen science efforts to characterize pollution in California’s San Pedro Creek.

Since the 1960s, labs have had automated machines that can pipette, seal, shake, move labware, and perform most of the other functions of a biology lab. Yet the majority of biology experimentation remains manual. Part of the reason for this is that most biology experiments are fundamentally dynamic: sample count, plate format, and the number of conditions change between runs, as do the scientific parameters, such as dilution series depth, incubation times, the number of timepoints, and so on.

Translating a single experiment configuration into an automated workflow takes a specialist, known as an automation engineer, weeks or months. So automation only pays off when a configuration is repeated at enormous scale, like in high-throughput screening, where one method is used across a library of hundreds of thousands of compounds. The bulk of experimentation remains manual, inheriting all the potential errors and reproducibility problems that entails.

Tetsuwan is building an automated biology lab, available to researchers and agents via an API. Without a way to automate both small- and large-scale configurations, our lab would be confined to the limited capabilities of lab automation today. We built ResearchOS to solve this. ResearchOS is an automation platform that allows users to generate, run, and manage automated workflows without prior lab automation experience within minutes. Claude works with users to turn natural-language protocols into a script written in our syntax for experiments, which is ultimately processed by a custom compiler into automation code.

ResearchOS connects users to the automated lab, but the lab itself presents a formidable orchestration challenge. It is, after all, a menagerie of pipetting robots,¹ robotic arms, and automated labware that all use different languages and all have their quirks. We implemented MHS to allow us to use Claude as an orchestration layer over that fleet by enabling these devices to communicate with one another and with the user. To test MHS, we put the platform to work on a citizen science project in Pacifica, California, running quantitative PCRs (qPCRs) to characterize sources of fecal contamination in the San Pedro Creek, which for decades have been at dangerously high levels.

Implementing MHS in a qPCR workflow

One of the most commonly used protocols in many biology labs, the polymerase chain reaction (PCR) copies DNA with nothing but a metal block, called a thermocycler, that heats up and cools down. DNA is a two-stranded molecule, and heating it separates the strands so they can be duplicated. Cooling the strands lets primers—short pieces of DNA that match the edges of the region you want copied—stick to those strands and mark where copying should start. Warming the strands back up, though not as much as before, lets an enzyme called a polymerase extend each primer along the strand it’s stuck to, copying it. qPCR adds a dye that glows brighter as copies accumulate, so we know how many copies there were to begin with. We can use this to measure how strongly a gene is switched on, to detect and quantify a pathogen in a patient sample, and, as in our case, to measure how much of a specific organism is present in an environmental sample.

qPCRs require a viscous, soap-like reagent known as a “master mix,” which contains the chemistry shared between reactions. These liquid properties make master mix especially prone to creating bubbles and foam when pipetted, which can cause inaccurate pipetting and degrade the quality of the experiment. With MHS, we were able to connect a camera that detects such errors and triggers an automated recovery process.

In one case, the camera identified bubbles in the master mix, which was in a tube held by a robotic arm. There was nothing the robotic arm alone could do to get rid of the bubbles. So ResearchOS scanned the lab for MHS-connected devices that could help, and Claude suggested an error handling strategy to us via Slack: move the tube to a centrifuge and briefly spin it at a low speed to draw the liquid to the bottom of the well, eliminating the bubbles. Through MHS, Claude was then able to issue the appropriate commands to the centrifuge.

This orchestration layer also allows protocols to stay hardware-independent. For example, a protocol might call for spinning a plate down at 15,000 × rpm for five minutes, without naming a specific type of centrifuge. ResearchOS can use MHS to query the network for a compatible centrifuge, learn its driver interface, and then use Claude to convert the force specified in the protocol into whatever parameters that specific machine accepts. For a machine that only takes rotor speed, for instance, that means dividing the force by the radius of the centrifuge’s rotor. The protocol author never even has to know which centrifuge was used, nor how the measurement was converted.

Improving compiler heuristics with MHS

We also used Claude to set up a closed-loop optimization experiment to improve our compiler, which translates high-level code into instructions our lab equipment can execute. We took our qPCR protocol and compiled it into a range of realistic worklists that spanned a variety of experimental setups, such as testing different primer sets with different combinations of samples, sample numbers, and replicates (multiple runs of the same sample). From this, we determined how many different types of liquid transfers our compiler could implement. We then tried out those transfers on a robot under varying conditions, and measured their accuracy and precision with a tracer dye. When an experiment finished, Claude retrieved the accuracy data from the plate reader via MHS, analyzed and visualized it, and suggested tweaks to improve our compiler’s model of transfer precision. With more precise predictions and known systematic offsets (predictable errors in measured values), the compiler was able to make more informed machine layout and tip-reuse tradeoffs, which will ultimately help make our experiments faster, cheaper, and more accurate.

Over the course of this experiment we tested 9,143 individual dispenses, 300 unique transfer types (liquid × tip × volume × dispense count × over-aspiration), and 1,508 measured conditions across four types of liquid. On held-out experiments, the model Claude and MHS helped refine predicted multi-dispense precision roughly 12% more accurately than the manufacturer’s technical specification, beating it on 31 of 45 runs (sign-test p ≈ 0.001). This increased to roughly 17% on our most-replicated data.

Preliminary data from the San Pedro Creek

Although these were just early tests, the preliminary data from our qPCR testing corroborated the San Pedro Creek Watershed Coalition’s finding that humans are the primary contributor to fecal contamination in San Pedro Creek. We used qPCR to amplify fragments of bacterial DNA specific to different host organisms, such as humans, horses, birds, and dogs.

We were able to detect the presence of E. coli with a general 16S marker, as well as the presence of Bacteroides bacteria using the AllBac primer. 16S is a ribosomal RNA gene shared by all bacteria. By designing primer sets to interrogate sequences of 16S that contain interspecies variations, the host species can be identified (in this case, E. coli).

We also saw clear amplification of human-associated Bacteroides using the HF183 and BacH primers. No other host-specific Bacteroides were detectable in our experiment. In future experiments, we aim to better characterize the source of contamination and quantitatively evaluate the concentration of human-associated Bacteroides in the wastewater.

Ultimately, the improved device integration, orchestration, and real-time error recovery made possible by MHS will be critical to bridging the gap between hardware, scientists, and models. As tools like ResearchOS and MHS improve the capabilities of lab automation, we believe experimentation will become increasingly accessible, reproducible, and programmable.

To read more about the optimization and community science aspects of this project, visit our blog.

¹ Known as “liquid handlers” within lab automation. Note that 6-DoF arms are not the same as liquid handlers; liquid handlers are optimized specifically for pipetting rather than for general use. Workcells—which combine multiple lab robots into a single system—usually employ both liquid handlers (for pipetting) and robotic arms (for transferring plates and other labware).

01 / 06

Hardware vendors and the software companies that support them are also building MHS support into their equipment so AI agents can more easily discover and operate their devices. For example:

• Amazon Web Services will support MHS through Strands Robots, the library for connecting AI agents to physical devices. AWS will provide participants a private, pre-release version of the Strands Robots package for the duration of the MHS research preview.
• Automata is adding MHS support to LINQ, their lab automation platform, to perform intelligent error handling of instruments in autonomous labs.
• Danaher and Anthropic are actively exploring how MHS-supported capabilities could enable its smart instruments and autonomous laboratories to scale biomedical research and development.
• Doosan Robotics is testing MHS with their robotic arms, including to perform automated quality assurance and coordinate tasks across multiple robots.
• MBF Bioscience is building an MHS driver for ScanImage, the software that runs laser-scanning microscopes in hundreds of neuroscience labs worldwide, to integrate AI agents into real-time data analysis and experiments.
• QIAGEN is experimenting with MHS through a working proof of concept on its nucleic acid purification platform, QIAsymphony Connect, showing how AI agents could help laboratories troubleshoot instrument issues faster, guide operators through recovery, and improve instrument uptime while reducing risk to biological samples.
• Tecan is adding MHS support for their Fluent liquid handling platforms so AI agents can discover and operate them directly.
• Universal Robots has had early access to MHS and plans to add support to its robotics platform.

Joining the research preview

These early results from our partners are encouraging, but we have more work to do on the standard before we open-source it. As a large language model, Claude learns about the physical world through text and images, meaning its spatial and physical reasoning have limitations that still require expert oversight. When working with protein samples, for example, Genentech researchers had to guide Claude to recognize that errors caused by foaming in samples were physical failures, not software bugs, that could only be mitigated through the appropriate physical corrections.

MHS also doesn’t yet work with hardware that lacks a programming interface, so we’re working with the manufacturers of such devices to build in MHS drivers. Many developers already use Claude Code to work with individual pieces of physical equipment; for the next phase of MHS, we hope to expand the standard to cover more of the devices developers build on. Early adopters include Hugging Face, who are adding MHS support in LeRobot, their robotics library, and Raspberry Pi, who are enabling MHS integration across a number of their products following successful tests using their Camera MHS Driver.

We will also use the research preview to build additional safety evaluations with our launch partners and strengthen protections for the use of AI in the physical world. We are developing a physical safety roadmap to further bolster our safeguards policy and enforcement coverage against the risk of misuse. When we open-source MHS, we will release findings from the research preview as part of our guidance for deploying the standard safely.

We’re inviting stakeholders across industries to join the waitlist for our research preview of MHS. If you’d like to participate, submit your interest here.

Acknowledgments

MHS began as a collaboration between Alek Kemeny on Anthropic’s Beneficial Deployments team and Arco Bast, a postdoctoral scientist at HHMI Janelia Research Campus. Bast was running complex brain-imaging experiments on a rig that combined lasers, motorized focusers, and specialized cameras from different vendors with no common interface. To speed up his experiments, he developed a shared memory dictionary that enabled the instruments to communicate with one another at memory speed. Kemeny and Bast worked together to integrate AI models into that interface.

We thank everyone who has contributed to this work so far, including, but not limited to, Aaron Boswell, Ben Arthur, Boaz Mohar, Gagan Bhat, Mark Kittisopikul, Nadine Yasser, Nick Purcell, Takashi Kawase, and Virginie Ruetten. We look forward to moving MHS forward with our industry partners and, soon, with the open-source community.