# Anthropic MHS Evidence Notes Updated: 2026-10-07 Scope: Anthropic Model Hardware Standard (MHS), hardware abstraction, low-Hz Agent / high-Hz control split, safety boundaries, deterministic fast path, early partner cases, and production-readiness gaps. ## Research questions 1. What does MHS standardize that MCP, vendor SDKs, ROS 2, or VLA policies do not? 2. How does MHS bridge slow online model reasoning and high-frequency physical control? 3. Is "Agent explores → writes deterministic controller → controller runs without Agent" a generalizable pattern or only a demo artifact? 4. Which safety properties are enforced outside the model, and which remain prompt/model dependent? 5. What must be added before MHS can be treated as a production control standard rather than a research preview? ## Core thesis The key MHS architectural idea is not to run an LLM at hardware control frequency. MHS standardizes a hardware-facing driver and device description so the Agent can discover and reason about equipment, then offers MCP, CLI, and code-file paths to operate it. When long-running or faster-than-online-reasoning behavior is required, the Agent chains device commands into deterministic code. This creates a slow reasoning/control plane and a fast deterministic execution plane. This thesis is strongly supported by Anthropic's own MHS architecture description and especially by the QuEra case, where the end product was a deterministic script that could run in production without an AI agent controlling it. It is still a derived systems interpretation rather than a formal MHS specification statement. ## Evidence grading ### E1 — Anthropic: Previewing the Model Hardware Standard, 2026-08-27 URL: https://www.anthropic.com/news/model-hardware-standard-research-preview Grade: Primary / official research preview and partner case report. Supports: - MHS is a shared specification for AI agents operating physical devices in scientific research and advanced manufacturing. - Development began as a collaboration between Anthropic and HHMI Janelia Research Campus. - MHS is in limited research preview and intended to become open source later. - It works with devices that expose a programmable interface. - It is model-agnostic and can be accessed from agent harnesses using standard protocols such as MCP. - MHS introduces a standardized driver between a computer/OS and a hardware device. - Publicly described primitive examples are read and write. - Device tags can encode natural-language information not obvious from code, including physical characteristics and safety limits. - The driver produces a reference file describing what a device can measure, what can be adjusted, and what safety limits will be enforced. - Three control mechanisms are explicitly described: MCP, CLI, and code files/APIs. - For long-running tasks or tasks faster than online reasoning allows, commands can be chained in code files so devices continue without Agent reasoning at each step. - Claude was observed exploring laser alignment through repeated adjustment/observation and then packaging the learned sequence into a deterministic script. Boundary: - Research preview, not proof of mature cross-vendor interoperability. - Public material does not state hard-real-time scheduling/jitter guarantees. - "Safety limits will be enforced" does not by itself establish industrial functional-safety certification or formal verification. ### E2 — QuEra partner case inside Anthropic MHS announcement URL: https://www.anthropic.com/news/model-hardware-standard-research-preview Grade: Primary / vendor + partner case study. Supports: - Baseline human-derived recovery script worked about 58% of the time and took around 150 seconds per attempt. - Claude accessed the laser system through MHS, proposed hypotheses, rewrote recovery code, ran experiments, and reviewed logs in a repeated overnight loop. - Development run reached about 96% success with roughly six-second recovery. - Final blind test used 700 randomized disturbance trials and succeeded 695 times: 99.3%. - Hardest disturbances took 10–14 seconds; simpler ones 0.9–5.4 seconds. - Final result was a deterministic, fully inspectable script capable of production operation without an AI agent controlling it. - A later PID optimization loop ran 363 experiments over 16 unattended hours and reduced residual RMS error from 15.7 mV to 1.55 mV. Implication: - This is the strongest published evidence for the "Agent as controller synthesizer / improver, deterministic program as production fast path" interpretation. Boundary: - One controlled partner system; not a general MHS benchmark. - Success depends on the quality of the MHS driver, experiment setup, success metric, disturbance distribution, and expert-defined boundaries. ### E3 — HHMI Janelia microscopy case inside Anthropic announcement URL: https://www.anthropic.com/news/model-hardware-standard-research-preview Grade: Primary / partner case study. Supports: - A microscopy rig previously involved seven vendor programs without a shared interface. - Device software spans multiple languages, including MATLAB, Python, and C#. - MHS unified device access so the rig state could be made available through one interface. - MHS originated from Arco Bast's shared-memory dictionary idea for a multi-device microscope. - Shared-memory communication enabled instruments to exchange state at memory speed before the interface evolved into MHS. - In agentic microscopy, deterministic acquisition/analysis loops can run while the Agent enters at decision points such as choosing imaging regions and analysis. Implication: - The useful split is "deterministic high-rate acquisition/control + sparse semantic decision points", not an LLM in every tick. ### E4 — Genentech BCA lab-automation case URL: https://www.anthropic.com/news/model-hardware-standard-research-preview Grade: Primary / partner case study. Supports: - BCA assay proof-of-concept coordinated a liquid handler, robotic arm, and microplate reader. - Existing lab automation setup can require weeks or months and significant custom programming. - MHS was used to standardize AI-to-hardware communication and reduce bespoke robotic code. - Claude encountered errors caused by bubbles/foaming and initially retried in ways that worsened the physical problem. - Human experts had to guide it toward gentler physical handling. Implication: - Standardized device I/O does not solve physical reasoning. - Physical failure semantics, material properties, collision/inertia/thermal/fluid effects, and expert process knowledge remain critical. ### E5 — Official MHS project site URL: https://modelhardwarestandard.com/ Grade: Primary / official project landing page. Supports: - MHS is described as a standard for AI agents to safely operate physical equipment. - Project origin is Anthropic + HHMI Janelia. - Current access is a limited research preview. - The preview is intended to gather stakeholders, safety evaluations, and best practices before open sourcing. Boundary: - Landing page is high-level; it does not yet expose a complete public conformance specification or reference SDK in the evidence collected for this topic. ### E6 — Reuters independent coverage, 2026-08-27 URL: https://www.reuters.com/technology/anthropic-unveils-new-framework-allowing-ai-agents-operate-physical-devices-2026-08-27/ Grade: Independent / secondary confirmation. Supports: - Independent confirmation of MHS launch and research-preview status. - Confirms intended use across scientific equipment and advanced manufacturing. - Confirms examples such as microscopes, robotic arms, drug discovery, and quantum-computer laser calibration. Boundary: - Useful for event confirmation, not low-level technical semantics. ### E7 — MCP 2026-07-28 specification context URL: https://blog.modelcontextprotocol.io/posts/2026-07-28/ Grade: Primary / adjacent protocol. Supports: - MCP is a general agent/tool/resource interaction protocol with a stateless core and Streamable HTTP evolution. - This supports the architectural distinction: MCP can carry calls to an MHS-exposed device, but MCP itself does not define hardware physics, device capabilities, safety envelopes, or real-time control semantics. ### E8 — Hugging Face LeRobot documentation URL: https://huggingface.co/docs/lerobot/main/index Grade: Primary / adjacent robotics ecosystem. Supports: - LeRobot provides hardware-agnostic interfaces, datasets, policies, and deployment workflows for real robots. - It includes VLA/policy systems that predict actions, while real robot deployments still need hardware interfaces and, for demanding systems, fast controllers. Related current evidence: - https://huggingface.co/blog/nepyope/bringing-humanoids-to-lerobot - The humanoid example explicitly separates a policy that predicts motion tokens from a fast controller that decodes them into stable whole-body motion. Implication: - In robotics, a slow semantic/policy layer + fast local control layer is not unique to MHS; MHS may standardize the Agent-facing hardware interface around that broader systems pattern. ### E9 — Universal Robots MHS cobot test, 2026-08-28 URL: https://www.universal-robots.com/blog/testing-agentic-physical-ai-univeral-robots-cobots/ Grade: Primary / robot-vendor partner evidence. Supports: - An Agent coordinated four separate UR cobot applications as a single cell and handed payloads between robots. - MHS adds Agent-facing device bounds and interlocks while UR's own robot safety architecture remains authoritative underneath. Implication: - MHS is already being tested beyond scientific instruments as a multi-robot orchestration/capability layer. - This does not establish that MHS replaces trajectory generation, whole-body control, servo control, or certified robot safety. ### E10 — Google DeepMind Gemini Robotics 2, 2026-07-30 URL: https://deepmind.google/blog/gemini-robotics-2-brings-whole-body-intelligence-to-robots/ Grade: Primary / adjacent embodied-AI architecture. Supports: - Gemini Robotics ER 2 acts as a high-level embodied reasoner and coordinates with a VLA for motor execution. - Gemini Robotics 2 provides whole-body VLA control and multi-robot capabilities. ### E11 — LeRobot humanoid stack, 2026-09-25 URL: https://huggingface.co/blog/nepyope/bringing-humanoids-to-lerobot Grade: Primary ecosystem / adjacent humanoid implementation. Supports: - A π0.5 policy predicts SONIC latent motion tokens from language, robot state, and camera observations. - A fast controller on Unitree G1 decodes those tokens into stable 29-DoF whole-body motion. Implication: - VLA-based embodied intelligence and MHS-style Agent systems share a slow/fast hierarchy. - Their more meaningful distinction is the representation of reusable intelligence: learned policy/action generation versus explicit program/skill generation. ## Embodied-control hypothesis ### E12 — MHS update: states + procedures and autonomous rerun URL: https://www.anthropic.com/news/model-hardware-standard-research-preview Grade: Primary / updated official case evidence. Supports: - Heterogeneous equipment is normalized into one manifest of **states** and **procedures**, even when the underlying controls are job files, Windows COM, or GUI-only software. - In the dose-response workflow, the system rejected a weak run, changed the concentration range, and autonomously repeated the experiment. - Anthropic reports eight hours from raw equipment readiness to a completed dilution curve including one autonomous rerun, versus vendor integration commonly measured in multiple weeks. Implication: - The useful abstraction is richer than read/write primitives: a physical-agent substrate increasingly resembles a state/procedure capability plane. - The integration-time result is partner evidence, not a cross-vendor benchmark. ### E13 — Anthropic robotics abstraction study, 2026-07-09 URL: https://www.anthropic.com/research/claude-plays-robotics Grade: Primary / adjacent robotics research. Supports: - Anthropic evaluates direct motor torque commands, generated Python controllers, model-supervised RL training, and high-level steering of pretrained robot policies. - The same model's capability changes substantially with the control abstraction. - High-level pretrained policies strongly outperform direct low-level model control on difficult embodiments. Implication: - Physical AI already contains multiple action representations and abstraction levels. - The key runtime problem is increasingly **which representation to use for which subtask**, not which single representation wins globally. ### E14 — Universal Robots Gen 7, 2026-09-14 URL: https://www.universal-robots.com/news-and-media/news-center/universal-robots-unveils-gen-7-new-platform-industrial-automation-physical-ai/ Grade: Primary / adjacent industrial platform signal. Supports: - UR positions Gen 7 as AI-ready, with modern software tools and connectivity intended to move AI-powered applications into industrial operations. Boundary: - Ecosystem-direction signal only; not evidence of production MHS conformance. Current LRI hypothesis, not an MHS claim: 1. Neural policy path: observations → VLA/policy → action chunk or motion token → fast controller. 2. Programmable Agent path: observations/state → Agent reasoning → explicit program/state machine/parameter strategy → fast controller/device procedure. 3. Likely hybrid: one Agent/Reasoner chooses or improves both explicit skills and learned policies, while a common hardware capability/safety layer constrains both. The key research question is not whether MHS replaces VLA. It is whether a Physical Agent Runtime benefits from treating **programs, learned policies, high-level procedures, and tightly bounded direct commands as first-class action representations** behind one device capability/state plane, with the Agent routing among them by task, uncertainty, latency, and safety requirements. ## Updated LRI thesis — Action Representation Router Current LRI systems hypothesis, not an announced MHS architecture: 1. **Capability plane:** devices expose discoverable states, procedures, limits, and evidence streams. 2. **Action representations:** subtasks may execute through learned policy, generated program/state machine, high-level device procedure, or tightly bounded direct command. 3. **Router:** the Agent/Reasoner selects or synthesizes the representation appropriate to the subtask. 4. **Fast execution:** local controllers, firmware, and safety systems remain below semantic reasoning. 5. **Learning loop:** traces and failures can improve programs, policies, routing rules, or device knowledge, while deployment remains gated and versioned. This synthesis is supported by the combination of MHS partner cases, Anthropic's robotics abstraction study, and current VLA/local-controller stacks. ## Derived architecture ### A. Slow path — Agent / frontier model Responsibilities: - goal interpretation - experiment planning - hypothesis generation - exceptional-failure interpretation - controller/program synthesis - high-level parameter strategy - deciding when to escalate to a human Properties: - probabilistic - relatively high latency - high semantic flexibility - should not own hard safety or per-tick timing ### B. Agent I/O — MCP / CLI Responsibilities: - discovery - inspection - one-shot commands - interactive debug - low-frequency orchestration Boundary: - protocol/transport is not a hard-real-time control guarantee. ### C. MHS driver Responsibilities: - vendor/device adaptation - standard primitives - physical/capability metadata - device discovery - enforceable device-level limits Open questions: - lease/ownership semantics - transaction semantics - concurrency - schema compatibility - offline behavior - E-stop standardization - audit requirements ### D. Fast path — deterministic code Responsibilities: - repeatable action sequence - conditional control - continuous sampling - bounded feedback logic - local optimization loops Key property: - can operate without asking the model to reason every step. ### E. Device/firmware/real-time controller Responsibilities: - servo loops - motor/sensor synchronization - PID and protection loops - strict timing - failsafe behavior Boundary: - public MHS material should not be read as replacing this layer. ## Hz-gap interpretation Illustrative engineering bands, not MHS guarantees: - Online frontier Agent reasoning: sub-Hz to a few Hz. - Task/parameter orchestration: a few to tens of Hz depending on stack. - Local deterministic programs: tens of Hz through kHz-class depending on device/API. - Firmware/servo loops: hundreds of Hz through multi-kHz depending on hardware. The important concept is not the exact number. The architectural move is to reduce the number of decisions that require online semantic reasoning and compile repeatable decisions into a faster deterministic path. ## Comparison matrix ### MHS vs MCP - MCP: generic agent/tool protocol. - MHS: hardware-facing semantics, driver model, physical metadata, device safety abstraction. - Relationship: MHS can be exposed through MCP. ### MHS vs vendor SDK - Vendor SDK: device-specific access. - MHS: normalizes Agent-facing access and can wrap vendor SDKs underneath. ### MHS vs ROS 2 / ros2_control - ROS 2: broad robotics middleware, node/message ecosystem, hardware/control frameworks. - MHS: Agent-facing hardware abstraction and semantic description. - Likely complementary; no evidence that MHS is intended to replace a robotics runtime or hard-real-time control framework. ### MHS vs VLA / robot policy - VLA/policy decides actions from observations/goals. - MHS standardizes how Agent/runtime sees and actuates equipment. - High-rate stability often still relies on a local controller. ### MHS vs deterministic script - Script alone is fast and inspectable but usually bespoke. - MHS tries to make the script portable across a common device abstraction. ## Safety hypotheses H1. Physical safety must be enforced below the model. H2. Generated fast-path code should have stricter admission than one-shot interactive tool calls because a bad script can execute errors faster and longer. H3. A production MHS ecosystem needs capability leases, interlocks, E-stop semantics, audit logs, limits, watchdogs, rollback, and driver/schema versioning. H4. Natural-language tags are valuable for tacit knowledge, but safety-critical fields should eventually have typed/machine-verifiable representations where possible. H5. Simulation/shadow execution should gate deployment of newly synthesized controllers. ## Required experiments ### E1 — Direct Agent vs code fast path Setup: - one sensor + one actuator, then a two-device chain - same task via per-step MCP calls and via generated local code Measure: - P50/P95/P99 latency - jitter - maximum stable control rate - network time - CPU/RSS - task success ### E2 — Safety fuzz Inject: - out-of-range writes - illegal transitions - stale sensor values - replayed commands - concurrency conflicts Measure: - unsafe-action block rate - false positive rate - E-stop latency - post-fault state consistency ### E3 — Controller synthesis Process: 1. start with a linear/manual baseline 2. let Agent explore under bounded disturbances 3. synthesize a deterministic controller 4. blind-test without Agent Measure: - blind success rate - recovery time - number of experiments required - controller complexity - regression rate across environment changes ### E4 — Failure recovery Cases: - device restart - transport disconnect - partial multi-device failure - Agent process crash - stale reference metadata Measure: - time to fail-safe - state reconstruction - recovery time - orphan command rate ### E5 — Integration cost Compare vendor-specific integration with an MHS-like driver: - engineer hours per device - driver LOC - duplicated logic - tests required - marginal cost of adding the N+1th device ### E6 — Sandboxed fast path Compare arbitrary Python with a constrained portable runtime (for example Wasm/DSL): - startup - RSS - throughput - permission granularity - deterministic replay - portability - static validation potential This is an LRI research hypothesis, not a current MHS requirement. ## Watch list P0: - public MHS specification - reference driver implementation - license - conformance suite - driver/package versioning - exact safety-limit schema - lease/ownership and concurrency semantics - emergency-stop behavior - disconnection/fail-safe rules P1: - LeRobot native integration - Raspberry Pi driver availability - equipment-vendor adoption - third-party production case studies - independent cross-vendor interoperability tests - long-running autonomous-lab reliability ## Current conclusion Evidence status: - public architecture/design: strong primary evidence - partner-case effectiveness: strong case evidence, but not general benchmark - high-Hz architecture interpretation: strong systems inference, especially supported by QuEra - hard-real-time / industrial safety readiness: unproven - ecosystem maturity: early preview The most important insight is that Physical AI may scale not by keeping a frontier model continuously in every control loop, but by using the model to create, validate, and upgrade deterministic control programs that run much faster and with much tighter operational boundaries.