Model Hardware Standard: when AI agents enter the physical world

What was announced—and what is actually available

Anthropic says the Model Hardware Standard began as a collaboration with HHMI Janelia Research Campus and is now being shared with an initial group across science, robotics, electronics and advanced manufacturing. Access is application-based. The project website describes the programme as a limited research preview, and Anthropic says it plans to make MHS open source only after participants have helped develop safety evaluations and deployment practices.

That availability boundary matters. MHS is not a public compatibility badge, a finished international standard or a package that any factory can responsibly install today. No date has been announced for the open-source release, and no public conformance test or independent certification programme has been described. The current evidence comes from the project team and participating organisations reporting their own early implementations.

The global significance lies in the direction rather than immediate reach. Software agents are beginning to coordinate equipment that can move, heat, illuminate, mix and measure physical material. A shared control layer could make that work less dependent on one-off integrations, but it also concentrates new safety questions at the point where an agent's output becomes a machine command.

MHS is a common language for machines—not a new model

Most scientific and industrial devices arrive with different interfaces, data formats and assumptions. One instrument may expose a modern API, another may depend on an older desktop application, and a third may require a specialist to translate its operating state. Connecting several machines can therefore demand custom code for every pairing before an AI system can do anything useful across them.

MHS proposes a standard driver that describes a device through shared states and procedures. Simple operations such as reading a temperature or writing a setting sit alongside information the software cannot safely infer from code alone: the physical characteristics of a robotic arm, the range a laser may use, the current position of a sample or a limit that must never be crossed. An agent can then discover devices and reason over a consistent description rather than learning every vendor interface from scratch.

Anthropic describes MHS as model-agnostic. The announced control paths include the command line, code files and the Model Context Protocol. That does not make MHS a replacement for MCP: MCP can connect an agent to tools, while MHS is intended to describe and control the physical-device layer behind those tools. The distinction is important because reliable messaging and safe machine behaviour are different engineering problems.

• Discovery: identify which machines are present and what state each is in.
• Description: expose capabilities, procedures and relevant physical characteristics.
• Constraint: enforce device-level operating limits before a command reaches motion or material.
• Orchestration: coordinate several instruments without requiring one custom interface for every combination.

The early demonstrations are promising, but they are not a universal benchmark

At Carnegie Mellon University, researchers report that an MHS-based system connected a liquid handler, plate reader, robotic arm and cameras spread across three computers. In a safe test using coloured dye rather than a drug candidate, the system blocked six deliberately introduced fault conditions before equipment moved, then rejected a weak dilution curve and ran a corrected experiment. The team says the end-to-end setup took eight hours, compared with multiple weeks for a typical vendor-built integration in its environment.

At Genentech, a proof of concept coordinated a liquid handler, robotic arm and plate reader for a protein-concentration assay. The model could optimise some transfer parameters and recover from several equipment errors, but it initially treated bubbles as if repeated software retries might solve them. Human experts had to explain the underlying physical failure before the system used gentler parameters and clean wells. That limitation is not peripheral: it shows the difference between reasoning about logs and understanding matter.

Other reported examples include microscopy rigs at HHMI Janelia and laser-stabilisation work at QuEra. These cases make the interoperability argument tangible, but the measurements remain partner-reported and highly specific to each rig, model, harness and safety configuration. They do not establish that MHS will produce the same integration speed, reliability or scientific quality on unfamiliar equipment or in regulated production.

Physical agency changes the meaning of an AI error

A wrong answer in a document may be corrected before it travels. A wrong command sent to a robot, laser, centrifuge or liquid handler can damage a sample, collide with equipment, create unsafe exposure or quietly corrupt an experiment. The relevant unit of safety is therefore no longer only the model response. It is the complete path from intent to permission, command, machine state, sensor evidence and recovery.

MHS is designed to carry device-level limits, and some pilots used camera checks, emergency-stop states and deterministic scripts for time-sensitive work. Those are useful architectural signals. They do not remove the need for independent interlocks, validated operating envelopes, access control, audit records and a human who can halt or override the system. A language model should not be the only component deciding whether its own action is safe.

NIST's AI Risk Management Framework makes the broader principle clear: risk management should span the full lifecycle, use in-domain testing and monitoring, and allow systems to be shut down or modified when behaviour leaves expected conditions. When agents act through physical equipment, those practices need to be mapped to the actual device, environment, material and severity of failure—not applied as a generic software checklist.

• Keep hard safety limits outside the model's discretion.
• Separate permission to plan from permission to execute a physical action.
• Confirm state through independent sensors before and after consequential movement.
• Define which faults stop automatically and which require human review.
• Record the exact model, driver, device configuration and approval path for every run.

The commercial opportunity is interoperability—but lock-in has not disappeared

A credible common interface could lower the cost of connecting equipment from different eras and manufacturers. That may broaden advanced automation beyond the largest laboratories, help factories adapt workflows without rebuilding every integration and make reusable monitoring or analysis components more valuable. Hardware vendors could also expose safer, better-documented capabilities instead of leaving customers to reverse-engineer control paths.

Yet a standard becomes useful only when implementations agree and remain compatible. MHS is currently stewarded through a private preview, its final open-source form is not public and announced vendors are at different stages—from exploring or testing to building planned support. Buyers should not confuse an intention to support a standard with verified interoperability on their own fleet.

There is also a new dependency chain. A model-agnostic interface may reduce reliance on one AI provider, but organisations still depend on device drivers, agent harnesses, identity systems, network controls, models and the quality of the machine descriptions supplied. Open governance, versioning, portable logs and conformance evidence will determine whether MHS becomes shared infrastructure or simply another integration layer with a new name.

What a serious adopter should ask during the preview

The right first question is not whether an agent can move a machine. It is whether the organisation can prove what the agent is allowed to do, how the machine confirms reality and how the system fails safely. A useful pilot begins with a bounded, reversible task whose physical outcome can be measured independently.

Procurement teams should also separate evidence about integration speed from evidence about scientific or manufacturing quality. Connecting three instruments in a day is valuable, but it does not demonstrate accuracy across every sample, long-run reliability, regulatory compliance or safe behaviour after a model or driver update. Each claim needs its own test and acceptance threshold.

• Which devices, firmware versions and interfaces are genuinely supported today?
• Which commands are blocked mechanically, which are blocked in software and which rely on the model's judgement?
• Can the organisation reproduce a run and audit every action, sensor reading and human approval?
• What happens when a device lies, a camera fails, a sample behaves unexpectedly or the network is interrupted?
• Does a model, driver or protocol update trigger validation again?
• Who owns the integration data, incident record and right to move to another model or vendor?

The Pumpkin AI conclusion: the interface is becoming the institution

MHS is easy to describe as a connector for machines, but its deeper importance is governance. The interface decides what an agent can see, what it can change, which limits are absolute, when a human must intervene and what evidence remains afterward. In physical AI, those decisions are the operating constitution of the system.

Pumpkin AI sees the research preview as a meaningful signal, not a finished safety answer. The next phase of AI adoption will be judged less by whether a model can propose an action and more by whether the surrounding system can make that action bounded, observable, reversible and accountable. If MHS develops through open scrutiny and rigorous real-world validation, it could become part of that foundation. Until then, its strongest lesson is already available: once AI can move the world, responsible design has to reach all the way to the machine.