What Is the Model Hardware Standard (MHS)? The Definitive Guide

What is the Model Hardware Standard (MHS)?

The Model Hardware Standard is an open specification that lets an AI agent discover and operate physical equipment through one common interface, rather than through a separate custom integration built for each instrument. Anthropic describes it plainly as a shared specification for AI agents to safely operate physical devices. Where earlier AI worked entirely in text and pixels, MHS is the layer that lets a model reach out and turn a real dial.

The most useful way to place MHS is next to its software sibling. In 2024, Anthropic released the Model Context Protocol (MCP), a standard that connects AI applications to software tools, data, and services. One Anthropic staff member has described that earlier work as being like a USB port for connecting AI to software. MHS extends the same idea into the physical world: it is a universal connector between an AI agent on one side and microscopes, liquid handlers, robotic arms, and other instruments on the other. An agent that speaks MHS can operate any device that ships a compatible MHS driver, without an engineer wiring the two together by hand.

It matters to place MHS correctly in the stack. MHS is not a model, not a robot, and not a replacement for the instruments themselves. It is an interoperability layer. A large language model provides the reasoning, an AI agent supplies the autonomy and planning, MCP standardizes how that agent reaches software capabilities, and MHS standardizes how it discovers and drives the physical hardware that carries out the work. The machines stay the same. What changes is that they now expose themselves to agents in a single shared format.

In short: MHS is the open standard that connects AI agents to physical machines, the plug that lets a lab instrument built to the spec be operated by any compatible agent rather than through a one-off integration.

What problem does MHS solve?

MHS solves the physical-world version of the integration explosion that MCP solved in software. In a modern lab or advanced-manufacturing line, most devices do not communicate with each other. Each microscope, pump, sensor, or robotic arm speaks its own proprietary language, and connecting an agent to that fleet has meant paying specialists to build a bespoke bridge for every device, one at a time.

The cost of that fragmentation is measured in weeks and months. Anthropic notes that it typically takes a lab or manufacturing facility weeks, if not months, to set up and integrate their hardware, because each device requires its own custom translator. Jonah Cool, who leads partnerships on the effort, put the researcher's frustration bluntly, saying scientific equipment suffers from proprietary solutions that are very brittle. Every new instrument multiplies the work, and knowledge about how a given rig behaves often lives in paper manuals, on one scientist's laptop, or in nobody's notes at all.

MHS changes the shape of that problem. When every device exposes the same standardized driver, an agent implements the standard once and can then discover and operate any compliant instrument. The integration burden stops growing as a product of agents times devices and becomes a matter of each side implementing one spec. This is the same move that standards such as USB, HTTP, and the shipping container made in their own domains: replace many private couplings with one public interface, and an ecosystem forms on top. Anthropic reports that MHS reduces integration work from weeks to hours or minutes, and Cool frames the goal in terms of the people who use the equipment, saying the intent is to avoid vendor lock-in for scientists.

How does MHS work?

MHS works by wrapping each physical device in a standardized driver, making that device discoverable on the network, and letting an agent supervise the work at a high level while precise commands are carried out through a small, shared command set. Understanding the flow from agent to instrument explains the whole standard.

The chain runs from the agent, through a standardized driver, to the device. The driver is software that translates between a computer's operating system and a hardware device, exposing that device through a simple, uniform interface. Because every driver presents the same shape, the agent does not need to know the private protocol of each instrument. It issues standard commands, and the driver turns them into the specific signals the hardware expects.

Devices and agents also need to find each other. MHS makes each device discoverable in a standard format, so devices and agents can locate one another and communicate across networks without needing a bespoke translator program in between. Once discovered, a device advertises what it can do and what it is, which the agent reads before it acts.

