Evidence-first verdict: Anthropic’s Model Hardware Standard is a credible attempt to give AI agents a common way to discover, understand, and operate physical equipment. Its partner pilots show why that layer could matter. They do not yet establish MHS as an open, production-ready, or independently validated industry standard.
Testing disclosure: Kingy.ai did not receive access to the MHS research preview and did not reproduce the partner results. This analysis is based on Anthropic’s public announcement, embedded partner accounts, linked technical material, and public repositories. Performance figures below are attributed to the organizations reporting them.
On August 27, 2026, Anthropic opened a limited, application-only research preview of the Model Hardware Standard, or MHS. The immediate pitch is practical: connect microscopes, liquid handlers, cameras, robotic arms, laser systems, and other programmable devices through one shared interface, then let an AI agent coordinate the workflow.
The deeper idea is more consequential. MHS tries to turn physical equipment into something an agent can discover and reason about without a bespoke integration for every model, machine, and experiment. Anthropic says facilities that normally spend weeks or months wiring hardware together could reduce that work to hours or minutes. The early examples make that claim plausible in specific settings, but the evidence remains a collection of partner proofs of concept rather than an independent benchmark.
The release status matters. MHS is not publicly downloadable. Anthropic has not linked a specification, SDK, schema, source repository, license, conformance suite, version number, or governance model. The official MHS site says the project will become open source after the preview, but gives no date.
TL;DR
- What launched: a limited research preview for selected scientific labs, manufacturers, robotics teams, and hardware vendors.
- What MHS does: standardizes how a device describes its capabilities, state, commands, physical characteristics, and enforced operating limits to an AI system.
- How agents reach it: through MCP, a command-line interface, or code files and APIs.
- What looks strongest: shorter integration work, multi-device orchestration, fault detection, and the conversion of agent discoveries into deterministic programs.
- What remains unproven: general interoperability, non-Claude performance, independent reliability, production security, certification, governance, and long-term support.
- Kingy verdict: apply if you operate programmable research or industrial equipment and can test safely; watch if you build agents; wait if you need a stable public standard or production assurances.
What Anthropic actually released
MHS began as a collaboration between Anthropic’s Alek Kemeny and HHMI Janelia researcher Arco Bast. Bast was running brain-imaging experiments on a rig assembled from lasers, cameras, motorized focusers, and other devices that had no common interface. The initial work created shared machine-readable state so the instruments could coordinate. Kemeny and Bast then added AI models to that layer.
Anthropic describes the resulting MHS driver as a translator between a device and the computer controlling it. The driver exposes simple operations such as reading a temperature or writing a new set point. It also makes the device discoverable and supplies information that may not be visible in an API: what the machine can measure, what can be adjusted, physical characteristics such as the weight of a robot arm, and the limits the driver will enforce.
Some of that knowledge can be written in natural language. Anthropic says a user can enter it directly or have an agent interview them about the hardware setup. The driver then produces a reference file the agent can use when planning and operating a workflow.
That design separates three jobs that are often muddled together in physical-AI demos: describing the machine, giving an agent access, and executing the machine’s fast control logic.
| Layer | Role | Example | Public evidence status |
|---|---|---|---|
| Physical equipment | Performs measurement or motion through its native interface | Microscope, liquid handler, robotic arm, camera, plate reader, laser controller | Multiple partner demonstrations; hardware support remains case-specific |
| MHS driver and reference data | Exposes states, procedures, characteristics, commands, and declared limits in a common form | Read temperature, set speed, report arm position, enforce a travel boundary | Described publicly; no public MHS schema or conformance suite yet |
| Access mechanism | Lets software or an agent call the driver | MCP, command line, or code/API file | All three mechanisms named by Anthropic |
| Agent orchestration | Plans steps, monitors results, changes parameters, and coordinates devices | Claude adjusts a laser, watches a camera, and tests the result | All detailed launch examples use Claude or Claude Code |
| Deterministic execution | Runs learned sequences at machine speed without model reasoning at every step | A standalone laser-relock controller generated and validated during the pilot | Strongest in QuEra’s testbed; not evidence for every device class |
| Human and hardware controls | Constrain risky actions and preserve expert authority | Interlocks, emergency stops, driver bounds, approvals, camera and state checks | Demonstrated in individual pilots; no public cross-platform safety certification |
MHS versus MCP
Calling MHS “MCP for hardware” is a useful first approximation and a misleading final explanation.
Model Context Protocol gives AI applications a standard way to connect to tools and data sources. It has a public specification, SDKs, repositories, and an open governance path; Anthropic later donated MCP to the Agentic AI Foundation under the Linux Foundation.
MHS addresses a lower and more physical layer. It describes a device, its available actions, its state, contextual characteristics, and its operating constraints. MCP is one way an agent can reach that interface, but MHS can also be accessed through a CLI or code. Put simply: MCP can carry the tool call; MHS is intended to make the machine behind that tool call understandable and consistently operable.
That distinction also explains why the open-source status cannot be blurred. Developers can inspect and implement MCP today. MHS remains available only to accepted preview participants. For a beginner-friendly explanation of tool connectivity, Kingy’s MCP and context-engineering course covers the software side of this stack.
What the six partner pilots showed
The launch article is unusually detailed for a research-preview announcement. It contains reports from biotech, academic biology, microscopy, quantum computing, and lab-automation teams. The results are useful because the failure modes are reported alongside the successes.
| Organization | Equipment or workflow | Reported result | Important limitation |
|---|---|---|---|
| Genentech | BCA protein assay across a liquid handler, robotic arm, and plate reader | Claude optimized transfer speeds to about 140 µL/s for water and 10 µL/s for viscous BSA; it recovered from some instrument errors | Humans had to explain that foam was a physical failure; retrying the same well made the problem worse |
| University of Washington | Six instruments for remote monitoring, qPCR supervision, and collision-free plate handoffs | The researcher reports connecting six instruments, including driver writing, in under a week | The demonstrations remain proofs of concept; complex protocols require optimization and continuous monitoring has compute cost |
| Carnegie Mellon | Liquid handler, plate reader, robotic arm, and cameras across three incompatible computers | Drivers and orchestration reportedly took eight hours; six injected unsafe states were blocked before motion; an agent reran a poor dilution curve | The test used colorimetric dye, not a drug candidate; vendor comparisons are partner estimates |
| HHMI Janelia | A microscopy rig previously spread across seven vendor programs | MHS unified control and live analysis; the report says adding a new camera took minutes | The work is supervised, domain-specific, and still being developed |
| QuEra Computing | Laser relocking and tuning on a dedicated quantum-computing testbed | Blind validation recovered 695 of 700 induced faults, or 99.3%; simpler faults took 0.9–5.4 seconds and harder faults about 10–14 seconds | The runtime relock controller is deterministic; deployment on live quantum processors is still described as a next step |
| Tetsuwan Scientific | qPCR automation, error recovery, and compiler optimization | The team reports 9,143 dispenses, 300 transfer types, and 1,508 measured conditions; held-out precision predictions were about 12% more accurate than a manufacturer specification | Results are partner-reported and preliminary; the pollution study was not an independent MHS benchmark |
Genentech exposed the model’s physical-reasoning limit
Genentech’s pilot is valuable because it shows both autonomy and brittleness. Claude could execute a protein-assay workflow, optimize liquid-transfer rates, and recover from some tip-pickup and fluid-detection errors. When bubbles appeared in a viscous protein sample, however, its first response was to retry the operation in the same well with different parameters. That agitated the fluid and created more bubbles.
Researchers had to explain the underlying physical cause, move the procedure to a clean well, and reduce mixing. Once supplied with that context, Claude kept it for the rest of the run and the lesson was converted into reusable handling guidance.
This is the central safety lesson in miniature. A model can reason fluently over error codes while misunderstanding the physical mechanism behind them. Driver limits can prevent forbidden movement; they cannot supply missing scientific judgment.
Carnegie Mellon showed the integration opportunity
The Carnegie Mellon setup spanned a robot controlled through job files, a liquid handler using an older Windows scripting interface, cameras over USB, and a plate reader with only an on-screen interface. MHS turned those mismatched controls into a common set of states and procedures.
The team reports that a Claude Opus 4.8 agent completed the driver and orchestration work in about eight hours, compared with several weeks for a vendor-built setup. The system also blocked six induced conditions—including a missing or rotated plate, disconnected camera, unreachable device, and active emergency stop—before equipment moved.
That is promising integration evidence, not a general speed guarantee. The experiment used a safe dye as a substitute for a drug candidate, and the comparison with conventional delivery came from the participating team.
QuEra showed why deterministic control matters
QuEra’s account is the strongest illustration of the model stepping out of the runtime loop. Claude used MHS to experiment on a dedicated laser testbed, develop control logic, and validate it. The deployed relock controller is then a standalone, inspectable program. QuEra says the program supervises above the microsecond servo loop rather than trying to place an LLM inside it.
In blind validation, QuEra reports 695 successful recoveries across 700 induced faults. The five misses shared a rig-condition cause, and the controller declined to claim success. The company also reports that 43 naturally occurring mode hops during the pilot were detected and recovered. Those are meaningful testbed results. They do not yet prove fleet reliability or live-QPU deployment.
The architecture is more important than the headline number: let the agent explore, generate, and improve control logic; constrain that work with device limits; then run the repeatable portion as deterministic code. Kingy’s guide to agent loops rather than one-off prompts describes the same general move on the software side.
What MHS defines—and what it does not yet publish
| Publicly described now | Not specified in the public launch material |
|---|---|
| Driver primitives, device states, procedures, characteristics, and declared safety limits | A downloadable, versioned specification or schema |
| Device discovery and multi-device orchestration | License, ownership, governance, change control, and standard-setting process |
| Access through MCP, CLI, and code/API files | Conformance tests, driver certification, and compatibility tiers |
| Natural-language hardware context and generated reference files | Authentication, authorization, credential handling, network isolation, and audit-log requirements |
| Driver-enforced limits, interlocks, approvals, and deterministic scripts in selected pilots | A common threat model, prompt-injection guidance, liability framework, or regulatory certification path |
| A model-agnostic design claim | Public demonstrations or benchmarks using non-Claude agents |
| An intention to release preview findings and open-source MHS later | A release date, public pricing, preview admission criteria, or long-term support policy |
“Not specified” does not mean Anthropic has done no work in these areas. It means the company has not given outside developers enough public material to inspect, implement, or evaluate them.
The linked Gently microscopy repository is public and documents a layered safety stack, but it is a separate HHMI/Janelia agentic-microscopy project—not the MHS source repository. Its GPL-3.0-or-later license cannot be treated as the future license for MHS.
Why MHS could matter for physical AI
The physical-AI bottleneck is not only model intelligence. It is integration. A scientific instrument may expose an API, a Windows automation interface, a directory watched for job files, a vendor GUI, or no programmable interface at all. Even when two devices can be automated individually, they may disagree about state, timing, units, failure reporting, and safety.
MHS attacks three parts of that problem.
First, it tries to make device capabilities and state legible in a common form. Second, it moves tacit operator knowledge—physical characteristics, safe ranges, and operating context—into reference material an agent can use. Third, it lets an agent coordinate the changing parts of an experiment while moving mature sequences into deterministic code.
If that pattern holds, the valuable agent may look less like a robot driver and more like an automation engineer that can commission a setup, test it, monitor it, and leave behind inspectable programs. That is a more credible near-term role than giving an unconstrained chatbot direct control of a factory floor.
Anthropic also lists support work from AWS Strands Robots, Automata, Danaher, Doosan Robotics, MBF Bioscience, QIAGEN, Tecan, and Universal Robots. Hugging Face is adding MHS support to LeRobot, while Raspberry Pi is enabling integrations following camera-driver tests. These are partner intentions inside a preview, not proof of broad adoption. Still, a standard becomes more plausible when device makers and automation platforms help shape it.
Safety and security: where the hard problems begin
The launch examples include sensible controls: device-declared limits, mechanical interlocks, emergency stops, camera and state checks, human approvals, restricted procedures, and deterministic execution. QuEra’s controller could decline to report success. Carnegie Mellon’s system blocked induced unsafe states before motion. Genentech kept experts in the loop when the model misunderstood foam.
Those controls are stronger than relying on a model’s judgment alone. They are not a complete security architecture.
A physical-agent standard needs clear answers about who may discover a device, who may issue a command, how credentials are scoped, how remote access is isolated, what gets logged, how a compromised driver is revoked, and what happens when an agent consumes malicious instructions from a connected data source. The public material does not yet provide that common threat model.
Safety is also local. A speed limit suitable for one robot arm can be dangerous after a tooling change. A temperature boundary can protect equipment while still destroying a biological sample. A valid command can be unsafe in the wrong sequence. MHS can standardize how constraints are expressed, but domain experts still have to define and validate the constraints.
Anthropic says the preview will be used to build more evaluations, develop a physical-safety roadmap, and publish deployment guidance when MHS is open-sourced. That work is not supporting detail. It is part of the product.
Who should apply now
Apply: scientific labs, robotics teams, advanced manufacturers, automation platforms, and device vendors that already operate programmable equipment, can isolate a safe test environment, and have experts available to define limits and judge failures. The preview is most useful for organizations willing to contribute drivers, evaluations, and operational lessons rather than simply consume a finished SDK.
Watch: agent developers and software teams interested in physical systems but without suitable equipment or domain staff. The public release may eventually provide a useful target, but today there is no specification to build against.
Wait: organizations that need certified safety, a stable public interface, vendor-backed compatibility, predictable support and costs, or regulatory assurances. The strongest demonstrations are still pilots and testbeds.
Kingy verdict
MHS deserves attention because it targets an unglamorous constraint that controls how quickly physical AI can become useful: every machine speaks a different language, and much of the real operating knowledge lives in manuals or people’s heads.
Anthropic’s partner results show that a shared driver and orchestration layer can reduce integration work, coordinate multi-device experiments, catch faults, and help agents produce deterministic control programs. The examples are concrete enough to move MHS beyond a concept slide.
They are not enough to crown a standard. That label has to be earned through a public specification, implementable code, licensing, governance, conformance tests, security guidance, independent evaluations, non-Claude demonstrations, and reliable production use across sites and hardware classes.
Until then, MHS is best understood as a serious research preview with an unusually strong set of partner proofs—not yet the USB port for the physical-AI era.
What would strengthen the case?
- a public, versioned specification and reference implementation;
- clear licensing, ownership, governance, and contribution rules;
- conformance tests and reusable simulated hardware for safe driver validation;
- a published security and physical-safety threat model;
- independent replication of the launch results;
- successful use with non-Claude models and agent harnesses;
- production deployments with incident, uptime, and human-intervention data; and
- measured compatibility across multiple vendors, sites, and hardware categories.
Reader FAQ
What is Anthropic’s Model Hardware Standard?
MHS is a proposed shared specification and driver layer for letting AI agents discover, understand, and operate programmable physical devices. It is initially aimed at scientific research and advanced manufacturing.
Is MHS available to the public?
No. Access is currently limited to an application-based research preview. Interested organizations can apply through the official MHS site.
Is MHS open source?
Not yet. Anthropic says it plans to open-source MHS after the preview, but it has not announced a date, repository, or license.
Does MHS require Claude?
Anthropic says MHS is model-agnostic. Every detailed demonstration in the launch article uses Claude or Claude Code, so non-Claude interoperability remains a design claim rather than public comparative evidence.
How is MHS different from MCP?
MCP connects AI applications to tools and data. MHS is intended to describe and operate the physical device behind a tool, including its state, procedures, characteristics, and safety limits. MCP is one way an agent can access an MHS driver.
What equipment can MHS control?
Anthropic says MHS can work with devices that have a programmable interface. The preview includes microscopes, liquid handlers, robotic arms, cameras, plate readers, and laser-control equipment. Compatibility still depends on a suitable driver and interface.
Is MHS safe enough for autonomous labs or factories?
The pilots use meaningful safeguards, but the public evidence does not support a general safety or production certification. Expert oversight, physical interlocks, carefully defined limits, isolated testing, and deterministic controls remain necessary.
When will MHS be released?
Anthropic has not announced a public-release or open-source date.
Sources and methodology
Source review cutoff: August 27, 2026, 5:03 p.m. PDT. Kingy.ai reviewed public materials only and did not receive preview access. Company and partner performance figures were not independently reproduced. Claims were classified using Kingy’s source policy, research methodology, and editorial standards.
Primary sources
- Anthropic: Previewing the Model Hardware Standard
- Official Model Hardware Standard preview site
- Anthropic: Introducing the Model Context Protocol
- Anthropic: MCP and the Agentic AI Foundation
- QuEra: Holding the Light
- HHMI Janelia Gently repository
For continuing coverage of physical systems and embodied agents, see Kingy.ai’s AI Hardware Radar.