Five days ago, Anthropic announced the Model Hardware Standard, MHS for short. It is the physical-world sibling of MCP, the protocol that taught AI models how to talk to software. MHS is an attempt to teach them how to talk to machines: microscopes, liquid handlers, robot arms. A standardized driver with two primitives, read and write. Devices that discover each other in a common format. Natural-language tags that capture what code cannot say, like how much a robot arm weighs, or where its safety limits sit.
The early numbers are the kind you notice. Carnegie Mellon wired up a complete serial dilution experiment in about eight hours, against the several weeks a vendor-built setup typically takes, and ran it roughly three times faster. QuEra Computing let an agent stabilize lasers in a quantum computer: 99.3 percent recovery in a blind test, 695 out of 700. The partner list reads like a lab procurement catalog: Tecan, QIAGEN, Universal Robots, Doosan, Danaher, Raspberry Pi, Hugging Face.
So the temptation arrives on day one, and I felt it too: take a small FPGA, bolt it onto an old machine, implement the MHS driver, and suddenly everything can be talked to by AI without changing its software. The 2009 liquid handler. The CNC from another decade. The microscope with the undocumented serial port.
It is a beautiful idea. It is also, as usually stated this week, wrong. But there is a narrower version of it that I think is genuinely important, and it has nothing to do with connectivity.
The Cost Does Not Disappear. It Moves.
Here is the part of the dream that does not survive contact with the bench. The FPGA shim does not delete the integration cost. It relocates it.
Anthropic’s headline claim, integration work reduced from weeks to hours, is real, but read the fine print: it applies to devices someone has already written an MHS driver for. For everything else, someone still has to reverse-engineer the command set of that 2009 liquid handler, map it to read and write primitives, encode its limits into metadata, and test it until they trust it. The bottleneck was never the silicon. It is the driver, and it always was.
Anthropic says MHS works with any device that has a programmable interface. True, and almost useless at the scale that matters. The ten partner devices are coverage. The ten thousand instrument models sitting in labs and factories worldwide are the market. Whether this standard changes the physical world depends less on Anthropic and more on a question nobody has answered yet: does a crowdsourced driver ecosystem form around MHS the way it formed around MCP servers? If yes, the long tail gets covered in a few years. If no, MHS stays a convenience for ten devices.
There is a second, quieter correction. “Without changing its software” only works where a control interface exists to attach to. RS-232, USB, CAN, GPIB. Your toaster has none of these, and no shim will give it one. The retrofit story was never about the kitchen. It is about the lab bench and the factory floor, which happens to be exactly where the partner list is aimed.
And that narrowing is not a weakness. It is the actual point. In pharma and manufacturing, firmware is frozen for reasons that have nothing to do with laziness: touch it and you revalidate the instrument under GxP, re-run qualifications, re-file paperwork. The single most expensive sentence in regulated automation is “we cannot touch the firmware.” A layer that genuinely does not touch it is answering a constraint that keeps real people up at night.
What a Small FPGA Bridge Actually Is
So let me sketch the thing properly, because the interesting design question is not “can it be done.” It can. The question is what belongs in the fabric.
The bridge is two-sided. On the network side, an MHS endpoint: it announces the device, serves the reference file, accepts MCP, CLI or code-file sessions. This side is not why you choose an FPGA. It is a network service; a soft core or an auxiliary MCU handles it fine.
The device side is where fabric earns its keep. Old instruments speak inconvenient protocols: bit-banged GPIB with timing you cannot get wrong, proprietary buses with strange edges, multiple interfaces that must run concurrently without an RTOS deciding to go think about something else. A one-dollar microcontroller covers the polite cases. A small FPGA covers the impolite ones, and because the fabric is reconfigurable, the same board can be re-targeted from a Tecan pump to a legacy oscilloscope by loading a different bitstream. The protocol adapter is itself software-defined. That is the honest case for FPGAs here, and it is enough.
But it is not the reason I would build one. The reason is the other thing fabric gives you: a hard boundary.
Look at Anthropic’s own results. Genentech’s agent needed a human to tell it that an error was caused by foaming, not a software bug. QuEra’s report is blunter: Claude lacked physical troubleshooting understanding, paused overnight waiting for approvals, and their conclusion was that an overly cautious agent is preferable to the alternative. Preferable, yes. But the oversight in every one of these deployments is a person, a script, or the model’s own judgment.
Now imagine the safety limits from the MHS metadata, the ones the announcement says the driver enforces, compiled into the FPGA instead. A deterministic watchdog in fabric that physically refuses any write outside the declared bounds. Not a Python guard clause the agent could reason its way around. Not a prompt. A piece of silicon between the agent and the motor, with no software path around it, that answers within a fixed number of clock cycles every time.
An agent can read a safety limit. Only silicon can refuse to cross it.
That is the reframing I keep coming back to. Everyone, including me, reached for the FPGA as a connectivity gadget, the thing that lets old machines join the conversation. The more interesting role is the opposite: it is the thing that lets us let agents act on machines, because someone can point at a component and say, that part is not intelligent, that part cannot be talked out of its limits. The announcement mentions a physical safety roadmap. Before any regulator accepts a model-actuated actuator, somebody will have to prove enforcement that does not depend on the model. A small FPGA is the cheapest credible way to run that experiment.
So, Useless or Wet Dream?
As pitched this week, with the implied promise that a shim makes everything AI-operable: wet dream. The driver ecosystem is the missing piece, not the silicon, and it is unproven.
Narrowed to what the constraint actually is, frozen, validated firmware in labs and factories, the retrofit story is defensible and mostly unoccupied. MHS is five days old and not yet open source, so the window for writing about it, and building on it, is wide open.
And the piece the current conversation is missing is the one I would bet on: not how to connect agents to machines, but how to build the boundary that makes it responsible to do so. If that boundary turns out to be a twenty-dollar chip between the network and the motor, then the FPGA was never a gadget. It was the trust layer, hiding in plain sight, waiting for a standard to give it a vocabulary.