State is shared, not guessed. In the reference implementation built at HHMI Janelia, the entire rig's state lives in a standardized dictionary held in shared memory, a region of the computer's memory that the operating system lets many programs read at once. That shared picture of what every instrument is doing lets an agent sequence steps across several machines, monitor results, and adjust parameters as conditions change in real time. When a task must run faster than an agent's live reasoning allows, or for long stretches, the agent can chain driver commands together in code files and let them execute autonomously, stepping back in to supervise rather than dictating every movement.

Anthropic's own two-minute launch video walks through what MHS is, how it works, and early examples of agents operating lab and manufacturing equipment.

In short: an MHS agent operates instruments through standardized drivers, discovers devices in a common format, tracks their state through shared memory, and supervises the work at a high level while chained commands handle fast or long-running execution.

What is an MHS driver, and what primitives does it use?

The MHS driver is the heart of the standard, and it is built from a deliberately small set of primitives. A primitive is a basic command that any hardware device can understand and act on, and MHS reduces the messy variety of device controls to a common vocabulary. The two foundational commands are read and write: read retrieves a value from the device, such as get temperature, and write sets a value on the device, such as set temperature. Almost any instrument action can be expressed as some combination of reading a state and writing a new one.

This minimalism is what makes the standard general. A microscope, a liquid handler, and a robotic arm are wildly different machines, but each can be described through the same read and write interface once its driver maps those primitives to the device's actual functions. An agent that learns the vocabulary once can therefore operate hardware it has never seen before, provided that hardware ships an MHS driver.

The driver also carries knowledge, not just commands. Critical information about a device, its quirks, its safe operating ranges, the tacit tricks an experienced operator knows, has traditionally lived in manuals or in a researcher's head. The MHS driver contains tags that let a user write this information directly in natural language, so an agent can read a plain-language description of how a device behaves rather than reverse-engineering it. An agent can even interview the user to capture that knowledge and store it in the driver, turning tacit expertise into something machine-readable. That natural-language layer is one of the clearest things that separates MHS from earlier, purely technical device standards.

In short: an MHS driver wraps a device behind a small set of primitives, chiefly read and write, and carries natural-language metadata about the device, so any compatible agent can operate unfamiliar hardware through one shared interface.

How do AI agents discover and control instruments under MHS?

Under MHS, agents reach devices through one of three control mechanisms, and the standard is intentionally flexible about which an agent uses. Anthropic describes three such mechanisms: the Model Context Protocol, the command line interface, and code files, which act as programmable interfaces or APIs. Each suits a different kind of task, and a single workflow can move between them.

The first path is MCP. Because MHS is built on top of the Model Context Protocol, any agent harness that already speaks MCP can access an MHS device using that standard protocol, the same way it would reach a software tool. This is what makes MHS model-agnostic in practice: an agent that supports MCP can operate hardware without a hardware-specific integration. The second path is the command line, which lets an agent or a person issue direct, discrete instructions to a device, useful for interactive control and quick operations. The third path is code files, where an agent writes and runs programs that chain many driver commands together. Code files are how MHS handles the cases where an agent needs to execute long-running tasks or operate devices faster than its online reasoning would allow.

The division of labor is the important idea. The agent works at the level of intent, deciding what experiment to run, in what order, and how to respond when results come back. The drivers and code files work at the level of precise, fast, repeatable execution. Between them sits the shared-memory state that keeps the agent's picture of the equipment current. That arrangement lets an agent sequence steps across several instruments at once, monitor the results as they arrive, and adjust parameters mid-run as conditions change, which is what separates an agent that runs an experiment from a model that merely suggests one.

In short: agents control MHS devices through three mechanisms, MCP, the command line, and code files, choosing among them by task, while operating at the level of intent and leaving precise execution to the drivers.

How does MHS keep physical operations safe?

MHS is built around safety because the failure modes are physical, and Anthropic has layered protections at several levels rather than relying on the agent's judgment alone. A wrong answer from a chatbot is a nuisance. A wrong action from an agent holding a robotic arm, a chemical dispenser, or a laser can damage a sample, an instrument, or a person, so the standard treats the hardware boundary itself as a place to enforce limits.

