MHS and PhanthyMotus: what converges when an agent has to move real hardware

One standard, two routes, the same physical world

On August 27, 2026, Anthropic published a research preview of the Model Hardware Standard (MHS) — a shared specification for AI agents to safely operate physical devices, opened first to research labs and advanced manufacturers. What it sets out to solve overlaps heavily with what we have spent the past year building into phanthymotus.

This article is not about who got there first. It is about something more interesting: when two groups start from a microscope rig and from a walking humanoid respectively, and both try to solve "let a large model drive the physical world," they end up designing remarkably similar shapes — and those points of convergence are exactly where the real difficulty lives.

First, what can and cannot be compared

This has to be said up front or nothing below holds: the MHS specification is not public yet. It is a research preview behind a waitlist, and Anthropic has said explicitly that safety evaluations and best practices will be built with partners before the standard is open-sourced. There is, today, no MHS spec document to compare against clause by clause.

So the scope here is: problem definition, design logic, the shape of each solution (architectural layers, choice of primitives, where safety is enforced), and publicly disclosed engineering numbers. It excludes field names, JSON Schema details, and version negotiation rules — none of which are public. Any "detailed spec comparison" would be invented.

The three problems MHS is solving

First, integration hell. Wiring up hardware in a lab or on a factory floor typically takes weeks to months, with a specialist writing a bespoke integration per device. MHS aims to compress that to hours or minutes. There are public numbers:

Second, the tacit knowledge stuck in paper manuals. This is MHS's sharpest insight. Code can tell a model that a set_speed method exists; it cannot tell the model how much a robot arm weighs, and therefore how it can be moved safely. Historically that information lived in a manual, on someone's computer, or only in a veteran's head. MHS lets the driver carry natural-language tags holding it, then automatically produces a reference file describing what the device can measure, what can be adjusted, and what safety limits will be enforced.

Third, agents have no unified view of state. MHS puts the whole rig's state into a shared-memory state dictionary, one slot per data stream, readable by any process that attaches. Analysis and visualization code can then be reused per data type rather than rewritten per device.

Its primitives are deliberately minimal: read and write. Devices are discoverable in a standard format. There are three control paths — MCP, a command line, and code files — and it is model-agnostic, reachable by any agent harness through standard protocols such as MCP.

We were stuck on three different things

phanthymotus was never blocked by instruments that could not talk to each other. We were blocked by these:

Actions take tens of seconds to finish, while the model decides its next step in one. Speaking an 80-word explanation takes over twenty seconds; walking to the next exhibit takes a minute. The moment the model finishes calling speech it wants to call navigation — so what you see on site is a robot walking while talking, speech cut off mid-sentence, and in the worst case two motion commands issued at once.

"Moving" and "reading" must be treated differently. Checking battery, reading a camera, sampling the IMU — calling those a few extra times costs nothing. Taking a step, raising an arm, panning a gimbal — those cost an irreversible physical world. Any design that treats both as merely "a tool" will eventually hurt someone on real hardware.

A model's good intentions are not a safety mechanism. Writing "please be careful" in a prompt constrains nothing. Constraints have to live where the model cannot reach them: in the driver, in the harness, in the protocol.

Four points of convergence

The two groups never coordinated, yet gave the same answer on four things.

One: the unit of standardization is the driver, not a central gateway. Rather than building one orchestrator that adapts to every device, push the standard down onto each device so it describes itself in a uniform shape. MHS calls it a standardized driver; we call it one MCP server per device. Same judgment.

Two: devices must describe themselves, and describe themselves to the model. MHS uses natural-language tags plus a generated reference file; we have drivers declare tool type, parameter schema, and output stream format — and the driver computes its own output topics, with the canvas asking the driver for the exact path so all naming logic stays inside the driver. Both insist on the same thing: knowledge about a device must live with the device, not sink into central code.

Three: safety is enforced at the device layer, not left to the model. MHS enforces device-level limits; the Janelia researcher put it plainly — because MHS enforces those limits, they do not worry about an agent using excessive laser power and bleaching the sample. On our side it is driver-level clamping, exposing only verified postures, and per-variant capability allowlists. A model may request; it may not exceed.

