In this piece
Model Hardware Standard: Should Your Enterprise Pilot MHS for Physical AI?
Model Hardware Standard matters if your expensive AI project is still blocked by cheap-looking integration work. Labs and factories often own programmable devices already, but every new robot, reader, microscope or controller arrives with another API, SDK, GUI or vendor-specific workflow. Anthropic's MHS research preview targets that layer.
Our recommendation is narrower than the launch hype: pilot MHS when custom hardware integration is already a measurable bottleneck and you can isolate one non-critical workflow. Wait if your devices have no programmable interface, the workflow is safety-critical, or you need a generally available specification today.
This guide owns the enterprise adoption question. If you only need the software-side protocol definition, use our Model Context Protocol glossary. If you are evaluating a specific robotics model rather than the hardware interface, read our Gemini Robotics 2 evaluation.
What is the Model Hardware Standard?
MHS is a shared specification for AI agents to discover, understand and operate programmable physical devices. Anthropic opened the Model Hardware Standard research preview on 27 August 2026 after work that began with HHMI Janelia Research Campus. The preview covers scientific and advanced-manufacturing equipment such as liquid handlers, microscopes and robotic arms.
The useful abstraction is not “let the LLM drive the machine.” An MHS driver gives the agent standardized read and write primitives, discovery information, device characteristics and natural-language context such as operating limits. The agent can then reach the device through MCP, a command line or code APIs. Long-running or latency-sensitive sequences can be packaged into deterministic code rather than requiring online model reasoning for every step.
As of 7 September 2026, the official MHS site still describes an application-only limited research preview. Anthropic says it plans to open-source the standard after more safety evaluation and best-practice work. That makes today's buying decision a readiness and pilot decision, not a standards-migration mandate.
MHS vs MCP: which layer does each own?
MCP and MHS are complementary, not competing protocols. MCP is one path an agent can use to call tools. MHS adds the physical-device description, discovery and operating context that a generic software tool contract does not provide.
| Layer | Primary job | Enterprise decision |
|---|---|---|
| MCP | Expose software tools and resources to an agent | Use it when you want a portable software tool interface |
| MHS | Describe and operate programmable physical equipment with agent-readable constraints | Evaluate it when repeated device integration is the bottleneck |
| ROS 2, OPC UA or vendor SDK | Existing robotics, industrial or device communication and execution | Keep the proven control substrate; do not replace it just to add an agent |
| Safety controller and interlocks | Enforce physical limits independently of model judgment | Keep this below the probabilistic AI layer |
The practical architecture is therefore layered: model reasoning selects a bounded goal, the agent calls an MHS-described capability, existing controllers execute it, and independent safety logic can still stop the system. An MHS pilot should prove this separation rather than flatten it.
What do the early MHS pilots actually prove?
The published evidence is more useful when read as a set of failure modes and integration signals, not as one headline metric.
| Pilot | Published result | What a buyer should infer |
|---|---|---|
| Carnegie Mellon | Serial-dilution experiments ran about three times faster; the team reports eight hours from equipment readiness to a completed dilution curve, including one autonomous rerun | Integration compression can be large in a bounded, programmable lab workflow, but this is not a universal quote |
| QuEra | The developed laser relock controller recovered lock 99.3% of the time, compared with about 58% for the earlier bespoke script | Agent-assisted exploration can improve a narrow controller, while the write-up still reports expert-context and physical-troubleshooting limits |
| Genentech | Claude initially retried a bubble-related liquid-handling failure like a software error | Physical failure semantics must be in the evaluation set, not hidden behind API success codes |
Universal Robots adds an industrial perspective. Its MHS proof of concept on UR cobots used Claude Opus 4.8 to coordinate four separate robot applications as one cell. UR explicitly says the work is not generally available and that its own safety architecture remained in control underneath the MHS layer.
That distinction matters commercially. “The agent coordinated four robots” is interesting. “The agent did so while the deterministic safety substrate stayed authoritative” is the architecture worth copying.
Where MHS does not fit yet
- Non-programmable equipment: Anthropic says MHS does not yet work with hardware that lacks a programming interface.
- Safety-critical autonomy: a language model should not become the only collision, force, temperature, pressure or emergency-stop control.
- Procurement that requires a stable public spec: the current preview is gated and provisional.
- A one-device workflow with a stable API: a direct integration may remain cheaper than adding a new abstraction layer.
- A team without domain expertise: the Genentech and QuEra examples both show why physical context still has to come from people who understand the equipment.
These are reasons to narrow a pilot, not reasons to dismiss physical AI. The highest-leverage use case is likely where skilled engineers repeatedly spend time translating between devices that already expose programmable interfaces.
Does MHS make consumer robotics imminent?
It makes the integration thesis more plausible, but it does not make a household standard available today. The current preview is aimed at scientific research and advanced manufacturing, where the equipment, workspace and operating procedures are comparatively structured. A home has children, pets, clutter, privacy-sensitive sensors, unpredictable object placement and much weaker assumptions about who can authorize an action.
The likely bridge is constrained consumer-adjacent automation: assistive devices, maintenance equipment, premium appliances or service robots with narrow capabilities and strong local safety. The key adoption signal is not a viral home demo. It is whether hardware vendors expose safe, discoverable interfaces that can survive model changes and ambiguous natural-language goals.
How to calculate whether an MHS pilot is commercially interesting
Do not start with token cost. Start with the integration bottleneck you already pay for.
Annual integration burden = integrations per year × engineer-days per integration × fully loaded engineer cost per day.
Then estimate pilot value as avoided integration effort plus reduced recovery or handoff time, minus driver work, evaluation, observability and governance. Keep vendor claims outside the spreadsheet until you reproduce them on your equipment.
| Metric | Why it matters | Measure before and during pilot |
|---|---|---|
| Time to first safe device action | Tests the integration-compression thesis | Hours from clean environment to an approved action |
| Task completion rate | Separates integration success from workflow success | Accepted runs over a fixed representative set |
| Unsafe-command rejection | Tests whether boundaries work under adversarial or ambiguous instructions | Rejected unsafe requests divided by unsafe test cases |
| Human intervention rate | Exposes hidden operating cost | Interventions per accepted run and reason |
| Recovery rate | Shows whether the agent adds resilience or just another failure mode | Recoverable injected faults resolved within the allowed policy |
A 30-day MHS readiness pilot
- Days 1 to 5, choose one workcell. Pick two or three programmable devices with known integration pain. Exclude anything where a mistaken action can injure a person or damage irreplaceable material.
- Days 6 to 10, map the control stack. Document native APIs, current orchestration, units, operating bounds, emergency controls, authentication and who is allowed to approve each action.
- Days 11 to 15, build the evaluation harness. Create normal tasks, malformed instructions, stale state, disconnected devices, sensor anomalies and physical-failure simulations. Define pass criteria before using an agent.
- Days 16 to 22, test the agent-facing abstraction. If you have preview access, implement against MHS. If not, build an internal readiness adapter that preserves the same separation of device description, bounded actions and deterministic safety without claiming MHS conformance.
- Days 23 to 27, run supervised trials. Log goals, discovered capabilities, proposed calls, approvals, device state, stop events and recovery.
- Days 28 to 30, decide. Compare integration time and accepted-task cost with the existing baseline. Expand, redesign or wait for the public specification.
For the broader rollout discipline, use our 30/60/90-day AI agent pilot plan. If the commercial choice is whether to build a custom integration layer or buy a platform, use the custom software versus off-the-shelf guide.
What should you ask an MHS integration partner?
- Which parts of the stack are deterministic and which parts can the model decide?
- Can we run the same device adapter with a different model or harness?
- How are units, limits, calibration state and permissions represented and tested?
- What happens when the device API succeeds but the physical action fails?
- Can every action be replayed from logs without exposing secrets or unsafe credentials?
- How will we migrate when the public MHS specification differs from the preview?
- What exact metric tells us to stop the pilot rather than rationalize a weak result?
Wavect's AI enablement and agent engineering service can scope the software integration, evaluation harness and governance around a physical-AI pilot while your automation specialists retain hardware authority. Our TwinSoft AI case study is adjacent evidence for production AI integration, not a claim that we deployed MHS or industrial robotics there. If you already have two incompatible programmable devices and one workflow that keeps consuming integration time, bring that workflow to an MHS readiness call.
Model Hardware Standard FAQ
Is Model Hardware Standard open source?
Not yet as of 7 September 2026. Anthropic describes MHS as a limited research preview with access by application and says open source is planned after further safety evaluation and best-practice work.
What is the difference between MHS and MCP?
MCP is a software protocol an agent can use to reach tools and resources. MHS describes and operates physical equipment with device context and limits. Anthropic lists MCP as one of several ways an agent can access MHS.
Does MHS replace ROS 2 or OPC UA?
Do not design a pilot around replacing proven control infrastructure. Treat MHS as an agent-facing hardware abstraction above or beside existing device and robotics interfaces, then verify the final public specification when it is released.
Can MHS control consumer devices today?
The research preview is focused on science and advanced manufacturing. Consumer use is a plausible direction, not a current general-availability claim.
Who should pilot MHS first?
Teams with multiple programmable devices, repeated bespoke integration work, strong domain expertise and a workflow that can be tested safely in isolation have the clearest reason to evaluate it.