How do I let an AI agent control physical hardware safely?

Put the safety envelope in the device layer, never in the prompt. The device or its wrapper should declare hard limits — speed, force, angle, temperature, volume — and reject any request that violates them regardless of what the agent asks for. A prompt instruction is a suggestion; a rejected command is a guarantee, and only the second one holds when the model behaves unexpectedly.

Can I use MCP to control hardware?

Yes, and many teams do by wrapping device commands as MCP tools. The gap is that MCP has no native concept of a physical safety envelope, so limits live in your wrapper code or system prompt. Anthropic's Model Hardware Standard, announced August 27 2026 as a research preview, exists to close that gap by having the device itself declare its capabilities, measurements, settings and safety limits.

What is the biggest mistake when connecting agents to hardware?

Treating it as a software integration problem. A software agent that misreads an API returns a bad result you can retry; a hardware agent that misreads a device damages equipment or injures someone. The design consequence is that every action needs a dry-run path, an independent physical interlock, and a bounded blast radius before an agent is allowed to issue it.

Should I wait for MHS before building hardware agents?

No, but design as if it is coming. MHS is a waitlisted research preview with no open-source date as of August 2026, so you cannot depend on it yet. Build your own capability-and-limits schema now with the same shape — device-declared operations, measurements, settings and safety envelope — and migration later becomes a translation rather than a rewrite.

Quick Answer

How to Connect AI Agents to Hardware: 2026 Guide

Published: August 28, 2026

The Short Answer

The whole problem reduces to one rule:

The safety limit belongs in the device, not in the prompt.

A system prompt saying “never move the arm faster than 0.5 m/s” is a suggestion that holds until the model behaves unexpectedly. A device layer that rejects any command above 0.5 m/s holds regardless of what the model does.

Everything else in this guide is engineering around that single principle.

Step 1 — Write the Capability Description First

Before any agent touches anything, produce a machine-readable description of the device covering four things:

Layer	Declares	Example
Capabilities	operations it can perform	`move_to(x,y,z)`, `dispense(volume)`
Measurements	what it senses and reports	position, temperature, pressure
Settings	adjustable parameters + ranges	speed 0.05-0.5 m/s
Safety envelope	hard limits, non-negotiable	max force, forbidden angles, max temp

This is exactly the shape Anthropic’s Model Hardware Standard, announced August 27, 2026, standardises. Its worked example: a robot arm vendor specifies how AI may safely manipulate a heavy arm by limiting the speed or angles through which it moves — the vendor who understands the machine owns the constraint.

Write this even if you never adopt MHS. The document is the design.

Completion criterion: someone who has never seen the device can list every legal operation and every hard limit from your description alone, without the manual.

Step 2 — Enforce Limits Below the Agent

Layer your stack so violations are structurally impossible, not merely discouraged:

Agent (may ask for anything)
  ↓
Capability layer  ← validates against declared envelope, REJECTS violations
  ↓
Device driver / ROS 2 / firmware  ← executes
  ↓
Physical interlock  ← independent of all software above

Three rules:

The validator is not the agent’s tool. It sits between the tool and the device, and the agent cannot disable, reconfigure or reason its way past it.
Rejections are informative. Return why the command was refused so the agent can correct rather than retry blindly.
There is a physical interlock. Emergency stop, torque limiter, thermal cutout — something that works when every layer of software is wrong. This is non-negotiable for anything with mass, heat or pressure.

Completion criterion: you can demonstrate a command that violates a limit being rejected, and a physical stop working with the control software killed.

Step 3 — Make Everything Dry-Runnable

Every operation needs a simulation path that returns what would happen without doing it.

The agent’s default loop should be: plan → dry run → review → execute. For anything irreversible, insert human approval between review and execute.

This matters more with hardware than software for an asymmetric reason: software actions are usually reversible and hardware actions usually are not. A bad API call is retried. A bad pipetting sequence destroys a sample that took three weeks to prepare.

Completion criterion: every capability in your description has a dry-run mode, and the agent uses it by default.

Step 4 — Bound the Blast Radius

Ask, per capability: what is the worst outcome if this fires with completely wrong parameters?

Worst case	Required control
Wasted consumable	log it, move on
Destroyed sample	dry run + human approval
Damaged equipment	hard limits + approval + interlock
Injury risk	interlock + physical guarding + no autonomous execution

Autonomy is earned per capability, not granted per system. A lab agent may reasonably read every instrument autonomously while requiring approval to actuate any of them.

Completion criterion: every capability has a written worst case and a matching control level.

Step 5 — Close the Loop with Measurements

An agent that issues commands without reading results is running open-loop, and open-loop hardware control fails silently.

After every action: read the measurements, compare to expectation, stop on mismatch. Do not let the agent proceed to step four of a protocol when step three reported something outside its expected range. Halting and reporting is nearly always the right default — the cost of an unnecessary stop is minutes, and the cost of continuing on a bad state can be the entire run.

This is where the measurements layer of your capability description earns its place: it is what makes verification possible at all.

Completion criterion: each action has a defined expected measurement range and an explicit stop-on-mismatch behaviour.

Step 6 — Log for Reconstruction

Physical operations need audit trails that software ones can get away without. Log, per action: the agent’s intent, the exact command, the validator’s decision, the device response, the measurements before and after, and timestamps.

When something goes wrong — and with novel technology driving physical equipment, something will — you need to reconstruct whether the model reasoned badly, the description was wrong, or the device misbehaved. Those three failures have completely different fixes.

Completion criterion: you can replay any past run from logs and identify which layer failed.

What MHS Changes, and What It Does Not

Anthropic’s Model Hardware Standard is a research preview as of August 28, 2026 — waitlisted, limited to selected scientific, robotics and manufacturing organisations. Early testers include AWS, Danaher, Hugging Face and Raspberry Pi. Anthropic intends to open-source it after the preview with safety evaluations and deployment guidance, but has not committed to a timeline.

What it changes: the capability description becomes standard and vendor-published rather than something you reverse-engineer from a PDF per device. In a lab with hundreds of instruments, that is the difference between an impossible project and a tractable one.

What it does not change: every step above. MHS describes and constrains; it does not dry-run for you, bound your blast radius, close your loop or log your runs. It is a better foundation, not a finished safety system.

Practical stance: build your own schema now with the same four layers. If MHS opens and your device vendors adopt it, migration is a translation. If it does not, you still have the right design.