MHS Use Cases: Early Examples in Labs and Robotics

These MHS use cases are early examples described in the public research-preview announcement for the Model Hardware Standard. They show the kinds of workflows the project is exploring: connecting heterogeneous devices, exposing their state and operations, coordinating actions, and helping an agent respond to live results. They are not independent validation, product guarantees, or a complete list of supported devices.

Independent resource: MHSBase is an unofficial, independent community resource. It is not affiliated with or endorsed by the Model Hardware Standard project or its contributors, and it is not the official MHS website.

Updated: August 28, 2026

How to read these MHS use cases

The examples below come from one public announcement about an early research preview. Each project used a particular set of instruments, drivers, models, operators, protocols, and experimental conditions. A result reported for one setup should not be treated as a promise that another lab can reproduce it without engineering work.

The common thread is not “AI replaces the lab.” The common thread is that a standardized hardware interface can give an agent a clearer way to discover equipment, read state, issue bounded operations, and coordinate a workflow. Human experts remain important for experimental design, safety limits, troubleshooting, and validation.

For the underlying idea, start with What Is MHS?. For the public concepts behind drivers and device state, see the MHS specification summary. For access context, see the MHS research preview guide.

Genentech: BCA protein assay and MHS liquid handler coordination

The project announcement describes a Genentech proof of concept for automating a BCA protein assay, a procedure used to measure total protein concentration in a sample. The workflow coordinated a liquid handler, a robotic arm, and a microplate reader. The liquid handler performed precise transfers, the arm moved labware, and the reader measured optical absorbance.

The report describes an agent orchestrating the connected instruments and testing liquid-transfer settings. The experiment compared water with viscous bovine serum albumin samples, where flow rate affects bubbles and transfer accuracy. The agent used measurements to adjust the process and encountered errors including tip pickup and fluid detection issues. The team had to provide physical context about bubbles and gentle handling before the recovery behavior became more sensible.

This is a useful MHS liquid handler example because the value is not just a command sent to one instrument. The workflow combines a liquid-handling operation, a physical handoff, and a measurement that feeds back into the next decision. The common device interface helps the system coordinate those roles, while the domain expert still defines what a good transfer means.

HHMI Janelia: MHS microscope and microscopy research

The public materials describe HHMI Janelia researchers using MHS with a microscopy rig assembled from many components and vendor programs. The system included lasers, mirrors, detectors, cameras, translation stages, and other equipment that had not been designed with one shared interface. Before the integration, starting an experiment involved several programs and many point-to-point connections.

The reported integration gave the project a shared representation of device state and data streams. The materials discuss reusable online analysis, generic viewers for different data types, and a harness that allowed an agent to read and write variables through one interface rather than separate vendor APIs. In the microscopy work, an agent could help choose acquisition and analysis actions at decision points while device-level limits remained important.

This is the clearest MHS microscope example in the public set. It shows why a device-control standard needs to cover data and action together. An agent may read an image or signal, analyze it, and then adjust a physical setting. A stable state representation can make that loop easier to build and reuse, but scientific goals and physical tradeoffs still require expert supervision.

University of Washington: qPCR monitoring and MHS robotic arm handoffs

The public announcement describes the Baker and Pinglay labs using MHS for several related demonstrations. One involved remote monitoring of instruments through a dashboard or an agent. Another involved an AI-supervised qPCR workflow that watched amplification curves and halted the procedure at an appropriate moment. The lab also integrated a robotic arm and a liquid handler for plate handoffs.

The qPCR example shows a monitoring-and-decision loop: data arrives during the run, the system interprets the curve, and a stop command can advance the instrument to a hold step. The handoff example shows a different coordination problem. The arm should move only after dispensing has finished, and the liquid handler should not begin again until the arm has cleared the plate. The reported demonstration kept those actions sequenced correctly.

This is an important MHS robotic arm use case because the difficult part is not merely moving an object. It is knowing when the move is safe and meaningful in relation to another device. State, timing, completion signals, and failure handling are as important as the motion command.

Carnegie Mellon University: dose-response automation

The public project materials describe Carnegie Mellon University researchers using MHS to coordinate a liquid handler, plate reader, robotic arm, and monitoring cameras for serial-dilution dose-response experiments. The equipment was spread across three computers and exposed incompatible interfaces, including a file-based scheduler, an older Windows scripting interface, and a plate reader controlled through its graphical interface.

The announcement says MHS turned the different systems into a consistent representation of states and procedures. The agent could prepare a dilution series, check plate position, move the plate, collect the measurement, inspect the resulting curve, and decide whether to adjust the range and run again. The reported setup was described as a roughly three-times-faster proof of concept with integration completed in about eight hours.

