If an AI agent is going to move a robot arm, tune a laser, or pipette chemicals, telling the model to be careful is not a safety system.
On August 27, Anthropic opened a research preview of the Model Hardware Standard (MHS), a model-agnostic interface for letting AI agents discover, monitor, and operate programmable physical equipment. The eye-catching part is Claude controlling microscopes, liquid handlers, robotic arms, and quantum-computing hardware. The more important part is the architecture between Claude and the machine.
MHS gives developers somewhere to put hard limits that do not depend on the model making a good decision. Anthropic’s early tests include device-level safety limits, checks that block invalid states before movement, active emergency-stop handling, coordination rules between machines, and deterministic scripts for operations that should not depend on continuous LLM reasoning.
That separation is likely to matter far more than whether Claude itself becomes better at robotics. A model can propose an action, interpret a measurement, and adapt a plan. Software and hardware underneath it can still decide whether the proposed action is allowed to become motion.
More on physical AI:
Key takeaways
MHS is an early research preview, not a generally available open-source standard yet. The official MHS site says access remains application-based while partners work on safety evaluations and best practices ahead of an open-source release.
The model does not have to be the final authority. MHS drivers describe what devices can do, expose their state, and define device-level safety limits that the agent must operate within.
Anthropic is already moving repeatable physical operations out of the model’s reasoning loop. Claude can learn a procedure, turn it into deterministic code, and invoke that code instead of reasoning through every movement in real time.
Claude can still make surprisingly basic physical mistakes. In a Genentech test, it reacted to a foaming problem by retrying the operation in a way that created even more bubbles. Human experts had to explain the physical cause before the system corrected its approach.
The safest architecture treats model reasoning as untrusted input. Let the model propose actions and interpret results. Let deterministic software and hardware protections decide whether those actions are actually allowed to reach the machine.
MCP connected AI agents to software. MHS extends the idea to machines
Anthropic introduced the Model Context Protocol in November 2024 as an open standard for connecting AI systems with data sources and software tools. Instead of building a bespoke integration every time a model needs access to a database, repository, business tool, or service, developers can expose those resources through a common interface.
MHS attacks a similar integration problem in the physical world.
Labs and factories are full of equipment with incompatible control systems. One machine might expose a modern API. Another might rely on a vendor SDK. Another may depend on an older Windows COM interface. A different instrument may expose no normal programmatic interface at all and still require interaction through a graphical user interface.
Anthropic says MHS wraps these systems in standardized drivers. The drivers expose simple operations such as reading a temperature or setting one, while also describing the states and procedures available on the machine. They can record physical information that software alone may not reveal, including details such as a robot arm’s weight or an instrument’s operating limits. That physical context matters because a model that understands a command syntactically may still lack the information needed to use the device safely.
The resulting hardware interface can be reached through MCP, a command-line interface, or code. The agent operates at the orchestration layer instead of having to understand every vendor-specific control system underneath it. The device keeps its own firmware, controller, sensors, vendor software, and physical constraints.
That makes MHS quite different from another robot brain. Popular AI previously looked at Alibaba’s open-weight embodied model in RynnBrain: Alibaba open-sources a “robot brain” for embodied AI. RynnBrain is about giving robots a model designed to perceive, reason, ground language in physical space, and support tasks such as localization and planning. MHS is the plumbing between an agent and programmable equipment.
Anthropic also describes MHS as model-agnostic. That distinction could become extremely useful. A lab could standardize how equipment is exposed to an agent without making the equipment interface depend on whichever model happens to be best this year.
What the Model Hardware Standard actually standardizes
The basic architecture separates three things that are easy to blur together in an impressive AI demo.
First comes the model. It can interpret a goal, inspect measurements, troubleshoot a situation, choose between procedures, and decide what should happen next. This is the flexible part of the system, and flexibility is exactly what makes it useful when conditions are messy or unexpected.
Then comes the MHS driver. It translates between the agent and the machine while describing what that machine can measure, what can be adjusted, what states it can occupy, and which safety limits should be enforced. Anthropic’s description says the driver can generate a reference file covering device characteristics, adjustable parameters, measurable values, and enforced limits.
Finally comes the physical equipment itself, with its own firmware, controllers, sensors, emergency stops, vendor software, mechanical limits, and other protections.
This separation lets a developer decide that the model may choose a laser setting without giving the model permission to choose any conceivable laser setting. The model can still reason over options, but its authority stops at a boundary defined outside the model.
At HHMI Janelia, a researcher using MHS for microscopy said device-level limits prevented an agent from accidentally using excessive laser power, which could bleach fluorescent molecules and degrade a sample. Claude can still suggest a bad value. Device-level enforcement keeps that suggestion from automatically becoming a physical command.
That is the right direction for physical AI.
A probabilistic model can make suggestions. A deterministic control layer can enforce the envelope within which those suggestions are allowed to become physical actions. The model can remain powerful and adaptive without being trusted as the only safety mechanism.
The smartest part may be where Claude stops reasoning
Anthropic’s preview contains another architectural choice that deserves more attention.
While experimenting with laser alignment, Claude adjusted the system, observed the result with a camera, and repeated the process while working out how the hardware behaved. Once it had learned a successful procedure, Claude wrote a deterministic script that could reproduce the alignment without reasoning through every individual step again.
This is a much more sensible use of an LLM than asking it to improvise every motor command forever.
Models are useful when conditions are ambiguous. They can interpret measurements, diagnose an unfamiliar failure, plan experiments, select among known procedures, or decide which branch of a workflow makes sense under changing conditions. Those are reasoning problems.
Once a physical sequence becomes understood and repeatable, ordinary software is often the safer executor. It is easier to inspect, easier to test, and less likely to reinterpret a familiar procedure differently on the next run.
This also mirrors the broader transition Popular AI covered in AI agents become platforms in 2026: how to avoid lock-in. The difficult problem in serious agent systems is increasingly the infrastructure around the model: durable state, execution environments, retries, scheduling, permissions, observation, and boundaries.
Physical machines make those boundaries impossible to ignore. A bad text response is annoying. A bad motor command can damage equipment, ruin a sample, interrupt an experiment, or create a condition that the model does not understand well enough to diagnose.
The safest use of model intelligence may therefore be selective. Let the model reason when reasoning is valuable. When it discovers a stable procedure, move that procedure into deterministic execution and make the model call it as a known operation.
More on AI agent platforms:
Anthropic’s failures make the case better than its successes
One of the strongest arguments for this architecture comes from a test in which Claude behaved badly.
Genentech used MHS to connect Claude to a liquid handler, robotic arm, and plate reader for a protein assay. Different liquids require different pipetting behavior because viscosity, bubbles, pressure, and flow rates affect how accurately liquid can be moved.
Claude initially used generic parameters for both water and a viscous protein solution. That caused bubbles in the viscous sample and produced inaccurate transfers. The model later optimized its parameters, but another problem exposed a deeper limitation.
When bubbles caused runtime errors, Claude tried changing parameters and repeating the same operation in the same well.
That made the problem worse.
The repeated mixing agitated the liquid and created more bubbles because Claude was treating the symptom like a software failure instead of understanding the physical process in the well. Researchers had to explain the cause and tell it to move to a clean well and use gentler mixing. Claude then retained that context for the rest of the run, and the team encoded the lesson into reusable liquid-handling skills.
Anthropic’s own report describes how Claude’s retries created more bubbles until researchers explained the underlying physical failure.
This is exactly why physical AI needs an architecture designed around fallible reasoning.
A model can have impressive general reasoning ability and still miss something obvious to an experienced lab technician. Larger or more capable models may reduce these failures, but probabilistic inference still should not be treated as a safety interlock.
The right system assumes that the model will sometimes misunderstand the world. It then limits how much damage that misunderstanding can cause before a deterministic check, hardware safeguard, or human approval stops it.
The guardrails are already doing real work
Other MHS demonstrations show what happens when state checks live below the agent.
At Carnegie Mellon University, researchers connected a liquid handler, plate reader, robotic arm, and cameras spread across three computers using fundamentally incompatible interfaces. They reported that MHS let them build the drivers and orchestration layer in about eight hours, compared with the several weeks they said a vendor-built setup normally takes.
That figure is a partner-reported proof-of-concept result, not an independent benchmark. Still, the safety test around the same setup is more revealing than the integration-speed claim.
The team deliberately created six unsafe or invalid conditions: a missing plate, a rotated plate, a busy reader, a disconnected camera, an unreachable device, and an active emergency stop. According to Anthropic’s published project description, all six conditions were blocked before any device moved.
Another experiment coordinated a robot arm with a liquid handler so neither device would move into the other’s workspace at the wrong moment. Across repeated tests described in the preview, the arm waited until dispensing had finished and the liquid handler waited until the arm had cleared the plate.
These are less cinematic than a robot taking instructions from Claude, but they are closer to the engineering problem that matters. The system needs a trustworthy representation of state, and it needs to prevent motion when that state does not satisfy the rules for motion.
At QuEra, Claude sometimes failed in the opposite direction and became too cautious. The agent would stop and wait for human approval before actions it considered even slightly risky, occasionally leaving experiments paused overnight. QuEra also found that Claude could struggle with failures rooted in the physical hardware because its understanding of the rig remained more programmatic than physical.
That is inconvenient, especially in a workflow designed to run unattended. It is still a better failure mode than an agent confidently improvising around expensive and fragile equipment.
The preview therefore shows two sides of the same problem. A model can act too aggressively because it misunderstands a physical cause, or too cautiously because it does not understand the physical system well enough to proceed. In both cases, the surrounding control architecture matters as much as the model’s reasoning quality.
The deterministic gate should have the final vote
Independent robotics builders are converging on a similar pattern.
In March, a developer posted an open-source hardware-control architecture to Reddit’s r/AskRobotics built around the question of how an LLM can reason about physical hardware without receiving direct execution authority.
The proposed design treats the LLM as an untrusted reasoning layer. Its requested actions pass through deterministic checks for valid tools, emergency-stop state, conflicting queued actions, expired commands, operator approval, and state changes between validation and execution. The post explicitly describes a pipeline with a deadline check for stale proposals and a time-of-check/time-of-use precheck that revalidates state immediately before dispatch. That independent architecture puts six deterministic gates between the model proposal and execution.
That Reddit project is not evidence that MHS implements all of those protections. Anthropic’s public MHS description does not specify a universal stale-command rejection mechanism or a universal time-of-check/time-of-use rule. The example matters because it shows another builder arriving at the same architectural concern from a different direction.
Likewise, a recent Codex-controlled robot-arm project drew more than 1,300 Reddit votes after its builder used Codex to prepare and execute a 256-stroke drawing. The interesting engineering details were below the video. The builder said the routes were preplanned, forward-kinematics checks were performed before motion, the planner stayed on a known-safe joint branch, and shutdown checks were part of the system. The robot-arm project paired Codex with preplanned motion and safety checks.
The flashy part was an AI drawing with a robot arm.
The serious engineering was everything that prevented the model’s creativity from extending to the laws of motion.
What an AI-to-hardware safety stack should look like
MHS is useful because it offers a standard place to build boundaries between model reasoning and physical execution. The public preview already demonstrates several of those boundaries. Others will need to mature as the specification, implementations, and safety evaluations develop.
A sensible architecture keeps five responsibilities separate:
The model reasons. It analyzes measurements, identifies goals, proposes actions, and handles unusual situations. Its output should be treated as a proposal, not as unquestionable authority.
The control layer validates. Commands are checked against device capabilities, operating state, limits, interlocks, and authorization requirements before they can become physical action.
Deterministic software executes known procedures. Once a sequence is understood, tested, and repeatable, it should not require an LLM to reinvent every movement on every run.
Hardware protections remain authoritative. Emergency stops, firmware protections, safety-rated controllers, mechanical stops, and other machine-level safeguards should remain in force even when an AI agent sits above them.
Humans remain available for high-risk or genuinely novel decisions. The right approval boundary will vary enormously between moving an empty microplate and changing a potentially destructive machine parameter.
Popular AI’s coverage of the Friendly Fire exploit affecting Claude Code and Codex showed the same principle in software. Once an agent can turn text into actions, permissions, containment, human approval, and execution boundaries become more important than whether the model usually behaves sensibly.
Physical AI raises the cost of getting that wrong because the model’s output can cross from software into motion, heat, pressure, light, fluid transfer, or other real-world effects.
The central design question is whether the system can prove that a plausible model-generated command is valid for the current machine state before anything moves.
More on AI-to-hardware safety:
MHS still has a major test ahead: becoming a real standard
Anthropic has enough partners to make MHS worth watching.
The preview names work involving Genentech, Carnegie Mellon University, HHMI Janelia, QuEra, and Tetsuwan. It also describes companies including AWS, Automata, Doosan Robotics, QIAGEN, and Tecan developing or testing MHS support, while Hugging Face is adding MHS support to LeRobot and Raspberry Pi is working on integrations for its hardware.
That is a meaningful starting group, but announced support is not the same as a mature ecosystem.
MHS remains behind an application-based research preview. Public documentation describes the architecture and demonstrations, but developers cannot yet treat it like a finished open standard with years of interoperability testing behind it. Reuters independently confirmed the August 27 research preview and Anthropic’s plan to make MHS open source after the initial safety-evaluation period.
That makes the eventual open-source release important.
A hardware standard becomes much more useful if the model, agent framework, and hardware vendor remain replaceable. If the open release preserves the model-agnostic property Anthropic describes and attracts broad vendor support, labs could potentially standardize their equipment interfaces without standardizing on Claude.
That would be healthier than turning Claude into another proprietary controller that every machine has to depend on. The value of MHS would then come from interoperability and enforceable boundaries, not from requiring one model vendor at the center of every workflow.
There is also a practical test ahead. A standard that works across proof-of-concept lab setups must still survive messy fleets of old instruments, partial APIs, vendor quirks, long-running experiments, degraded sensors, network failures, and operational procedures built up over years. The research preview is a chance to discover which parts of the proposed abstraction hold up when those edge cases become routine.
Who should care about Anthropic MHS now?
Most ordinary Claude users cannot do anything useful with MHS today. It is a limited research preview aimed at scientific labs, robotics companies, manufacturers, hardware developers, and other organizations working with programmable physical equipment.
Robotics builders and developers working on physical agents should pay attention to the architecture now, even if they never adopt MHS.
The lesson does not depend on one standard.
Do not give a language model unrestricted execution authority because it produced a plausible JSON object. Represent machine state explicitly. Put non-negotiable limits below the model. Require approval where the consequences justify it. Keep safety checks deterministic. Turn stable procedures into ordinary software. Preserve a hardware-level stop mechanism that the AI cannot override through argument or reinterpretation.
Then let the model do what it is genuinely useful for: interpreting messy situations, adapting plans, coordinating tools, and finding useful actions inside those boundaries.
This division of labor also gives teams a better debugging model. When something goes wrong, they can ask whether the failure came from reasoning, validation, execution, device state, or hardware. Collapsing all of those layers into “the AI did it” makes both safety analysis and engineering much harder.
A standard interface can help because it gives each layer a clearer place in the system. That does not guarantee safety by itself. It does make it easier to decide where safety rules belong and which rules should never depend on the model agreeing with them.
Why the Anthropic Model Hardware Standard matters for physical AI safety
Anthropic’s Model Hardware Standard is interesting because Claude can control microscopes, liquid handlers, robotic arms, and lasers. Its more important contribution may be defining where Claude’s authority ends.
Anthropic’s own experiments show why. Claude can optimize an experiment, recover from some errors, coordinate several machines, and turn learned behavior into reusable code. It can also misunderstand basic physical causes, make a bad situation worse, or stop because it lacks enough physical understanding to proceed confidently.
A physical AI system should assume that all of those versions of the model will eventually show up.
That means safety cannot depend on the hope that the next model generation will reason correctly every time. Model capability can improve, but the architecture still needs a layer that checks state, enforces limits, preserves emergency stops, and executes stable procedures deterministically.
MHS gives developers a possible place to encode that division of authority. The model can decide what it wants to do. Deterministic systems decide what the machine is allowed to do.
If MHS becomes a broadly adopted open standard, that separation could matter more than any single Claude robotics demo. It would give labs and hardware builders a shared way to expose machines to AI agents without making model judgment the final safety boundary.
That is the architecture worth standardizing.
Explore more from Popular AI:
Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast
Would you trust an AI agent to control physical hardware autonomously? Where would you draw the line?