A Driver Standard for Machines an Agent Can Drive

Anthropic has introduced a research preview of the Model Hardware Standard, a specification that lets AI agents discover and control physical equipment including robotic arms, microscopes and laboratory systems. MHS works as a standardised software driver sitting between a computer's operating system and a physical device, exposing a common command set for reading equipment information and adjusting settings, together with standardised hardware descriptions that declare measurable parameters and safety limits. It is not tied to any specific AI model, and agents can reach it through established protocols such as the Model Context Protocol. Doosan Robotics is testing MHS with robotic arms for automated quality assurance and Universal Robots plans to add support; other named participants are Danaher, Tecan, QIAGEN and MBF Bioscience, with platform support from Amazon Web Services and Hugging Face. The stated aim is to cut equipment integration time currently measured in days or weeks, and to let an agent coordinate several inspection devices, cameras and measurement instruments together rather than operating each in isolation. Anthropic says the current version remains a research preview and that it intends to develop safety evaluations and operating practices before making the standard open source; it also acknowledges that AI agents can have difficulty understanding the physical causes of equipment failures and that expert oversight remains necessary.

The part of this that is recognisable to anyone who has integrated instruments is the driver problem, which has nothing to do with AI. Every microscope, scale, CMM and robot controller exposes its own command set over its own transport, documented to its own standard, and connecting five instruments into one workflow means writing five adapters and maintaining them through five firmware roadmaps. That cost is why laboratory and inspection automation is dominated by single-vendor cells. A common driver layer with machine-readable capability descriptions is a useful thing whether or not the client is a language model.

The declared safety limits in the hardware description are the design decision worth watching, because they are where this either works or does not. An agent that can discover a device's capabilities can also request something the device should not do, and a specification that carries a machine-readable envelope of permitted parameters is attempting to make refusal a property of the driver rather than of the agent's judgement. That is the correct architecture — a machine's safety interlocks should never depend on the good behaviour of whatever is sending commands — and its adequacy is exactly what the research preview period should establish.

For industrial readers the practical posture is interest rather than adoption. A research preview with a named set of partners is not a procurement input, and the safety-critical layer of any plant should not be the first place a new control interface is tried. The sensible engagement is at the edges where the cost of being wrong is a wasted sample rather than a damaged machine: automated quality assurance, metrology cells, laboratory workflows — which is precisely where the first named participants are testing it.