Anthropic previewed the Model Hardware Standard this week: a driver standard for AI agents operating equipment (read/write primitives, discovery, a per-device reference file of what it measures, adjusts, and refuses), model-agnostic, reachable over MCP, and to be open-sourced after safety evaluations exist.
Universal Robots and Doosan are among the partners. Announcement: Previewing the Model Hardware Standard \ Anthropic
I maintain URML, an Apache-2.0 intent language whose programs are validated whole against a capability manifest and a deployment safety envelope before dispatch, with a ROS 2 reference runtime among others ( GitHub - URML-MARS/URML: The specification, reference runtimes, validator, LLM bridge, and conformance suite for URML — an open language for robot intent. · GitHub ). My read of the layering: MHS is a Layer-0 driver and description standard, in the same family as URDF and SDF, and an intent layer derives its manifest from those and dispatches through them.
A per-call limit at the device catches the fifth action of a bad plan; a whole-program check refuses the plan, and a separate deployment envelope lets a site be stricter than the vendor.
The positioning doc with a mapping table is here: URML/docs/integrations/model-hardware-standard.md at main · URML-MARS/URML · GitHub , and a hermetic safety-evaluation harness built for the gate Anthropic named is here: URML/examples/physical-ai-safety-eval at main · URML-MARS/URML · GitHub
The one question I would value this community’s view on: which ROS 2 device-description conventions should a reference-file-to-manifest mapping respect so that an MHS device and a ROS 2 device describe their limits the same way? I am thinking of URDF joint limits, ros2_control command and state interfaces, and sensor_msgs field names, but I would rather hear what people who maintain those think than guess.
Not asking anyone to adopt anything; corrections to the layering picture are welcome too.