MHS Gives AI Agents Hands. Your App Still Needs a Physical-Effect Contract

Anthropic and HHMI Janelia have opened a research preview of the Model Hardware Standard (MHS), a shared interface for AI agents to discover and operate programmable physical equipment. The announcement describes microscopes, liquid handlers, cameras, lasers, robotic arms, and other lab or manufacturing devices connected through standardized drivers. An agent can read device state, change parameters, coordinate several instruments, and package a learned sequence into deterministic code.

That is a meaningful product shift. An AI app no longer has to stop at recommending an action or changing a digital record. It can increasingly cause motion, heat, pressure, fluid transfer, exposure, or machine state in the physical world.

But MHS is a limited research preview available by application and intended to become open source later. It is not a published safety certification, a universal device schema, or evidence that a model understands the physics of every machine it can call. Anthropic's own Genentech case is useful precisely because it reports both progress and failure: Claude found reasonable liquid-flow parameters, yet initially responded to bubble-related errors by retrying in the same well and making the physical condition worse.

For a nontechnical founder or small AI product team, the immediate question is therefore not “Can we connect an agent to hardware?” It is “What must remain true before software is allowed to cause a physical effect?”

This guide turns the MHS preview into a launch artifact: a physical-effect contract that binds device identity, calibrated state, allowed actions, approval, independent safety controls, execution evidence, and recovery. It includes a worked lab scenario, a decision matrix, eight failure drills, and clear boundaries for when an AI agent should observe, recommend, simulate, or act.

What MHS Changes, and What It Does Not Prove

The Anthropic announcement describes MHS as a standardized driver layer for devices with programmable interfaces. Drivers expose simple primitives such as reading a temperature or setting one. They also make devices discoverable and produce a reference file describing characteristics, adjustable parameters, measurements, and enforced safety limits. An agent can access those devices through MCP, a command-line interface, or code.

This can remove real integration friction. A microscope, plate reader, robotic arm, and liquid handler may each have a different vendor API, data shape, and control program. A common interface can make them visible to one orchestration layer without a new bespoke translator for every pair. MHS also supports long-running sequences: the agent can compose driver calls into code so the device workflow does not depend on the model reasoning at every millisecond.

The preview is still bounded. The MHS site says access is by application and asks participants to help develop safety evaluations and best practices before the standard becomes open source. Public materials do not yet provide a stable open specification, conformance suite, certification process, threat model, version compatibility table, or independent reproduction package.

Separate four claims that are easy to collapse:

Interoperable means a controller can exchange commands and state with a device through a defined interface.
Controllable means the requested change can actually reach an actuator or device process.
Operationally correct means the action produces the intended result under the current physical conditions.
Safe means foreseeable failures remain within an accepted hazard envelope, including failures in the model, driver, sensor, network, device, environment, and human process.

MHS advances the first two. Its early cases offer promising evidence about the third in selected workflows. The fourth remains an application-level systems responsibility.

Define the Terms Before You Connect a Device

Physical products become dangerous when a team uses one word for several different controls. Define these terms in plain language:

Capability is an action the software interface can request, such as setting a temperature, moving an arm, opening a valve, or stopping a run.
Operating envelope is the allowed range of device, material, workspace, and human conditions for one approved task. It is narrower than the device's full technical range.
Interlock is a control outside the agent's judgment that prevents or stops an unsafe condition. A guarded door switch, force limit, travel limit, or independent temperature cutoff can be an interlock.
Approval is a named person's authorization for a specific action plan, device, material, parameter range, and time window. It is not a general chat message such as “run the experiment.”
Execution receipt is evidence of what command reached which device, under which state and limits, plus the observed result. It is not the agent's narrative summary.
Safe state is the physical condition the system should reach after a stop, timeout, communication loss, or detected fault. “Nothing is moving” may not be safe if heat, pressure, stored energy, or a hazardous sample remains uncontrolled.
Recovery authority is the limited permission to contain a failure. It must not silently become permission to improvise a new experiment.

These definitions matter because a model can correctly select an API call while acting on a stale sensor value, using the wrong fixture, moving through an occupied workspace, or retrying a process whose first failure changed the material.

Treat MHS as an Interface, Not the Safety Controller

The current MCP tools specification explains that tools are model-controlled, recommends a human ability to deny invocations, and requires clients to treat tool annotations as untrusted unless they come from a trusted server. It also calls for input validation, access control, rate limits, confirmation on sensitive operations, timeouts, and audit logging.

Those are valuable software controls. Physical equipment adds a harder boundary: the model, MCP host, MHS driver, and descriptive tags should not be the only components capable of preventing injury or equipment damage. A persuasive tool description is not a safety-rated circuit. A JSON schema can reject temperature: "hot"; it cannot prove that the measured temperature is fresh, the sensor is calibrated, a valve moved, or a human has left the work envelope.

