Your agent can discover a device and send a valid command, but the physical result still fails—or the system cannot explain what happened.

Fastest fix: do not enable automatic control yet. Treat Anthropic MHS as a limited research preview, start with offline simulation, and release permissions only through evidence-backed gates.

Who should use this runbook

You need this guide if you run a research lab and must decide whether an instrument is technically ready for an MHS pilot.

It also fits automation and robotics engineers validating drivers, device state, write limits, and physical interlocks, plus Agent platform owners planning isolation, remote monitoring, audit logs, and recovery.

As of August 30, 2026, Anthropic has confirmed that MHS entered a limited research preview on August 27, 2026. The official announcement says the standard is intended to let AI Agents operate programmable physical devices through standardized drivers. It does not establish universal compatibility, general safety, or public availability of a complete SDK. Read Anthropic’s MHS research preview announcement before treating any example as a production feature.

The acceptance model

The right question is not “Can MHS connect to this instrument?” The better question is “Which action can you prove is safe, observable, reversible, and independently constrained?”

Use this release path:

  • Simulation: no physical actuator, no live process, no production credentials.
  • Read-only monitoring: status, sensors, units, and logs only.
  • Restricted writes: approved parameters, device-side validation, and operator approval.
  • Multi-device orchestration: explicit dependencies, handoffs, and stop conditions.
  • Unattended execution: bounded runtime, bounded retries, recovery, and human takeover.

A successful demonstration moves you to the next gate. It does not automatically grant the next permission.

Anthropic’s own announcement includes a case where a model interpreted a physical hardware problem as a software problem. That example matters because a plausible explanation from Claude can still be wrong about the physical world. A tool call may succeed while a valve remains blocked, a workpiece is absent, a sensor is stale, or a mechanism is in an unexpected position. Use the NIST AI Risk Management Framework as a governance reference, but implement the actual safety boundary in the device and control system.

Gate one: offline simulation versus physical access

Start by identifying what you actually received.

The current MHS status is a limited research preview. Your team may have an approved application, a public description, or a partner example. Those are not interchangeable. The announcement does not mean that MHS is formally open-sourced, that a complete public SDK is available, or that every supported driver can be downloaded.

For the first milestone, use one of these:

  • A vendor simulator.
  • A virtual device state machine.
  • A test interface that cannot energize a real actuator.
  • Recorded device responses replayed through a local harness.
  • A mock driver with deliberately malformed and delayed responses.

Do not connect the control process to a live instrument merely because discovery works. At this stage, validate four boundaries:

  • Driver discovery: Can the agent identify the intended device without selecting a similarly named endpoint?
  • Command format: Are arguments typed, units explicit, and required fields enforced?
  • State transitions: Does the virtual device reject impossible transitions?
  • Failure reporting: Does an error identify the device condition, or does it invite the agent to guess?

Preserve the driver inventory, state transition trace, command payloads, returned errors, and rejected cases. These records are your first evidence package. If the team cannot reproduce a failed simulation, do not proceed to hardware.

Keep the layers separate:

  • The MHS driver describes the device capability and its supported operations.
  • MCP carries tool and system interactions between an Agent and external services.
  • Claude Code can inspect files, run approved commands, and help operate a development workflow, but it is not the device safety controller. Its official getting-started documentation describes its operating model; it does not grant physical authority.
  • A deterministic control script handles fixed sequences, validation, timing, and recovery.
  • The device safety system enforces physical and electrical limits.

Do not collapse these layers into one “AI control” component.

Gate two: read-only monitoring versus interpreted control

Choose the lowest-risk programmable device you have. Expose only read operations.

The agent may read:

  • Device identity.
  • Operating state.
  • Sensor values.
  • Units and ranges.
  • Run history.
  • Fault and event logs.

It must not start, stop, move, heat, pressurize, dispense, or change a setpoint during this gate.

Compare every MHS-described capability with the vendor manual and the actual device interface. Check names, units, timestamps, enum values, null behavior, and fault codes. A field named ready may describe software readiness rather than physical readiness. A temperature value may be cached. A position value may be commanded position rather than measured position.

Record three evidence types:

  1. The raw response from the device.
  2. The normalized value shown to the Agent.
  3. The operator’s interpretation and the source used to verify it.

Stop permission escalation if the state drifts, readings arrive late, units are unclear, or a field has no defensible meaning. Do not instruct Claude to infer the missing meaning from context. The correct response to ambiguous telemetry is a blocked transition.

