What MHS actually is
Anthropic's Model Hardware Standard introduces a standardized driver layer that translates between an operating system and a physical device using simple read/write commands. Each driver also carries the device's physical characteristics — weight, safety limits, adjustable parameters — information that today mostly exists in paper manuals or in the tacit knowledge of a specialist technician. Anthropic says the standard cuts device-integration work from weeks or months to hours or minutes, is model-agnostic, and will eventually be open-sourced so any device manufacturer can adopt it.
The near-term use is narrow and credible: labs and manufacturing floors where an agent needs to run a microscope, calibrate a laser, or dispense a reagent without a human writing device-specific integration code for every instrument.
Device limits are not the same thing as policy
MHS drivers encode device-local invariants: a laser's maximum power, a motor's valid operating range, which commands a piece of equipment actually supports. Those are hard physical facts. They answer “can this device do this at all,” not “should this agent be allowed to ask it to.”
That second question is organizational policy, and it sits above the device layer entirely. “Never exceed 20 mW” is a device guardrail. “An autonomous agent may not change production calibration without an approved engineering decision” is not — no device driver can express it, because it isn't a fact about the hardware. It's a fact about who is allowed to decide what, and under which conditions.
Device safety and organizational policy are different layers, enforced differently
The gap this leaves open
MHS gives a physical-facing agent a way to know what a device can do. It does not give an organization a way to express which devices an agent may use in what sequence, when human approval is required before a step, which data may travel to which instrument, or whether a workflow is allowed to modify a process autonomously. Examples worth sitting with:
- A robotic workflow may adjust motion parameters, but must not redefine a safety zone without human sign-off.
- A sample-handling agent must never route patient-identifiable data to an external analysis instrument.
- An autonomous agent may not change production calibration without an approved engineering decision behind it.
Each is a decision an organization made, or should make, before an agent is given authority over the equipment.
Software architecture already has this exact gap
This is not a new problem for Mneme — it's the same problem restated in a physical register. In software, an agent that can technically execute a database write is not thereby authorized to write to a table an ADR designated read-only, or to introduce a dependency the architecture forbids. The compiler and the runtime will happily let it happen; nothing at that layer knows the decision exists.
MHS device drivers are the physical-world equivalent of a permissive runtime: correct about what is mechanically possible, silent about what is organizationally allowed. The pattern rhymes with what pre-action architectural enforcement already does for coding agents — evaluate the compiled decision corpus against a proposed action deterministically, then pass, warn, or fail before the action crosses a consequential boundary. For architectural governance today that boundary is a file write or a shell command. As device-control standards like MHS mature, someone will have to answer the same question at robot.move() or reactor.set_temperature().
Conclusion
MHS is a genuine and useful piece of infrastructure: it solves device integration, and it does so without requiring any particular model. But solving device integration is not the same as solving authorization, and the standard does not claim to be. That second problem lands on whoever deploys the agent.
Device standards answer what a machine can do. Governance answers what an agent is allowed to do with it. Software already needed both layers; physical AI is about to need them too.