Established robotics guidance is more explicit about independence and consequence. The OSHA Technical Manual's robotics chapter describes safety-rated monitored stops, speed and separation monitoring, and power and force limiting. OSHA's older but still instructive robotics safety guidelines say emergency stops should override other controls and recommend redundancy and backup systems when robots can create serious hazards.

The principle for an AI product is simple: let the agent operate inside the approved envelope; let an independent control enforce the envelope. The interlock should not need the model to notice, agree, remain online, or describe the situation correctly.

Build a Seven-Layer Physical-Effect Contract

A founder can review an AI-to-hardware feature without reading motion-control code. Require the team to complete seven layers for every production workflow.

Layer	Required evidence	Stop condition
1. Device identity	Device ID, driver version, firmware, owner, physical location	Unknown or substituted device
2. State validity	Calibration ID, sensor timestamp, fixture/material identity, occupancy	Stale, missing, contradictory, or out-of-range state
3. Action envelope	Allowed commands, units, ranges, rate, sequence, workspace	Command or cumulative effect exceeds the approved envelope
4. Plan validation	Simulation/dry run, collision or constraint checks, expected state transitions	Plan cannot be evaluated or differs from approved task
5. Authority	Named approver, exact parameters, expiration, two-person rule where needed	Approval is broad, stale, or detached from the executable plan
6. Independent protection	Guard, limit switch, PLC/safety controller, cutoff, emergency stop	Protection unavailable, bypassed, untested, or controlled only by the agent
7. Effect and recovery	Command log, device acknowledgement, independent observation, safe-state result	Outcome is ambiguous or recovery would expand authority

The layers are deliberately ordered. Identity precedes telemetry: a fresh reading from the wrong device is still wrong. State precedes planning: a valid route based on yesterday's fixture map is unsafe. Approval follows the executable plan: users cannot meaningfully authorize a vague intention and discover parameters after motion starts. The receipt comes from both command and observation because “device accepted request” does not prove the physical effect occurred.

Do not store this only in a policy document. Make it the object your application compiles before execution and records afterward.

Use This Reusable Contract Artifact

The following example is intentionally readable by a founder, operator, safety owner, and engineer. It is not an MHS schema and should not be presented as one. It is a product-side control record that can reference whatever versioned driver or protocol the team adopts.

yaml

physical_effect_contract:
  contract_id: pec-2026-08-28-0042
  product_workflow: protein-assay-transfer
  risk_owner: lab-operations-lead

  device:
    asset_id: liquid-handler-lh07
    location: lab-a-cell-3
    driver_version: mhs-preview-build-verified-in-test
    firmware: 5.12.4
    permitted_capabilities: [aspirate, dispense, read_status, stop]

  state_requirement:
    calibration_id: cal-lh07-2026-08-27
    max_sensor_age_seconds: 2
    material_lot: bsa-lot-184
    plate_id: plate-96-8841
    workspace_occupancy: clear

  envelope:
    volume_microliters: {min: 5, max: 100}
    flow_microliters_per_second: {min: 8, max: 15}
    max_retries_per_well: 0
    allowed_wells: [A1, A2, A3, A4]
    forbidden_conditions: [foam_detected, tip_pickup_uncertain]

  authority:
    approved_plan_hash: sha256:...
    approver: operator-217
    expires_at: 2026-08-28T11:30:00+09:00

  independent_protection:
    interlock_check_id: preflight-55018
    emergency_stop_tested_at: 2026-08-28T08:45:00+09:00
    safe_state: motion_stopped_and_pressure_released

  outcome:
    command_receipt_required: true
    observation_required: [plate_image, pressure_trace, volume_check]
    ambiguous_effect_action: stop_and_quarantine_plate

The most important fields are not the model name or prompt. They are the physical asset, current state, cumulative envelope, approved plan hash, independent protection, and ambiguous-effect response. Changing any of those should create a new contract or invalidate the existing one.

A Concrete Scenario: The Bubble That Turns Retry Into Damage

Consider a small biotech team building a natural-language lab assistant. A scientist asks it to transfer a viscous protein sample into a 96-well plate, then read absorbance. The product connects a language model to a liquid handler and plate reader through standardized device drivers.

In a clean demo, the agent selects the correct well, transfers the requested volume, and records a reading. The team is tempted to approve automatic retries because software APIs often recover from transient failures that way.

The physical system behaves differently. A rapid mix creates bubbles. The liquid-level sensor reports an error. Retrying in the same well agitates the sample further, so the state after failure is not the state before the first attempt. The original idempotency assumption is false.

