On 27 August 2026, Anthropic opened a research preview of the Model Hardware Standard (MHS): a shared specification that lets AI agents safely operate physical devices – microscopes, liquid handlers, robotic arms, plate readers, lasers. Unlike most announcements in the agent space, this is not another protocol for text-based tools. It is the step from the screen to the lab bench and the factory floor.
For companies in the DACH region this matters for two reasons. First, MHS addresses a problem anyone who has ever integrated equipment from different vendors knows well: every device ships with its own software, its own data format and its own driver, and integration takes weeks to months. Second, MHS is deliberately built as a complement to the Model Context Protocol (MCP) – if you already use MCP, this is the missing layer below it, down to the hardware.
This article explains what MHS is, how it works technically, what the partner labs have already demonstrated – and what it means for mid-sized companies with labs, test benches or production lines.
What MHS is – and what it is not
MHS is a specification for the driver layer between AI agent and device. The standard defines how a device describes itself, how it is addressed and which safety limits the driver itself enforces. According to Anthropic it works with any device that has a programmable interface – whether that is a modern REST API, a legacy COM interface or nothing but a graphical UI.
MHS is model-agnostic. Any agent harness can access it through standard protocols such as MCP. The partner projects run on Claude, but the specification itself does not prescribe a model.
MHS is not open source yet. The standard is currently in a gated research preview for a first group of research labs and advanced manufacturers. Anthropic wants to use the preview to build safety evaluations and best practices together with the partners, and then release the standard as open source. Interested organisations can apply at modelhardwarestandard.com.
MHS does not replace MCP. MCP standardises how an agent discovers and invokes tools. MHS standardises how a physical device becomes a tool in the first place. An MHS device can then be exposed to the agent via MCP – MCP is one of three control paths MHS provides.
Anthropic accompanied the announcement with a short video that shows the core idea in just over two minutes:
A second video with a closer look at the partner labs is also on Anthropic’s channel: AI models can now help run physical science experiments.
How MHS works technically
The full specification is not public yet. But from the announcement, the partner labs’ reports and the blog posts by QuEra and Tetsuwan, the architecture can already be reconstructed quite well. It consists of four building blocks.
1. A standardised driver with two primitives
At the core of MHS is a driver that translates between the operating system and the device. Instead of learning a separate command semantics for each device, the agent works with a very small vocabulary: read (for example “get temperature”) and write (for example “set temperature”). Any device that understands these primitives can be addressed the same way – whether it is an incubator, a galvanometer mirror or a robotic arm.
Carnegie Mellon University describes the result like this: MHS turns each device into a single manifest of states and procedures. States are conditions the system can be in (“plate at position 3”, “sample at 25 °C”, “well filled”); procedures are the operations it can execute. What sits behind the manifest – a directory watcher, an ActiveX/COM interface or a GUI with no API at all – is invisible to the agent.
2. Discovery and a shared state dictionary
Every MHS device makes itself discoverable in a standardised format. Devices and agents can find each other across networks without anyone writing a bespoke translator program in between.
The idea behind this comes from the HHMI Janelia Research Campus, where MHS was developed together with Anthropic: the entire state of a device rig lives in a standardised dictionary in shared memory – a region of memory that many programs can access at once. Every variable, every control, every sensor value gets a documented slot. A detector in MATLAB, a camera in Python and an electrophysiology tool in C# read from and write to the same dictionary. Analysis and visualisation code becomes device-independent and reusable in any language.
3. Natural-language tags instead of paper manuals
A robotic arm has a weight, a sensor has a measurement range, a motor has a maximum speed. Until now this information has lived in PDF manuals, on a colleague’s computer or nowhere at all. The MHS driver therefore contains tags in which the user writes such characteristics directly in natural language. Alternatively, an agent can interview you about each device. The driver compiles this into reference files that document what a device measures, which parameters can be adjusted and which safety limits apply.
This lets an agent operate a device it has never seen before – because the reference file explains not just the API but the physics behind it.
4. Three control paths: MCP, command line, code files
Once the devices are connected, the agent needs a way to control them. MHS offers three that work together:
- MCP for connecting any agent harness and for interactive reasoning over individual steps.
- Command line for direct calls and scripting.
- Code files (APIs) in which the agent chains driver commands across multiple devices.
The third path is the decisive one for production use. An LLM reasons in seconds; a laser control loop needs milliseconds. For long-running or fast workflows, the agent therefore writes a deterministic program once, which the devices then execute on their own – without the model having to think at every step. QuEra puts it succinctly: what runs on the bench is a deterministic, fully inspectable program – AI-driven in development, human-orchestrated, autonomous in operation.
Safety lives in the driver, not in the prompt
The most important point for decision-makers: safety limits are enforced at device level by the MHS driver, not by the model. The device declares its limits, interlocks and independent emergency stops remain in force, and the driver blocks commands outside the permitted range before anything moves. CMU tested this explicitly: six artificially induced fault conditions – missing plate, rotated plate, busy reader, disconnected camera, unreachable device, active emergency stop – were all correctly blocked before any device moved.
What the partner labs have already shown
The announcement is unusually concrete because six partners back their results with numbers. An overview:
| Partner | Task | Result |
|---|---|---|
| Genentech | BCA protein assay across liquid handler, robotic arm and plate reader | Claude optimised flow rates autonomously (approx. 140 µL/s for water, 10 µL/s for viscous samples); automation experts confirmed the values |
| University of Washington (Baker and Pinglay labs) | Remote monitoring, AI-supervised qPCR, collision-free plate handoffs | Six instruments integrated in under a week, including writing the drivers |
| Carnegie Mellon University | Serial dilution dose-response experiments | Roughly three times faster; integration in eight hours instead of several weeks; all six fault scenarios blocked |
| HHMI Janelia | Multi-component microscopy spanning seven vendor programs | One single interface; new camera integrated in minutes instead of days |
| QuEra Computing | Laser stabilisation on a quantum computer | Auto-relock success rate up from 58% to 99.3% (695 of 700 trials); recovery in seconds instead of 5–10 minutes |
| Tetsuwan Scientific | qPCR workflow for citizen-science water monitoring | Camera-detected bubble errors trigger automatic centrifugation; 9,143 dispenses measured for calibration |
Two examples deserve a closer look.
QuEra had a linear script for relocking a Ti:Sapphire laser that worked 58% of the time and took around 150 seconds per attempt. Via MHS, the agent got read access to instrument data and write access within declared limits. In one night of iterative attempts – propose, test on the hardware, read the result, refine – it rebuilt the sequence into decision-tree logic that first classifies the disturbance and then fixes it specifically. In PID tuning, the residual error dropped from 15.7 mV to 1.55 mV. The point that goes beyond the numbers: bringing up a new wavelength, which had originally taken weeks, took the team one night with the knowledge gained.
Tetsuwan shows how MHS fits into an existing automation architecture. The company replaced its previous scheduler with an MHS-based system and connected devices without vendor support through small single-board computers acting as MHS connectors. A protocol now just says “spin the plate at 15,000 rpm” – the system queries which devices are available, and Claude translates the parameters to the specific machine. When the camera detects bubbles in a pipette tip, the agent proposes a correction that an operator approves via Slack before it is executed.
Limits: where current models still fail
Anthropic and the partners name the weaknesses as openly as the successes. The recurring finding: frontier models are strong in general reasoning but weak in physical intuition.
Genentech provides the clearest example. In the first run, Claude chose the same flow rate for water and for viscous protein solution. The result: bubbles in the viscous solution, inaccurate transfers, error codes from the liquid-level sensors, distorted optical readings. The model could read the error code but could not infer the physical cause. Only after a human explained that bubbles were the problem and that fewer mixing cycles would help did the model keep that context for the rest of the run. Genentech subsequently turned these lessons into reusable skills so that Claude picks sensible default parameters for liquids of varying viscosity next time.
The consequence for operations: for now, the agents’ understanding remains programmatic rather than physical. They need a lot of context, and on risk-related decisions they frequently pause and ask – which is intentional at this stage. CMU plans further safety checks and clear rules on when human approval is mandatory.
Who supports the standard
A standard is worth as much as the devices that speak it. At launch, Anthropic names vendors and platforms building MHS support: Amazon Web Services (via the Strands Robots library), Automata (LINQ lab platform), Danaher, Doosan Robotics, MBF Bioscience (ScanImage microscopy software), QIAGEN (QIAsymphony Connect), Tecan (Fluent liquid handlers) and Universal Robots.
With Universal Robots and Doosan, two of the relevant vendors for collaborative robot arms – widespread in German manufacturing – are on board. That is the signal that MHS is not meant to stay confined to life-science labs.
Putting it in context: MCP, SAM, MHS – the layers are sorting themselves out
Anyone following agent standards over the past eighteen months will recognise a pattern. The layers are separating cleanly:
- MCP defines how an agent discovers and invokes tools – the semantics.
- Google SAM defines how MCP calls are transported with authorisation across network boundaries – the transport.
- MHS defines how a physical device becomes a tool an agent can safely operate – the hardware abstraction.
For IT decision-makers this means: an investment in MCP competence does not expire when hardware enters the picture. On the contrary – the governance questions we described in MCP as a Standard for Agent Tool Usage: Yes, But Please Securely only become more urgent with physical devices. A wrongly authorised tool call deletes a file in an office context. In a lab, it moves a robotic arm.
What this means for mid-sized companies
MHS is a research preview for labs and manufacturers today. Still, three things are worth doing now.
First: inventory your devices with programmable interfaces. Test benches, measurement instruments, cameras, cobots, climate chambers, analytical equipment – anything with an API, an SDK, a serial interface or even just an operable GUI is a potential MHS candidate. CMU connected a plate reader with no programming interface at all. The question is not whether your devices can be integrated, but which processes would benefit most from integration.
Second: lay the MCP foundation. MHS connects to agents via MCP. If you already run a properly secured MCP layer with permissions, audit logs and approval processes, you have done the hard part of the governance work. What such a layer looks like in a company is something we cover in our AI strategy consulting.
Third: ask the compliance questions early. An AI agent that moves machines touches machinery law, product safety and – depending on the use case – the EU AI Act’s requirements for safety components. The pattern all MHS partners use is the right one from a compliance perspective as well: deterministic programs in operation, safety limits in the driver rather than in the prompt, human approval for risky decisions. Which documentation and control obligations apply in your case is something we clarify in our AI compliance consulting.
Conclusion
The Model Hardware Standard is the first serious attempt to standardise the integration of physical devices for AI agents – with a small driver vocabulary, a shared state dictionary, natural-language reference files and safety limits at device level. The partner numbers are solid: integration times down from weeks to hours, success rates up from 58% to 99.3%, six instruments in under a week.
The limits are just as clear. The models understand code, not physics. Operation works because humans set the frame, safety limits live in the driver and the agent asks when in doubt. That is not a shortcoming of the concept – it is its architecture.
For companies with labs, test benches or production lines, now is the right time to review your own device landscape and lay the MCP groundwork. When MHS becomes open source after the preview, the head start will not be decided by the technology but by the preparation.
If you would like to assess which processes in your company are candidates for agent-operated hardware, get in touch.
Sources: Anthropic: Previewing the Model Hardware Standard (27 Aug 2026) · Model Hardware Standard – Research Preview · Anthropic on YouTube: Model Hardware Standard: AI operating physical equipment · QuEra: Holding the Light – Teaching an AI to Lock and Tune Our Quantum Computer’s Lasers · Tetsuwan Scientific: MHS · CNBC: Anthropic pushes into physical world with new standard to help AI agents operate machines