This is also the point to review identity and isolation. The read-only node should have its own account, a narrowly scoped credential, and access only to the test device. Keep personal workspaces, experimental data, and equipment credentials out of the same unrestricted environment. If you are evaluating a remote Mac control node, document the MacPng service and operating model separately from the MHS device layer. A remote development host is not an equipment interlock.

Gate three: restricted writes versus independent limits

Write access is where a software mistake can become a physical event.

Define an allowlist before the first write. Each allowed parameter needs:

  • A type.
  • A unit.
  • A minimum and maximum.
  • An approved operating window.
  • A reason for the change.
  • An operator or job identity.
  • A timeout.
  • A rollback or safe-stop behavior.

Enforce these rules in the device or an independent controller. Do not rely on a prompt, a system message, or Claude’s judgment to reject an unsafe value. Natural-language labels such as “safe,” “low,” or “normal” are useful metadata. They are not bypass-proof physical protection.

Run the negative tests before positive demonstrations:

  • A value just outside the permitted range.
  • A missing unit.
  • A repeated command.
  • A command issued while the device is busy.
  • A command against a stale state.
  • A command after communication loss.
  • A command for a missing or unidentified workpiece.
  • A command that conflicts with the current process phase.

For every case, define the expected result in advance. The system should reject the request, hold the device, or enter a known safe state. “The Agent usually notices the problem” is not an acceptance criterion.

High-risk actions retain three independent controls: human approval, a physical emergency stop, and a separate operator console. The console should show the actual device state, not only the Agent’s explanation. Test that an operator can stop the process when the Agent is still generating output or when the network connection is unavailable.

Gate four: multi-device handoffs

A single instrument can be understandable while a workflow spanning several devices is unsafe.

Typical dependencies include a liquid handler transferring material to a reader, a robot moving a workpiece between stations, or a machine waiting for a sensor confirmation before changing mode. The failure is often at the handoff. One device reports an intended state while the next device assumes a completed state.

Write the workflow as an explicit state machine. For each transition, specify:

  • The precondition.
  • The device that proves it.
  • The command allowed after proof.
  • The timeout.
  • The abort path.
  • The human takeover condition.

Then create deliberate faults:

  • Disconnect one device.
  • Remove the workpiece.
  • Return a stale sensor value.
  • Delay completion from the previous device.
  • Send two incompatible transitions.
  • Restart the orchestration process during a handoff.

The next device must not act merely because the previous command was sent. It should act only after an independently verifiable completion condition.

Document responsibility by layer. MCP may transport a tool request. The MHS driver may map that request to a device capability. The Agent may choose the next step. A deterministic script may enforce sequence rules. The device controller may apply hard limits. If your incident log cannot identify which layer made the decision, the workflow is not ready for physical testing.

Gate five: long jobs versus unattended operation

A short successful run proves very little about an unattended experiment.

Long-running Agent systems can lose context, repeat a failed action, drift from the original objective, or continue after a control channel becomes unreliable. Anthropic’s discussion of managed Agents highlights the engineering need to handle long tasks as managed processes rather than as one uninterrupted conversation. Review the managed Agent engineering guidance when designing the execution layer.

Move critical actions into recoverable deterministic scripts. Let the Agent select from approved procedures and provide parameters within bounds. Do not let free-form reasoning reconstruct a partially completed physical sequence after a restart unless the device state has been independently verified.

Set explicit controls:

  • A maximum job duration.
  • A maximum retry count.
  • A maximum number of repeated commands.
  • A heartbeat timeout.
  • A checkpoint after each irreversible step.
  • A human takeover trigger.
  • A safe state for process termination.

The control environment should be separate from a personal development workspace. Keep credentials scoped to the test job. Keep experiment data in the intended storage boundary. Keep device access unavailable to unrelated coding sessions.

For teams using Claude Code to prepare scripts or inspect logs, review file permissions, shell access, secrets, and command approval separately. Claude Code can be part of the workflow, but it should not silently inherit production equipment privileges through a broad shell environment.

Independent recovery and audit

Before any physical pilot, test failure recovery as a first-class milestone.

The remote control node needs:

  • A dedicated account.
  • Minimum required permissions.
  • Network allowlists.
  • Command-level audit records.
  • Timestamped device responses.
  • Session or terminal replay where appropriate.
  • A visible operator takeover path.
  • A documented credential revocation process.

Run at least these recovery exercises:

  • The control node loses network connectivity.
  • The Agent process crashes.
  • The operator console disconnects.
  • An invalid parameter reaches the device boundary.
  • A command is accepted but the physical action does not complete.
  • The device reports a fault after a command has been issued.

For each exercise, verify whether the device enters a safe state, whether the event is logged, and whether an operator can recover without asking the Agent to diagnose its own failure. NIST’s material on human-AI interaction and risk management supports this separation between automation and accountable human oversight.