The protections operate in layers. Safety limits are enforced at the driver level, so a device can refuse a command that would drive it outside its safe operating range regardless of what an agent requests. A vendor can specify in an MHS file how an AI may move a heavy arm safely, for example limiting the speeds and angles it is allowed to use, and that limit holds no matter what the agent asks for. Systems are designed to recover from hardware errors without intervention, so a routine fault does not require a human to step in. Before automation runs, safety checks validate conditions to block dangerous states, and the standard supports requiring human approvals for high-risk decisions, keeping a person in the loop where the stakes are highest. Anthropic also says it is developing a physical safety roadmap to further bolster its safeguards as the standard matures.

The company's caution is also visible in how it is releasing MHS. Rather than shipping the standard openly on day one, Anthropic is sharing an early version with a limited group of vetted partners so it can build safety evaluations and best practices before making the standard open source, stating plainly that it has more work to do on the standard before it opens it up. That staged approach, preview first and open release later, is itself a safety mechanism, because it lets failure modes surface in controlled settings with expert operators present. The honest counterpoint, which any careful reader should hold, is that guardrails like these tend to face pressure once a standard starts racing for broad adoption, and that a universal control layer also widens the security attack surface, a concern practitioners raised immediately after the preview.

In short: MHS enforces safety at the driver level, for instance capping a robot arm's speed and range of motion, recovers from routine errors automatically, validates conditions before automation, supports human approval for high-risk actions, and is being released in a staged preview so failure modes surface before an open launch.

How is MHS different from the Model Context Protocol?

MHS and MCP are the same strategic idea aimed at two different worlds, and the cleanest way to understand MHS is by its contrast with the software standard that preceded it. MCP connects an agent to software: tools, data, and APIs. MHS connects an agent to hardware: instruments and machines. MHS is not a competitor to MCP but an extension of it, since MHS is built on top of MCP and uses it as one of its control paths. Viewers of the launch summed it up in three words: MCP for hardware.

The difference that matters most is the nature of failure. When an MCP tool call goes wrong, the result is a bad answer or a failed request, recoverable with a retry. When an MHS action goes wrong, the result can be a ruined experiment, a damaged instrument, or an unsafe machine state, which is why so much of the MHS design is about enforced limits and human approval that MCP never needed. The two standards also differ in maturity: MCP is an openly published, broadly adopted standard now stewarded by a neutral foundation, while MHS is a research preview that Anthropic still controls and has not yet opened.

The relationship is best read as layers rather than rivals. An agent can use MCP to pull a protocol from a database and MHS to run that protocol on the bench, in the same workflow. For a full treatment of the software layer, see our guide to the Model Context Protocol.

In short: MCP connects agents to software and MHS connects them to hardware, MHS is built on top of MCP rather than competing with it, and the defining difference is that MHS failures are physical, which is why safety enforcement sits at its center.

How does MHS relate to existing standards like ROS, SiLA, and OPC UA?

MHS is not the first attempt to make machines interoperable, and understanding what already exists is the fastest way to see what is genuinely new about it. Laboratories and factories have standardized device communication for years. SiLA 2, the Standardization in Lab Automation standard, defines how laboratory instruments and software connect. OPC UA is the dominant machine-to-machine communication standard on the factory floor. The Robot Operating System (ROS) provides a widely used framework of hardware abstraction, drivers, and message passing for robotics. Academic efforts such as the laboratory automation plug-and-play (LAPP) framework have pushed toward the same plug-and-play goal MHS describes.

What MHS adds is an agent-native layer designed for the way large language models actually work. The existing standards were built for deterministic software talking to deterministic software: a program that already knows a device's interface exchanges structured messages with it. MHS assumes the thing operating the device is an AI agent that reasons in language and needs to discover, understand, and safely drive hardware it was never explicitly programmed for. Its two distinguishing features follow from that assumption: a minimal read and write primitive set an agent can generalize across unfamiliar devices, and natural-language metadata that lets an agent read, in plain English, how a device behaves and where its limits are. That is a different problem from the one SiLA 2 or OPC UA set out to solve.