This is not hypothetical framing imposed on the release. In Anthropic's Genentech account, Claude initially used generic flow parameters for water and viscous BSA, then optimized them to different values. The case says that when bubble-related runtime errors appeared, its default response was to retry in the same well with different parameters, which created more bubbles. Human guidance was needed to move to a clean well and mix more gently; that learning was later encoded in reusable skills.

The product lesson is broader than pipetting:

A failed digital call may leave no effect. A failed physical call can alter material, energy, geometry, contamination, or occupancy.
A device error code describes what one controller detected. It may not describe the physical root cause.
Recovery is a new action on changed state, not a continuation of the original intent.
A learned skill can improve defaults, but it does not replace a pressure limit, guarded workspace, material rule, or independent stop.

For this scenario, max_retries_per_well: 0 is a product decision. The agent may stop, preserve evidence, and propose a recovery plan. It may not autonomously treat the sample as unchanged.

Separate Observation, Recommendation, Simulation, and Actuation

Teams often jump from “the agent can read the instrument” to “the agent should control it.” Use four release modes instead.

Mode	Agent may do	Minimum evidence	Good first use
Observe	Read state and alert	Device identity, timestamp, data quality	Remote monitoring and anomaly triage
Recommend	Propose parameters or a sequence	Evidence links, bounds, named reviewer	Expert decision support
Simulate	Execute against a digital or inert environment	Model fidelity, scenario coverage, sim-to-real gap	Plan and collision testing
Actuate	Cause a physical effect	Full contract, independent protection, receipt, recovery	Narrow validated production task

The default path should advance one mode at a time. A monitoring agent that notices a qPCR curve approaching a threshold may first alert the researcher. Later it may recommend stopping. Only after false alarms, missed stops, sensor freshness, user response time, and safe fallback are understood should it gain a narrow stop capability.

Simulation is useful but not magic. A simulator may omit foam, cable drag, worn grippers, dirty lenses, mechanical backlash, calibration drift, or human improvisation. The AWS and Hugging Face Strands Robots example wisely defaults a robot constructor to simulation and requires an explicit mode="real" for hardware. Treat that switch as a promotion boundary with different credentials, approvals, network paths, and logs—not as one harmless parameter.

Run Eight Failure Drills Before a Real Pilot

Do not begin with adversarial prompts. Start with ordinary physical failures that a helpful agent is likely to mishandle.

Wrong-device drill: substitute an identical model with a different asset ID or firmware. The contract must reject it before state reads or motion.
Stale-state drill: freeze a sensor timestamp while keeping its value plausible. The agent must not infer freshness from a reasonable number.
Unit drill: present a valid parameter in a different unit or scale. Conversion must be explicit, bounded, and visible in the approval.
Changed-after-approval drill: move a fixture or change a material lot after the plan is approved. The approval hash must no longer authorize execution.
Communication-loss drill: disconnect the agent, driver, or network mid-sequence. The device must reach or maintain the defined safe state without model reasoning.
Ambiguous-effect drill: deliver a timeout after the device accepts a command. The system must observe before retrying and quarantine uncertainty.
Interlock drill: report an unavailable guard, stop, or limit while the software path looks healthy. Production actuation must remain disabled.
Recovery-expansion drill: make the suggested fix require a new well, tool, route, or parameter range. The system must request a new contract instead of stretching the old one.

Keep the drills harmless: inert material, reduced speed and force, empty workspaces, simulated faults, and trained operators. The goal is not to ask a general model to prove safety. It is to prove that the system constrains the model's authority when predictable uncertainty appears.

Design Stop, Safe State, and Restart as Three Different Actions

A red button is necessary in many settings, but “stop” is not one universal result. A moving arm may need power removed. A sample chamber may need temperature maintained. A pressurized line may need controlled venting. A laser may need its emission disabled while cooling continues.

The consolidated EU Machinery Regulation requires emergency-stop devices where they reduce risk, says stop controls take priority over start controls, and states that releasing an emergency stop must not itself restart machinery. For remote-controlled machinery, it also describes automatic stopping after loss of control, a stop signal, a safety-related fault, or absence of a validation signal within a specified time.

Translate that systems logic into three separate product states:

Stop requested: a control asks hazardous motion or processing to cease.
Safe state verified: independent observations confirm the physical system is in its task-specific contained condition.
Restart authorized: a human or separate policy approves new motion after the cause, device state, workspace, and contract are reviewed.

Never let the agent turn stop acknowledged into safe, or fault cleared into restart allowed. The execution UI should show each state separately and identify the system that produced the evidence.

Measure Accepted Physical Outcomes, Not Successful Tool Calls