Four: deterministic code absorbs whatever outruns online reasoning. The most striking passage in the MHS announcement: the agent adjusted a laser, watched the beam through a camera, adjusted again, and once it understood the causal chain wrote what it had learned into a deterministic script, after which alignment was a single command. Our ACP is the same idea from another angle — the model owns the decision sequence, the harness guarantees physical actions land serially, and the model neither has to nor should reason on every frame.

Six designs that real hardware forced on us

Each one starts with the scenario that hurts someone or collapses a demo, then explains why the design had to be this way.

While the robot is walking, should "check the battery" wait in line? If a framework queues every tool identically, reading battery or glancing at a camera has to wait for the walk to finish — yet it is precisely while it moves that you most need sensor reads, since that is the only basis for deciding whether to interrupt. Putting monitoring behind the thing being monitored locks the safety mechanism outside the door. But skip the queue entirely and two motion commands overlap. So reads and writes cannot be the same kind of thing: tools are typed as sensor / actuator / processor / resource, and the ACP barrier blocks only the latter two — never sensors and read-only resources.

The model put "stop" parameters into "go forward." One locomotion tool carries move / stop / set height / wave. Flatten all parameters into one table and the model sees six mixed fields; it will attach velocity to stop, and it will omit velocity on move while filling in height — which on real hardware means a joint moved that should not have. So each action declares the parameters it actually uses, and the framework splits one tool into several independent functions: stop takes no parameters at all, so the model physically cannot give it a velocity. Constraints should not be written into a description asking the model to cooperate; they belong in the signature it sees, leaving nothing to violate.

The tour robot walks off mid-sentence. Making the tool synchronous and blocking does not fix this — it is worse, since the model idles for twenty seconds that were the best moment to prepare the next segment. What is actually needed is "the model keeps thinking, but physical actions land serially." That is ACP: an async tool returns an action ID immediately, the model reasons on, and before the next actuating tool is dispatched the harness automatically waits for everything outstanding. Timeouts have to scale with content, because a fixed timeout is too long for one sentence and too short for a paragraph.

You interrupt it, and it stops talking three seconds later. If "stop speaking" goes through the normal tool-call path it waits a full LLM round; for those 1–5 seconds the robot is still talking, the user assumes it did not hear and repeats, speech recognition fires again, and the interaction collapses. Emergency stop is worse — an emergency stop that has to wait in line is not an emergency stop. So system hooks are a path that deliberately bypasses the model: no LLM, no barrier, no schema validation, under 50 ms. That decision propagates down into how drivers are written: bounded-duration motions are capped at three seconds and deliberately register no barrier, purely so a stop command can always cut in.

Someone shares their robot setup — API key included. A canvas setup can be packaged and uploaded to a marketplace, which means it carries keys and tokens. Guessing by field name is not acceptable: it misses real secrets and wrongly clears harmless fields, and a safety mechanism that both leaks and misfires is more dangerous than the protection it offers. So it became explicit declaration: password-type fields are sensitive by default, with separate markers for "must stay visible but must never ship" and for "fixed factory password, where blanking it only makes the recipient retype the same default." Cleared fields are surfaced to the downloader as "needs configuration."

The same driver installed on two different hardware variants. The lazy approach exposes everything and errors out where unsupported. Acceptable in pure software; not here — a model that sees a tool exist treats it as a viable path, writes it into a plan, retries, tries different parameters to get around the failure, and every attempt is a real command sent to hardware. So capabilities come from a per-variant allowlist: on this machine, that tool simply does not exist. The same reasoning goes further in posture control: expose only the stand / sit / lie states verified on real hardware, route every non-standing transition through standing, and return the actual path taken. Narrowing the capability surface is not conservatism; it is because a model's exploratory behavior has a price in the physical world.

Three real differences, and where they come from

Almost none of these are cases of one side not thinking of something. They come from standing on different ground.

Why one data plane is shared memory and the other is DDS. MHS grew on one rig in one room: every instrument on the same machines, with brutal closed-loop requirements — a camera sees the beam position and must immediately feed the galvo mirrors correcting the optical path. Under that constraint a shared-memory dictionary is the right answer, and serialization plus discovery are pure overhead. A robot's ground is different: it is inherently distributed, with compute board, motion-control board, and peripherals in separate places, and it also has to talk to another robot, to venue cameras, and to a remote dashboard. The hardware span is far wider than one lab — humanoids, quadrupeds, drones, dexterous hands — and the existing stacks for those forms almost all grew on ROS2. Our cost is paid in "can it be connected at all," not in "is it microsecond-fast." The two are not exclusive: a same-machine high-rate loop can use shared memory inside the driver process while DDS carries only the externally observable layer. That is the trick we would most like to borrow.