MCP should be reviewed as a communication and tool-access layer. Its official documentation explains how MCP connects models with tools and external systems; it does not turn a network request into a physical safety mechanism. Use the MCP documentation to verify the integration boundary, then test authorization and device behavior independently.

Mid-pilot FAQ

Application status

Anthropic MHS access is currently a limited research preview confirmed on August 27, 2026. Apply through the official MHS page and preserve the approval context in your project record. Do not represent an application, announcement, or partner demonstration as proof that the full standard, SDK, or driver collection is publicly available. Check the official MHS application page before planning procurement or deployment.

Supported equipment

Model Hardware Standard is aimed at devices with programmable interfaces and standardized driver support. That can include laboratory, robotic, or manufacturing equipment only when the required interface and safety behavior are documented. It is not a universal adapter for legacy instruments with no programmable control surface. Confirm capabilities against the vendor interface and test in simulation first.

MHS and MCP

MHS and MCP solve different problems. MHS concerns the representation and operation of eligible physical hardware through drivers. MCP provides a protocol pattern for exposing tools and external context to an Agent. MCP can transport an instruction to an MHS-enabled workflow, but it does not define the device’s hard limits or replace an emergency stop.

Robot safety testing

Before an AI Agent controls a robot, test stale state, missing workpieces, invalid coordinates, duplicate commands, device busy conditions, communication loss, unsafe sequencing, and operator takeover. Verify that an independent controller blocks unsafe motion. Use simulation and read-only telemetry before any restricted write. A successful natural-language explanation is not evidence that the robot is physically safe.

The release decision

At the end of the pilot, choose one of three outcomes.

Keep read-only access when discovery and telemetry are reliable, but state meaning, failure behavior, or recovery remains unclear.

Allow limited writes only when the device or independent controller enforces parameter bounds, negative tests block unsafe commands, human approval remains available, and recovery has been demonstrated.

Pause the physical MHS pilot when the device lacks a programmable interface, logs cannot reconstruct decisions, the control node shares unrestricted credentials, or a failed command can leave the equipment moving, heating, dispensing, pressurizing, or otherwise active without an independent stop path.

This is the point where the current environment matters. A shared developer laptop makes credentials, experiment data, terminal access, and control sessions difficult to separate. A general cloud host may add network uncertainty, weak device locality, or unclear session recovery. A self-managed workstation can work for a stable long-term installation, but it leaves you responsible for hardware availability, patching, access control, and recovery testing.

For teams that only need a temporary Claude Code workspace, driver simulation, remote monitoring console, or isolated orchestration node, a rented Mac environment from MacPng can be easier to separate from the physical equipment layer. It does not replace device interlocks, and it is not the right choice for permanent heavy workloads or workflows that require direct physical ports. Use it as an isolated control-side environment, then connect to real equipment only after the acceptance evidence supports that decision.

Pilot acceptance checklist

  • [ ] Confirm that your MHS status is an approved research preview, public explanation, or partner example.
  • [ ] Confirm the device has a documented programmable interface.
  • [ ] Build a simulator, virtual device, or non-actuating test interface.
  • [ ] Save driver discovery results, state transitions, command payloads, and failure logs.
  • [ ] Prove that device names, units, states, and safety labels match the vendor interface.
  • [ ] Disable all writes during the read-only milestone.
  • [ ] Create an allowlist for every parameter before enabling restricted writes.
  • [ ] Enforce ranges and types in the device or an independent controller.
  • [ ] Test invalid values, duplicate commands, stale state, busy state, and communication loss.
  • [ ] Retain human approval, physical emergency stop, and an independent console for high-risk actions.
  • [ ] Model multi-device dependencies as explicit preconditions and completion states.
  • [ ] Simulate device loss, missing workpieces, delayed completion, and sequence conflicts.
  • [ ] Move irreversible steps into recoverable deterministic scripts.
  • [ ] Set runtime, retry, heartbeat, and takeover limits.
  • [ ] Separate the control node from personal workspaces and unrelated credentials.
  • [ ] Enable command audit, response logging, and operator session records.
  • [ ] Test node failure, Agent crash, console loss, rejected parameters, and incomplete actions.
  • [ ] Record whether the final status is read-only, limited write, or deferred physical access.

Last updated August 30, 2026. Preview status, application availability, device conditions, and open-source claims were checked against Anthropic’s MHS announcement, the official MHS page, and the linked MCP and Agent documentation. Recheck those sources before approval if Anthropic publishes a public SDK, full specification, safety guidance, or changes the research-preview terms.