The relationship is therefore complementary more than competitive. Because MHS reaches devices through MCP, the command line, or code, an MHS driver can in principle sit on top of, or alongside, an instrument that already speaks SiLA 2 or a robot that already runs ROS, wrapping it in the agent-facing layer rather than replacing its underlying control stack. The open question, and the reason the incumbents matter, is adoption: labs and manufacturers have invested heavily in these existing standards, and MHS will succeed only if it is easy to layer over them rather than a rip-and-replace. Anthropic's choice to build on MCP and to plan an open-source release is a bet that layering, not replacement, is the path.

In short: standards like SiLA 2, OPC UA, and ROS already connect lab and factory devices, and MHS differs by being built for AI agents, adding a minimal read and write vocabulary and natural-language documentation, so it is best understood as an agent-facing layer that can sit over existing standards rather than a replacement for them.

Where did MHS come from, and what is HHMI Janelia?

MHS did not start as a product plan. It started with one frustrated scientist and a microscope that would not cooperate. Arco Bast, a postdoctoral researcher at the Howard Hughes Medical Institute's Janelia Research Campus, studies how neurons communicate and how populations of neurons work together to form memories. Trained first as a medical doctor in Germany before turning to neuroscience, he had built a custom microscope whose cameras, scanners, sensors, lasers, and mirrors were each controlled by different software written in different programming languages. Getting them to work together for a new experiment took months of engineering. As he described it, standing in front of the rig left him frustrated that he could not get to his desired experiment quickly.

His fix became the seed of MHS. Working with Claude Code, Bast built a system in which the microscope's components share a single pool of memory they can all read and write, rather than passing messages through a central program, so every part looks at and updates the same live picture and can respond to changes immediately. Setup time dropped from months to days, and something new became possible: an AI agent could watch the experiment as it ran and, in his words, look at what is happening while the experiment is running and steer it. That shared-memory design is the reference architecture at the heart of MHS, and the collaboration between Bast and Anthropic's Alek Kemeny is where the standard began. Colleagues describe the shift in ambition rather than just convenience, with one Janelia scientist saying it changed what he thought was possible as a scientific project.

The choice of birthplace is not incidental. HHMI's Janelia Research Campus, founded in 2006 outside Washington, DC, exists to take on scientific problems too large for a typical university or company lab, and it made its name building tools the rest of biology now depends on, from fluorescent sensors and advanced imaging to brain connectomes. Janelia has since organized around two big bets: decoding the brain, meaning a mechanistic account that links molecules, neurons, circuits, and behavior in a living vertebrate, and reinventing how science is done through an AI-in-the-Loop approach in which, as the institute describes it, the discovery loop compresses from months to days and AI and laboratory experiments work together as one continuous system. MHS is the connective tissue that second bet requires, which is why the brain-imaging bench of a Janelia postdoc turned out to be exactly the right place for it to be born.

What has MHS achieved so far, and who is building on it?

MHS has already run real instruments in real labs, and the early partner-reported results are the strongest evidence for what the standard enables. These figures come from Anthropic's preview partners rather than independent benchmarks, so they should be read as early demonstrations, but they are specific and consistent.

The clearest wins are in integration speed. At Carnegie Mellon University, connecting instruments for serial dilution experiments took about eight hours, against the several weeks a vendor-built setup typically requires, and the resulting automated workflow ran roughly three times faster than the previous method. At the University of Washington, a researcher integrated six instruments in under a week. Those are the numbers behind Anthropic's claim that MHS turns weeks of integration into hours.

