Software agents taught enterprises to standardise tool calls. Physical agents raise the stakes: the tool can move, heat, cut, dose, measure or damage something real.
Anthropic’s August 2026 research preview of the Model Hardware Standard (MHS) proposes a shared specification for AI agents to operate scientific and manufacturing devices such as microscopes, liquid handlers and robotic arms.
Whether MHS itself becomes widely adopted remains to be seen. The architectural problem it targets is already important: physical equipment is fragmented, integration is expensive, and an AI agent needs a safe machine-readable way to discover and control capabilities.
This is where “tool use” stops being metaphorical.
A device API is not enough
Industrial systems already have APIs, field buses and automation protocols. An agent interface needs additional semantics.
The system must know:
- what the device can do;
- current state;
- operating range;
- units;
- calibration status;
- required preconditions;
- mutually exclusive operations;
- safety interlocks;
- whether the action is reversible;
- how long it can take;
- what evidence proves completion.
A generic command such as set_parameter(8) is dangerous without a shared understanding of parameter, unit, acceptable range and machine state.
The contract must be richer than connectivity.
Physical state makes stale context dangerous
Software can often retry after an error. Physical processes may have changed irreversibly.
Between two agent steps:
- a sample may have moved;
- temperature may have changed;
- a robot may no longer be in home position;
- another operator may have taken control;
- calibration may have expired;
- a safety door may have opened.
The agent should not act from an old observation as though the world were static.
Physical tool contracts therefore need freshness and state validation before execution.
Safety must sit below model reasoning
A model should never be the only layer preventing an unsafe command.
Hard safety limits belong in deterministic infrastructure:
- device firmware;
- programmable controllers;
- policy services;
- interlocks;
- physical constraints;
- emergency stops.
The agent can reason about the goal and propose sequences. The system should still refuse actions outside engineered envelopes.
This separation is essential: reasoning can be probabilistic; safety boundaries cannot.
Simulators become part of evaluation
Before an agent controls expensive or dangerous hardware, organisations need realistic evaluation environments.
A useful programme includes:
- digital twins or simulators;
- recorded trajectories;
- fault injection;
- hardware-in-the-loop tests;
- adversarial instructions;
- latency and network-loss scenarios;
- human takeover drills.
Success should not be defined only as completing the experiment. It should include no unsafe intermediate state and correct recovery when reality diverges from plan.
Identity and custody matter
Physical AI also introduces operational accountability.
The trace should answer:
- who authorised the run;
- which agent version operated;
- which device and serial number;
- calibration state;
- model and policy version;
- exact commands;
- sensor observations;
- manual interventions;
- resulting artefacts.
In regulated manufacturing or science, this record may be as important as the output itself.
MHS, MCP and A2A solve different boundaries
A useful conceptual stack could become:
- MHS-like contract: agent ↔ physical device;
- MCP: agent ↔ software tools/data;
- A2A: agent ↔ agent.
Those protocols need not collapse into one standard. What matters is consistent identity, policy and evidence across the transitions.
The Lexdatum view
Physical AI will not scale safely through bespoke Python wrappers around every instrument.
It needs device contracts that make capability, state and safety legible to machines while keeping deterministic controls below model reasoning.
The more autonomy moves into the physical world, the more boring infrastructure becomes strategic.
That is a feature, not a limitation.
Sources
- Anthropic — Previewing the Model Hardware Standard (2026-08-27)
Research note: This analysis is based on public information available on 1 September 2026. Product capabilities, prices and regulatory interpretations can change. Vendor-reported claims are identified as such. This is not legal, security, financial or investment advice.