This is a field brief — front-loaded verdict, sourced facts, and the decisions they force. A different shape from the essays I usually publish here; tell me if it’s more useful.
What shipped. On 27 August 2026 Anthropic opened a research preview of the Model Hardware Standard (MHS), a specification for AI agents to operate physical laboratory and manufacturing equipment through a standard driver layer.
Why it matters. Every reliability control the agent ecosystem has built so far quietly assumes the action can be undone. A
writein MHS turns a motor. There is no revert.What to do. Nothing, if you don’t run instruments — this is a preview for labs and manufacturers. But the control pattern it forces is the one the rest of us are about six months from needing.
The facts
| Claim | Detail | Source |
|---|---|---|
| What it is | A specification for agents to operate physical devices safely, developed with HHMI Janelia Research Campus | Anthropic |
| The primitives | A driver layer exposing commands like read (“get temperature”) and write (“set temperature”) | Anthropic |
| Control paths | Three: MCP, a command line interface, and code files (APIs) | Anthropic |
| Long-running work | Agents chain driver commands across one or more devices inside code files, so long tasks run without the model reasoning at each step | Anthropic |
| Built-in safety | Device-level safety limits are enforced by MHS. Six induced fault conditions were correctly blocked in testing: missing plate, rotated plate, reader busy, disconnected camera, unreachable device, emergency stop | Anthropic |
| Stated limits | Because models learn the physical world from text and images, their spatial and physical reasoning remains limited and still needs expert oversight. Hardware without a programming interface is not supported yet | Anthropic |
| Scope | Research preview for selected research labs and advanced manufacturers; open source planned after safety evaluation | Anthropic |
| Partners named | Genentech, UW’s Baker and Pinglay labs, Carnegie Mellon, HHMI Janelia, QuEra Computing, Tetsuwan Scientific; vendors including AWS, Danaher, QIAGEN, Tecan, Universal Robots, Doosan Robotics, Automata, Hugging Face and Raspberry Pi | Anthropic |
The one property that changes everything
Strip the announcement down and you get a device abstraction with two verbs. That is not novel — SCADA and LIMS integrations have looked like that for decades. What is novel is the caller.
Here is the property that breaks the existing playbook. Read this list of the controls I’ve argued for on this site over the past year and notice what they have in common:
- Roll back the bad deploy.
- Restore the database the agent dropped.
- Revert the config change.
- Revoke the credential and rotate.
- Quarantine the branch and re-run the pipeline.
Every one of them is a compensating action taken after the fact. They work because software state is, with enough discipline, reversible. That assumption is doing enormous unacknowledged load-bearing work in how the whole industry reasons about agent safety. “Let it act, watch closely, undo the mistakes” is a coherent strategy only where undo exists.
A liquid handler that has already dispensed reagent into the wrong well has no undo. A robotic arm that has already moved has no undo. A laser that has already fired has no undo. The action is not hard to reverse; it is not reversible, and no amount of observability changes that.
So the control has to move left — out of remediation and into emission. The question stops being “how fast can we detect and correct?” and becomes “under what conditions do we refuse to emit the call at all?” That is a different engineering problem, and it is the one safety-critical industries have been solving for fifty years under names like interlocks, two-person rule, and permissive logic.
The second detail worth pausing on is the code-file path. Anthropic describes agents chaining driver commands inside code files so that long-running tasks execute without the model reasoning at each step. That is the right call for reliability and cost — you don’t want a model re-deliberating between every servo movement. But be clear about what it means: the model is not in the loop during execution. The safety properties of the run are fixed at the moment the code file is generated, not supervised while it executes. Whatever review you do has to happen against that artifact, before it runs. This is the runner-is-the-API argument with the stakes raised from “corrupted database” to “damaged equipment.”
What MHS guards, and what it doesn’t
The distinction that matters is device-level versus process-level. MHS is genuinely good at the first and makes no claim to the second.
| Layer | MHS position | Who owns it |
|---|---|---|
| Device operating limits (temperature ranges, travel limits, e-stop) | Enforced; six induced fault conditions reported blocked | MHS |
| Device discovery and capability description | Standardised; drivers emit reference files covering characteristics and safety limits | MHS |
| Is this caller allowed to drive this instrument right now? | Not addressed | You |
| Rate and volume limits on physical actions | Not addressed | You |
| Dry-run / simulate before commit | Not addressed | You |
| Which human authorised this run, provable after the fact | Not addressed | You |
| Cross-device interaction hazards (device A is safe, device B is safe, both at once is not) | Not addressed | You |
| Consumable and sample state (“is this the right plate?”) | Partly — a rotated or missing plate was caught | Shared |
That right-hand column is the whole point of this brief. A device-level limit says this actuator will not exceed 80°C. It does not say this agent may not run 400 assays overnight, and it cannot say the human who asked for this had authority to ask. Those are platform questions, and MHS deliberately leaves them to the platform.
Notably, the most encouraging safety signal in the announcement is not a spec feature at all. Genentech reported that Claude frequently paused for human confirmation before doing anything it judged even slightly risky. Good behaviour — and a model disposition, not a guarantee. Design as if it isn’t there.
The controls I’d require before an agent touches an instrument
Ordered by how much they buy you per hour of work:
- A hard, physically-enforced envelope that is not in the agent’s path. Interlocks, e-stops, fume-hood sensors, torque limits in the controller firmware. If the only thing preventing an unsafe action is software the agent can call, you have a policy, not a control. This is the one that survives every other failure on this list.
- A quota on physical actions, denominated in the thing that costs you. Dispenses, cycles, arm movements, sample consumption — not API calls. Set it low enough that a runaway loop trips it before it trips anything expensive. This is error budgets for autonomy applied to a domain where the budget is consumables and equipment hours.
- A distinct identity per agent, bound to the human who initiated the run. Not a shared instrument service account. When something goes wrong at 3am you need the record to answer “who asked for this,” and a shared credential structurally cannot. Same argument as agents need identities, not API keys, with the loss now measured in ruined samples.
- Dry-run as a first-class mode. The generated code file should execute end-to-end against a simulated device and produce a diffable plan — movements, volumes, durations — before anything actuates. If your driver layer can’t simulate, that is the gap to close first, because it is the only thing that makes review of a long chained run tractable.
- An append-only record of the emitted plan, not just the outcome. Store the code file, the driver versions, the device reference files it was generated against, and the approving identity. When you investigate, the question is “what was it about to do and why,” and outcome telemetry alone cannot answer that.
- A named human owner per instrument, with authority to revoke. Boring, and the one most often skipped. Someone must be able to say no and have that take effect in under a minute.
If you only do one: number one. Everything else on the list is software, and software is in the agent’s blast radius.
What I’d push back on
“Safely” is doing a lot of work in the framing. MHS enforces device limits and it blocked six specific fault conditions in testing, which is real and worth crediting. But device-level limits are the floor of a safety case, not the case itself. Six induced faults is a demonstration, not a hazard analysis — the interesting failures in instrument automation are usually combinatorial and process-level, and those aren’t in scope here. To Anthropic’s credit, the announcement doesn’t claim otherwise; the summarised coverage of it does.
The honest limitation is buried and it is the most important sentence in the release. Models learn the physical world through text and images, so spatial and physical reasoning remain weak. The announcement gives a concrete example: an expert had to recognise a foaming problem as a physics issue rather than a software bug. That is exactly the failure mode you should expect — the agent is fluent about the physical world without being grounded in it, which reads as competence right up until it isn’t.
And the no-programming-interface exclusion is a bigger constraint than it sounds. In most real labs and most real factories, that describes a large fraction of the equipment on the floor. The integration cost MHS removes is real; the population of devices it currently applies to is narrower than the partner list implies.
Open questions
- Does the spec define a refusal contract — a standard way for a driver to reject a call as out-of-envelope in a form the orchestrator must handle — or is that per-vendor? A standard block is worth far more than a standard write.
- What happens to a chained code file mid-execution when a device faults? Physical processes rarely have a safe arbitrary stopping point, and “halt immediately” is sometimes the more dangerous option.
- How are driver reference files versioned and trusted? They encode safety limits, they’re generated, and they’re now an input to agent planning — which makes them a supply-chain artifact with the same problems as agent skills.
- When it opens fully, does governance follow MCP to a neutral foundation, or stay vendor-held? For a spec that touches physical safety, that question isn’t academic.
The thing I keep coming back to: we spent two years building agent safety on the quiet assumption that mistakes are recoverable. That assumption was never stated because it was never tested. It is being tested now.
Related: Why your AI agent should not be allowed to act yet · The runner is the API · Autonomy is a budget, not a toggle
Comments