This example matters for AI lab automation because “programmable” does not always mean “modern API.” Real equipment can have old, awkward, or mismatched interfaces. A common integration layer can be useful precisely when the laboratory has to bridge those differences. The reported speed and accuracy results are specific to the described experiment and should be evaluated locally before being generalized.

QuEra Computing: laser stabilization

The public announcement describes QuEra using MHS to give an AI agent access to parts of a laser system inside a neutral-atom quantum computer. The problem was recovering a laser's frequency lock after disturbances. The agent loop tested disturbances, improved a recovery script, and eventually produced a deterministic, inspectable controller.

In the reported blind test, the controller recovered the correct lock in 695 of 700 trials, or 99.3%. The most difficult induced disturbances took seconds in that test, while a human recovery could take several minutes. The materials also describe a separate tuning workflow in which an agent adjusted parameters and analyzed measurements over many experiments.

The distinction between exploration and deployment is important. The agent helped discover and improve a procedure, but the reported relock result was a deterministic script that could run without an agent in the loop. Those figures belong to the tested laser system and conditions; they are not a universal performance target for MHS hardware or every physical-control workflow.

Tetsuwan Scientific: qPCR for environmental monitoring

The project announcement describes Tetsuwan integrating MHS with its ResearchOS automated biology platform for a qPCR workflow studying pollution in California's San Pedro Creek. ResearchOS turns natural-language protocols into executable automation, while MHS provided an orchestration layer for a fleet of pipetting robots, robotic arms, and other equipment with different interfaces.

The public description includes a camera detecting bubbles or foam during liquid handling. When an error was found, the system could search for an MHS-connected device that might help. In the reported example, the agent suggested moving a tube to a centrifuge and then issued the appropriate commands through MHS. The project also used MHS to retrieve measurement data and improve predictions about transfer precision.

This is a useful MHS lab automation example because it connects error detection, device discovery, recovery, and measurement. It also shows why an agent needs more than a command list: the system must understand what a device can do, what another device might contribute, and when a proposed recovery should be reviewed by a person.

What these MHS examples have in common

Several patterns appear across the early MHS examples:

1. Heterogeneous interfaces: the equipment does not need to share one vendor or one programming style.
2. State before action: an agent can use measurements, status, or camera observations before deciding what to do.
3. Coordination across devices: timing and handoffs become explicit parts of the workflow.
4. Closed-loop adjustment: results can influence parameters or trigger a repeat run.
5. Deterministic follow-through: an exploratory agent can package a learned procedure into code.
6. Safety and oversight: physical limits, failure modes, expert context, and human approval remain part of the system.

These are design patterns suggested by the reports, not a promise that every MHS integration will contain all six. They also explain why use cases should be evaluated as workflows rather than as isolated demos. The same driver that works for a single measurement may need additional state, timing, or failure handling when placed in a larger device chain.

What the examples say about AI lab automation

The cases suggest that AI lab automation is not one feature. It can mean remote monitoring, adaptive parameter selection, instrument handoffs, error recovery, online analysis, or the generation of deterministic scripts. These tasks have different risk profiles and different evidence requirements.

A low-risk monitoring action may read a status value and notify an operator. A more complex workflow may decide whether to stop a qPCR run, move a plate, adjust a liquid-transfer parameter, or recover a laser lock. Before deploying any of them, a team should define the allowed action range, the conditions that block the action, the human approval points, and the logs needed to reconstruct what happened.

The public examples also suggest a progression: first describe the device, then connect it to a workflow, then add observation and feedback, and only after that consider greater autonomy. This progression is more useful than treating an agent as a magic layer that removes all engineering.

Limits of the evidence

The public announcement is a primary source for what these teams reported, but it is still a description of early projects. It does not establish a universal benchmark, independent audit, support matrix, or production guarantee. Some experiments used induced failures, demonstrations, dyes, or specific hardware configurations. Transferability must be tested in the target environment.

Numbers should be kept in their original context. A reported success rate belongs to a particular test set. A reported time reduction belongs to a particular integration. A proof of concept does not prove that an unrelated microscope, liquid handler, robotic arm, or manufacturing line will behave the same way.

If you are evaluating a new project, define the devices, workflow, safety boundaries, baseline, success metrics, and human intervention points. Then use the MHS research preview page to understand the current access context and the MHS specification summary to review the concepts that should be documented.

Conclusion: what MHS use cases show

The clearest takeaway from the public MHS use cases is that the standard is aimed at the messy middle between an AI agent and real equipment. It can help organize device descriptions, state, operations, timing, and feedback across instruments that were never designed to work together.

The examples are promising demonstrations, not a substitute for local engineering, domain expertise, or safety review. Read them as patterns for asking better questions: What must the driver expose? What can the agent observe? What action is permitted? What should happen on failure? What evidence will show that the workflow is safe and useful?

Sources

• The Model Hardware Standard project's public research preview announcement and project materials.
• For access context, see the MHS research preview guide.