An MHS call returning success is useful operational telemetry. It is not the product outcome.

For each workflow, define an independent acceptance measure. A liquid transfer might require mass, pressure, imaging, or downstream assay evidence. A robotic handoff might require both devices to report compatible states plus a camera or fixture sensor confirming the plate's location. A laser alignment might require measured output within tolerance, not merely a completed motor sequence.

Track at least:

accepted physical outcomes per attempted run;
ambiguous effects requiring quarantine;
safety-controller interventions;
human corrections before and after actuation;
material, energy, equipment, and operator time per accepted result;
recovery attempts that requested broader authority;
failures by device, driver, firmware, model, plan version, and environment condition.

NIST's Physical AI and Data Generation for Robotics program emphasizes that real performance depends on the combination of AI algorithm, robot system, and task. That is the right measurement unit. “The model succeeded” hides the exact hardware, fixture, calibration, controller, environment, and acceptance rule that made the result possible.

Avoid the Most Dangerous Product Misreads

Several interpretations would outrun the evidence available today.

“The standard enforces safety limits, so the workflow is safe.” A declared or enforced limit can be valuable, but safety depends on whether it is complete, correctly configured, independently implemented, validated for the application, and resilient to component failure. “Natural-language device tags contain the expert knowledge.” Tags can make tacit information visible. They can also be incomplete, stale, ambiguous, or authored by someone without authority. Version them, approve them, and test behavior at boundaries. “The agent recovered from errors, so fewer humans are needed.” Recovery from a known software or device error is not proof of correct recovery from changed physical state. The Genentech example shows both autonomy and a limit in physical intuition. “A deterministic script written by the model is safer than online reasoning.” A reviewed deterministic script can reduce runtime variability. It can also repeat a wrong sequence faster and longer. Bind it to a plan hash, operating envelope, current state, and independent interruption path. “Open source will make the standard certified.” Openness can improve inspection and integration. It does not automatically provide conformance, safety integrity, liability allocation, or validation for a particular device and task. “An operator confirmation makes the action safe.” Humans can approve the wrong target, miss changed conditions, or become habituated to prompts. Show the exact physical asset, parameters, workspace, material, expected effect, and irreversible boundary; keep hard protections outside the confirmation flow.

Know When This Framework Applies, and When It Does Not

Use the physical-effect contract when an AI feature can control or sequence a programmable device whose state affects people, valuable equipment, samples, inventory, facilities, or the environment. It is relevant to lab automation, industrial robots, drones, cameras with movable fields of view, building controls, agricultural equipment, test rigs, and some consumer devices.

It is also useful one step earlier when an AI-generated code file will later be run on hardware. Deferred execution does not remove the physical effect; it only moves the authorization boundary.

This article is not a machine-safety design, regulatory determination, or substitute for a qualified systems integrator, safety engineer, lab operator, or domain expert. High-consequence equipment may require certified safety components, formal hazard analysis, validated procedures, training, protective equipment, maintenance, and jurisdiction-specific compliance beyond anything an application-layer contract can supply.

Do not use a general AI agent for real actuation when the team cannot identify the device, measure state freshness, constrain cumulative effects, independently stop the process, observe the result, or contain ambiguity. In that case, remain in observe, recommend, or simulate mode.

A 48-Hour Founder Checklist

If MHS or another hardware interface makes a physical-agent feature newly feasible, use the next two days to narrow the product rather than rushing to connect every device.

In the first four hours:

Name one task, one physical asset, one accountable operator, and one accepted outcome.
List all people, materials, energy, equipment, and spaces the task can affect.
Mark the current release mode: observe, recommend, simulate, or actuate.

By the end of day one:

Complete the seven-layer contract for that task.
Identify which protections are independent of the model, host, network, and driver.
Define stop, verified safe state, and restart authorization separately.
Remove automatic retries from any failure that may change physical state.

On day two:

Run the eight failure drills with inert material, reduced energy, or simulation.
Verify that a changed device, stale sensor, expired approval, and missing interlock all block actuation.
Produce one command receipt and one independent effect observation.
Record who can change device tags, envelopes, drivers, code sequences, and recovery rules.

Then make a bounded decision:

Decision	Evidence threshold
Continue observing	State is useful, but actuation controls are incomplete
Pilot recommendations	Experts can verify proposals before any physical change
Pilot actuation	One narrow task passes the contract and drills with independent protection
Hold	Identity, state, interlock, outcome, or recovery remains ambiguous

MHS makes the connection layer more tractable. That is precisely why product teams need to make the authority layer more explicit. The right launch question is no longer whether the agent can reach the machine. It is whether every physical effect is bounded before execution, independently interruptible during execution, and verifiable afterward.

References