The performance and autonomy demonstrations go further. At QuEra Computing, an agent supervising the lasers inside a quantum computer improved the laser relock process from 150 seconds at a 58 percent success rate to 6 seconds at 99.3 percent success. At Genentech, one of the companies that pioneered the biotechnology industry and now part of the Roche Group, Claude autonomously optimized liquid-handling parameters with expert-level accuracy, pointing at a near-term use case in drug-discovery labs where liquid handling is a daily bottleneck. At Carnegie Mellon, an agent independently rejected poor dose-response curves and reran the experiment with better parameters until the fit exceeded an R-squared of 0.98. Anthropic also cites collision-free handoffs between multiple robots, remote real-time supervision of qPCR runs, and autonomous detection and recovery from hardware errors.

The ecosystem forming around MHS is broad. Anthropic lists partners building MHS support across robotics, lab automation, and hardware, including Amazon Web Services through its Strands Robots library, Automata, Danaher, Doosan Robotics, MBF Bioscience, QIAGEN, Tecan, Universal Robots, Hugging Face through its LeRobot library, and Raspberry Pi. The target domains span scientific research, from drug discovery and de novo protein design to microscopy, neuroscience, and quantum-computer calibration, and advanced manufacturing. Alongside the standard, Anthropic expanded its AI for Science program beyond biology and offered 10,000 free Claude subscriptions to researchers, signaling that it sees the scientific community as the standard's first home.

What does regulation mean for MHS?

Regulation is the part of the MHS story that gets the least attention and may matter the most, because an MHS file does not just describe a machine, it can govern how that machine is allowed to move. When a driver caps a robot arm's speed and range of motion, that constraint is a safety function, and safety functions are regulated. Whoever writes that MHS specification may, in effect, be authoring a regulated safety component without thinking of it that way.

The timing sharpens the point. In the European Union, Regulation 2023/1230, the new Machinery Regulation, replaces the long-standing Machinery Directive entirely on January 20, 2027, and for the first time it explicitly covers AI-based safety functions and machinery with self-evolving behaviour. Under that regime, a simple self-declaration of conformity is no longer sufficient for the highest-risk categories. An agent that adjusts a machine's behaviour as conditions change is close to the definition the regulation was written to capture, so an MHS deployment operating a machine in the EU could fall within scope, with the documentation, conformity assessment, and accountability that implies.

The takeaway for anyone evaluating MHS is that the standard's technical convenience and its regulatory weight are two sides of the same feature. The reason MHS is powerful, that it can encode and enforce how a machine behaves, is exactly the reason it attracts safety regulation. For labs and manufacturers, that means an MHS rollout is not only an engineering decision but a compliance one, and the natural-language safety metadata that makes MHS easy to use is likely to become part of the audit trail regulators ask to see.

In short: because an MHS file can constrain how a machine moves, it can qualify as a regulated safety component, and rules such as the EU Machinery Regulation taking effect on January 20, 2027, which covers AI-based safety functions for the first time, mean MHS deployments carry compliance obligations, not just engineering ones.

What are the limitations of MHS today?

MHS has real and openly acknowledged limits, and the most important ones come from the models rather than the standard itself. Anthropic is candid that a large language model learns about the physical world through text and images, so its spatial and physical reasoning have limitations that still require expert oversight. An agent that has never felt a pipette can misread what is happening on the bench.

Those gaps show up concretely in the preview. At Genentech, researchers had to teach Claude that errors caused by foaming in samples were physical failures, not software bugs, a distinction obvious to any human at the bench. At QuEra, the agent often stopped to wait for human confirmation before performing an action it deemed even slightly risky, and when hardware failed physically, Claude did not know how to troubleshoot, because its understanding of the rig was programmatic rather than physical. The same caution that makes an agent safe can also make it slow and dependent on a nearby expert.

There are practical limits too. MHS does not yet work with hardware that lacks a programming interface, so devices that can only be operated by hand fall outside the standard until manufacturers build in MHS drivers, which Anthropic says it is working on with those makers. Running an agent continuously over long monitoring windows also carries compute costs that have to be weighed against the researcher time saved. And because the standard is a research preview that is not yet open source, its specifics can change, and the safety evaluations that would let it operate with less supervision are still being built. None of this undercuts the direction, but it means MHS today is a supervised tool for experts, not an autonomous lab in a box.