One is pushing a standard; the other is accumulating a working system. This is the most fundamental difference and the easiest to misread as a ranking. MHS's route is to define the standard and have vendors adopt it, and the list is serious: AWS, Automata, Danaher, Doosan Robotics, MBF Bioscience, QIAGEN, Tecan, Universal Robots, plus LeRobot and Raspberry Pi. The ceiling is very high — once a vendor supports it natively, integration cost approaches zero. The cost is dependence on someone else's roadmap: before a given vendor ships support, that device cannot be connected. phanthymotus chose not to wait: we adapt device by device ourselves — 15 drivers, 11 vendors, 5 hardware forms. What a developer gets is not "here is a specification, please implement it" but something that runs when you plug it in: drivers, canvas, perception stack, ACP, permissions, and packaging. The cost is equally clear — our adapted surface always has an edge, and hardware outside the list still needs someone to write a driver. MHS cares whether the standard gets adopted; we care whether it runs today. Which is also why the two look more like neighbors than rivals: each of our drivers is itself an MCP server, and MHS describes itself as model-agnostic and reachable over MCP.

Safety evaluation: both treat it as first priority, with different verification methods. This is not a gap. Anthropic has said it will use the entire research preview to build safety evaluations and a physical safety roadmap; we write safety directly into the protocol. The difference is method. They lean toward fault injection and coverage — CMU induced six conditions (missing plate, rotated plate, reader busy, disconnected camera, unreachable device, active emergency stop) and all six were blocked before any device moved, which is reproducible and countable. We lean toward real-hardware verification with tests guarding regressions — seven permanently connected robots, 172 perception tests, and unit tests watching the posture-transit behavior. The weak spots are symmetric: their evaluation set is not public yet and it is unclear whether it covers forms that move and can hit people; our protections are point defenses, and we lack a reproducible fault-injection suite. That one we intend to copy, translated into robot terms: battery collapse, joint overtemperature, DDS stream loss, remote-control link loss, and indeterminate posture.

What is actually shipping

Seven robots stay permanently connected for debugging, including both JetPack 5.11 and 6.1 lines so a new-version regression can be told apart from a problem present on both. The 172 perception tests cover the TTS engine facade, the speech-synthesis frontend, the ASR device registry, OCR, and shared utilities. Shipping platform capabilities include the ACP barrier and completion callbacks, model-bypassing system hooks, layered prompts with editable long-term memory, memory retrieval with isolated subagent contexts, daily auto-summaries, solution packaging with credential redaction, and channel integration with a permissions panel.

Closing: the fight over standards is not a fight over formats

Reading MHS, the strongest feeling was not "we have been overtaken" but "we have been corroborated."

A year ago we decided to type tools into four kinds instead of unifying them as "functions," to write safety clamps into drivers instead of prompts, and to invent a barrier purely because physical actions have duration. All of that looked like over-engineering at the time. Now the best model team in the world, arriving from the direction of microscopes and quantum computers, has given the same answer on four key judgments. That means these were never our preferences. They are properties of the physical world.

The remaining differences are not right versus wrong; they are different wards. They face seven programs, three computers, and a plate reader with no interface. We face a machine that walks, gets interrupted mid-sentence, and lands on someone if it falls. So they spent their effort on a unified cross-device view of state, and we spent ours on the ordering and irreversibility of actions.

The real fight over standards was never about formats. It is about who writes the physical world's failure modes into the protocol first. Bubbles, disconnections, emergency stops, overlapping motions, squatting down and not getting back up — each one has to be crashed into on real hardware before it becomes a field in a specification. On that count, what we have accumulated is not lines of code. It is the number of times we have fallen over.

Every statement here about MHS comes from Anthropic's announcement of 2026-08-27 and the five partner reports within it. The MHS specification itself is not public; this article contains no speculation about its field-level details.