What OpenMHS is
OpenMHS is an open, model-agnostic, supervisory interface between AI agents and programmable hardware. It is one trusted program, the gateway, that every agent, script and person goes through to reach a machine.
The idea, simply
Imagine a lab hires a very fast, very capable new assistant. The assistant is clever, but sometimes misunderstands an instruction and is occasionally too sure of itself. You would like it to help run the lab's machines.
You would not hand over the keys. You would put a supervisor between the assistant and the machines, and the supervisor would:
- let the assistant touch nothing until you say which machines it may use;
- know each machine's limits, and refuse "48 volts" on a supply that only goes to 12;
- ask "5 what?" when told "set it to 5", instead of guessing the unit;
- make it change things gradually, not jump from zero to full power;
- call you before anything dangerous, and never let the assistant approve itself;
- look at the machine afterwards to confirm the job really happened;
- say "I don't know yet" when a reply is lost, then go and check, rather than guess;
- keep a logbook in which a torn-out page is noticed.
OpenMHS is that supervisor, written as software. The assistant is an AI agent. The machines are real devices, or simulated ones while you test.
Background: agents, tools, MCP and MHS
AI agents and tools
A large language model on its own only produces text. An agent is a model running in a loop that can also take actions: it decides on a step, calls a tool (a function such as "read the temperature"), looks at the result, and decides the next step. The tool is ordinary code; the model only chooses when to call it and with which inputs.
MCP, the Model Context Protocol
MCP is an open standard for connecting agents to tools. A program called an MCP server lists the tools it offers and how to call them; any MCP host (Claude Code, Claude Desktop, an IDE agent, your own client) can use them. Write a tool once, and every compatible agent can call it.
OpenMHS includes an MCP server, openmhs mcp. Through it an agent sees
tools such as list_devices, describe_device,
read_state, check_command, submit_command and
submit_plan. The server holds only an agent's token, so everything the
agent does is checked and recorded by the gateway like any other client.
MHS, the Model Hardware Standard
MCP was designed for software. Machines add problems software does not have: units, physical limits, slow or lost replies, and actions that cannot be undone. In August 2026 Anthropic announced the Model Hardware Standard as a limited research preview: per-device drivers that describe a machine's operations and safety limits in a common, discoverable format, so that any model can work with any device that has a programmable interface.
The MHS specification has not been published. Many community projects appeared afterwards with "open MHS" in their names. OpenMHS is one of them, but it does not imitate a format it cannot see. It defines its own specification, and is structured so that an MHS-compatible front end can be added if the standard is published.
| What it connects | Status | |
|---|---|---|
| MCP | Agents to software tools | Open standard, widely used |
| MHS | Agents to hardware (Anthropic) | Research preview, no public specification |
| OpenMHS | Agents, scripts and people to hardware, through one supervising gateway | Independent, open source, pre-alpha |
Why machines need a supervisor
Connecting an agent to a machine is the easy part. The hard part is what happens when something goes wrong, because with hardware the consequences are physical.
| Problem | What can happen without a supervisor |
|---|---|
| Out-of-range values | A model asks for 48 V on a 12 V supply and the device is damaged. |
| Missing units | "Move 5" is read as 5 cm instead of 5 mm. |
| Sudden changes | A jump from 0 to full output stresses the equipment or the sample. |
| Stale readings | A decision is made from a temperature that is several seconds old. |
| Lost replies | The device acted but the answer never came back. A naive client retries, and the action happens twice. |
| Crashes | A driver or the gateway dies mid-command, and nobody knows what state the machine is in. |
| No oversight | A hazardous move runs with no person in the loop, and afterwards there is no trustworthy record. |
What OpenMHS does
- Describes devices. Each device has a descriptor: a JSON document listing its capabilities, units, ranges, rate and slew limits, preconditions and how to verify a change.
- Authorizes every request. Identities (principals) get grants from an operator: allow, deny, or require approval. Access is denied by default, and agents cannot change policy or approve their own requests.
- Validates every value. Units, ranges, slew and rate limits, preconditions and freshness are checked before anything is sent.
- Tracks each command through a lifecycle. Accepted is not applied, and applied is not verified. Success means the device was read back.
- Handles uncertainty explicitly. A timeout or crash after a
command was sent becomes
UNKNOWN_OUTCOME, which is never retried blindly and is settled by reading the device. - Survives restarts. A SQLite journal records intent before dispatch, so the gateway recovers after a crash. Idempotency keys make retries safe.
- Keeps evidence. A hash-chained audit log makes tampering detectable, and every command produces a receipt.
- Connects to real protocols. Modbus TCP, MQTT, SCPI and HTTP devices are described by JSON profiles. OPC UA and ROS 2 adapters observe equipment. Adapters in other languages run as supervised child processes.
- Coordinates several devices. Plans run ordered steps under one lease, and say what to do when a step fails: halt, compensate, or ask a person.
- Tests integrations. A conformance suite checks an adapter against levels L0 to L3 with injected faults, and writes a JSON report.
What it is not
- Not a safety system. Emergency stops, interlocks and protection circuits belong to the hardware and keep final authority.
- Not a real-time controller. Fast control loops stay in the device's own controller. OpenMHS supervises; it does not drive motors directly.
- Not tied to one model. Any agent that speaks MCP, or any program that uses the API, can use it.
- Not proven on physical hardware yet. Everything is tested against simulators or simulated peers. Two experiments went further, still without physical hardware: a read-only adapter against a real OctoPrint server driving its Virtual Printer, and real ESP32 firmware running in QEMU over a real MQTT broker (results).
Who it is for
- Labs that want agents to help run instruments and experiments with a person approving the risky parts.
- Automation and integration developers who connect equipment over Modbus, MQTT, SCPI, HTTP, OPC UA or ROS 2.
- Makers and researchers who want to try agent-driven hardware safely against simulators first.
- Adapter authors who want a clear contract and a test suite that says whether their integration behaves.
How it differs from similar projects
Most of the community "open MHS" projects the maintainers looked at share one feature set: a device manifest with limits, MCP tools, read, write and stop, and an audit log. OpenMHS focuses on what happens under real-world failure:
- a durable command journal with crash recovery and idempotency keys;
- an explicit lifecycle where
ACCEPTED,APPLIEDandVERIFIEDare different states; UNKNOWN_OUTCOMEwith reconciliation by readback;- an implementation-neutral conformance suite with fault injection;
- a single gateway binary written in Rust, which every interface goes through.
The comparison is in the repository's landscape research, with sources.
Independence and the name
OpenMHS is not affiliated with or endorsed by Anthropic, and does not claim compatibility with the Model Hardware Standard. Other unrelated projects also use the name "OpenMHS"; this one keeps it knowingly. The reasoning is in naming.md and ADR-0007.
Next: how it works.