Previewing the Model Hardware Standard
Skip to main contentSkip to footer
[](https://www.anthropic.com/)
- Research
- Policy
- Commitments
- Learn
- News
Announcements Beneficial Deployments
Previewing the Model Hardware Standard
Aug 27, 2026
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
Before 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 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 judgment, 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.
The automated experiment workflow. First, a scientist describes the experiment to Claude in plain language. Then, Claude plans and orchestrates the run, drawing on reusable skills and a knowledge base. Every instruction passes through MHS, which serves as the standard interface for each device. MHS then operates each instrument (the liquid handler, robotic arm, and microplate reader) and streams its state back to Claude. The orange ring shows the part of the experiment Claude executed in a closed loop. It set a flow rate and transferred dyed liquid to a plate, sent the plate down the stack and read absorbance, then scored its own transfer against an expert’s and adjusted the flow rate, converging on water ≈ 140 µL/s (0.016) and viscous BSA ≈ 10 µL/s (0.181).
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.
Genentech scientists analyze plates for the presence of bubbles.
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.
**Figure 1.** Comparing an academic lab, an automated lab, and an MHS-based lab. Traditional labs run distributed instruments without a central scheduler. This is flexible but labor-intensive, with AI use limited to human-AI exchanges. Automated labs integrate instruments under a scheduler for near-autonomous operation, but they’re expensive and inflexible, keeping them out of reach of most academic labs, and AI-integrated versions are impractical beyond demos. MHS-based labs schedule all instruments through the standard, letting researchers monitor, control, and coordinate equipment; their AI-native architecture also lets agents actively participate in experiments.
Case study 1: Taking the lab remote
**Figure 2.** Monitoring instruments using MHS. Researchers can monitor the status of all connected instruments directly through the MHS dashboard or via an AI agent. (left) Screenshot of the MHS dashboard; (right) output from Claude Code after connecting to MHS.
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.
**Figure 3.** Using an AI agent to monitor and control an experiment in real time via MHS. We worked with Claude Code to automate the execution of a qPCR protocol, transmitting the curve for each cycle to the chat box in real time for review. Upon receiving a stop command, the system halted the protocol and loaded a hold protocol. (All curves represent actual images from the interaction with Claude Code; some output has been truncated.)
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.
CMU laboratory instruments. (left) The Analytik Jena CyBio FeliX liquid handler for automated pipetting and liquid-transfer workflows. (right) The Thermo Scientific Varioskan LUX multimode plate reader for microplate-based absorbance, fluorescence, and luminescence measurements.
CMU laboratory instruments, continued. The Thermo Scientific Spinnaker robotic arm for automated microplate handling and transport (left), with monitoring cameras used to observe plate movement and system operation (center and right).
A 96-well plate arranged as a serial dilution, with the concentration decreasing step by step across the columns from 200 µg/mL to 0.20 µg/mL. This produces a broad, predictable concentration range that can be measured to build a dose-response curve.
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.
Run 1. The first serial dilution experiment tested concentrations up to 200 µg/mL. At the higher concentrations, the measurement began to saturate, meaning the signal stopped increasing in a useful way. Because this made the dose-response curve less reliable, the system rejected the run and decided that the concentration range needed to be adjusted.
Run 2. The system automatically repeated the experiment with a lower maximum concentration of 100 µg/mL. This new range captured the changing response much more clearly, producing a stronger and more reliable dose-response curve. The improved fit was accepted without any human intervention.
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.
WHOLISTIC imaging of body-wide cellular activity in a larval zebrafish seven days post-fertilization. Maximum-intensity projection through the full volume of a young fish expressing the calcium indicator GCaMP7f in all cells, imaged with a customized mesoscope, a two-photon large field of view microscope. Fluorescence transients report intracellular calcium, a proxy for cellular activity, and are visible simultaneously in the brain, spinal cord, heart, gut, and peripheral tissue.
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.
Beam alignment using MHS. Data from a laser beam camera streams through the MHS state dictionary. A digital target (white cross) can be added to guide alignment, and the beam can be precisely centered manually or using motorized mirrors controlled by an agent.
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.
Online heartbeat tracking and prediction using MHS. Data from a camera imaging the ventral side of the animal is streamed through MHS, where it can be monitored using a generic MHS array slot viewer. Once in the MHS state dictionary, the data is instantly accessible to other processes, allowing for online identification of the heart and real-time tracking of heart activity (blue curve). Another process fits a predictive model enabling phase-locked stimulation (orange curve).
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