In short: MHS is limited by models whose physical and spatial reasoning still need expert oversight, by hardware that lacks a programming interface, and by the compute cost of continuous operation, so it currently augments skilled operators rather than replacing them.

Why does MHS matter for AI, science, and manufacturing?

MHS matters because it is a serious attempt to define the interface layer between AI and the physical world, and interface layers are where lasting advantage in computing accumulates. The immediate value is speed in the lab: a team that once wrote custom code to link an agent to each instrument can connect them through one standard and let an agent run experiments around the clock, catching and recovering from faults as it goes. That turns a model from an assistant that suggests experiments into a system that runs them, which is the working definition of the self-driving laboratory that materials and chemistry researchers have been building toward for years.

The scientific stakes are high because instrumentation, not ideas, is often the bottleneck. Reviews of self-driving laboratories in the chemical sciences describe autonomous experimentation as a path to compress discovery cycles that currently run in months into ones that run in days, by letting systems design, run, and learn from experiments in a continuous loop. A common hardware standard is exactly the missing piece those systems have needed, because without one, every autonomous lab has had to be hand-built. If MHS becomes that piece, it lowers the barrier to autonomous science for labs that could never afford bespoke integration.

The strategic stakes explain why Anthropic moved first. Physical AI, the effort to push models out of the chat window and into machines, is where a large share of the next wave of AI companies is being built, and it drew a crowd in 2026: on the same day Anthropic previewed MHS, Hugging Face launched its own physical-AI hardware, part of an industry-wide turn toward robotics and embodied systems. Nvidia's Jensen Huang has called physical, or embodied, AI the next wave of the technology and told investors the opportunity in robotics and humanoids runs into the tens of trillions of dollars over the coming decade, and whether or not those specific figures hold, they capture where the industry's attention and capital are moving. Whoever defines the standard those machines speak sits at the center of that ecosystem. If the interface is Anthropic's, then Claude is well positioned to operate the machines, the safety framework is Anthropic's framework, and competitors arrive to a layer that has already been defined, the same position MCP handed Anthropic in software. That MHS is model-agnostic and slated to become open source tempers the lock-in concern, but the first mover on an open standard still shapes it. For anyone tracking where AI is heading, MHS is a layer to watch, because it is where autonomous agents stop merely thinking about the world and start acting on it.

A brief timeline of MHS

Frequently asked questions

Sources and further reading

1. Anthropic. Previewing the Model Hardware Standard. August 2026. anthropic.com
2. Anthropic and Howard Hughes Medical Institute. Model Hardware Standard: AI operating physical equipment. Launch video, August 2026. youtube.com
3. Model Hardware Standard. Research preview and access applications. modelhardwarestandard.com
4. Anthropic. Introducing the Model Context Protocol. November 2024. anthropic.com
5. Fortune. Anthropic makes its first move into physical AI with a universal standard for scientists and manufacturing. August 27, 2026. fortune.com
6. CNBC. Anthropic pushes into the physical world with new standard to help AI agents operate machines. August 27, 2026. cnbc.com
7. European Union. Regulation (EU) 2023/1230 on machinery (the Machinery Regulation), applicable from January 20, 2027. eur-lex.europa.eu
8. Nature Reviews Chemistry. The past, present and future of self-driving laboratories. 2026. nature.com
9. Nature Communications. Science acceleration and accessibility with self-driving labs. 2025. nature.com
10. SLAS Technology (ScienceDirect). Towards robotic laboratory automation Plug and Play: the LAPP framework. 2021. sciencedirect.com
11. Howard Hughes Medical Institute. How One Postdoc's Problem Solving is Changing the Way Scientists Work. 2026. hhmi.org
12. Howard Hughes Medical Institute. Janelia's Two Big Bets: Decoding the Brain and Reinventing How Science is Done. 2026. hhmi.org