Model Hardware Standard (MHS) Research Preview Guide

On this page

Quick answer

The Model Hardware Standard (MHS) is an Anthropic-led research preview for connecting AI agents to programmable physical equipment through standardized device drivers. The driver makes device state and controls discoverable, exposes simple read and write primitives, and can be operated through MCP, a command-line interface, or code APIs.

As of the August 29, 2026 source check, MHS is not a generally available open-source package. The preview is limited and application-based. Anthropic says it is working with research and manufacturing partners on safety evaluations and best practices before making the standard open source.

What is available now?

QuestionCurrent source-backed answerDecision consequence
LifecycleLimited research previewTreat interfaces, packaging, and access as changeable
AccessApplication through the MHS siteDo not plan a rollout around immediate self-service access
Device scopeDevices with a programmable interfaceInventory every real device and vendor interface first
Model scopeModel-agnosticEvaluate the agent harness separately from the hardware layer
Control mechanismsMCP, CLI, and code files or APIsChoose each path by latency, audit, and failure requirements
Open sourceForthcoming, not available yetRecheck license, repository, and release artifacts before adoption
Safety maturityPreview partners are building evaluations and practicesKeep independent safety controls and expert oversight

MHS began as a collaboration between Anthropic and HHMI Janelia Research Campus. Anthropic describes early work across laboratory automation, robotics, electronics, manufacturing, and quantum systems. Those examples show what selected partners tested; they do not prove that an untested device, workflow, model, or site will produce the same result.

How the MHS layer works

The preview describes four connected parts.

  1. A standardized driver exposes the device. It translates between software and the device, and uses simple primitives such as reading a temperature or writing a temperature set point.
  2. Device information becomes discoverable. Tags can describe physical characteristics that code alone may not reveal, such as the weight of a robot arm.
  3. A reference file defines the operating surface. Anthropic says it can describe what the device measures, what can be adjusted, and which safety limits the driver enforces.
  4. The harness selects a control path. MCP, CLI, and code APIs can expose the driver to an agent or to deterministic orchestration.

This is not permission to let a model freely operate hardware. A trustworthy implementation must bind every discovered device to a verified physical identity, authorize commands by workflow and role, validate units and ranges, enforce rate and sequence limits outside the model, and preserve a human-controlled stop path.

Agent reasoning versus deterministic execution

Anthropic describes agents sequencing instruments, monitoring results, adjusting parameters, and packaging learned steps into code files for longer or faster operations. That suggests a useful division of responsibility:

  • use agent reasoning for bounded planning, interpretation, and approved decision points;
  • use deterministic scripts or controllers for timing-sensitive and repeatable sequences;
  • keep hard limits, interlocks, emergency stops, and physical protections independent of agent output;
  • return observed device state to the supervisor before the next material action.

Do not treat a generated script as safe because it is deterministic. Version it, review it, simulate it where possible, test it on a bounded fixture, verify units and device identity, and require approval before it can affect real equipment.

A defensible preview pilot

Begin with one low-energy, reversible workflow rather than a facility-wide integration.

  1. Record the exact device model, firmware, vendor interface, calibration state, and physical envelope.
  2. Define allowed reads, allowed writes, units, bounds, rate limits, command order, timeout, and stop conditions.
  3. Map the MHS driver declaration to the vendor manual and independently observed behavior.
  4. Test stale state, disconnected devices, sensor disagreement, invalid units, duplicate commands, partial completion, and recovery.
  5. Log the requesting identity, approved objective, command, arguments, driver version, device response, operator action, and final state.
  6. Require an accountable expert to approve the workflow and supervise real-hardware trials.

Use the MHS driver and safety evaluation guide for the test matrix. Use the MHS versus MCP architecture guide when deciding where discovery, authorization, orchestration, and device limits belong. The MHS readiness check turns those decisions into eight browser-local evidence gates.

Frequently asked questions

Is the Model Hardware Standard open source?

Not yet. Anthropic and the MHS site describe a limited research preview and say open source is forthcoming. Access is currently by application.

Does MHS require Claude?

No. Anthropic describes MHS as model-agnostic and says any agent harness can access it through mechanisms including MCP, a command-line interface, and code APIs.

What does an MHS driver contain?

The preview describes standardized read and write primitives, discoverable device information, natural-language tags for physical characteristics, and a generated reference file that states capabilities, adjustable values, and enforced safety limits.

Is the MHS preview production-ready?

The announcement does not establish general production readiness. It asks preview partners to help build safety evaluations and best practices, so every deployment still needs device-specific limits, authorization, supervision, recovery, and real-hardware validation.

Official sources

Source check: August 29, 2026. Recheck preview eligibility, supported hardware, driver specification, license, repository, interfaces, safety guidance, and availability before relying on this page.