Anthropic Model Hardware Standard Deep Dive: AI Agents Finally Operate Real Devices — Weeks of Integration Compressed to Hours, Unified Drivers for Microscopes/Robotic Arms/Liquid Handlers
Introduction: A Milestone in AI’s Journey from Digital to Physical
On August 27, 2026, Anthropic, in collaboration with the HHMI Janelia Research Campus, unveiled the Model Hardware Standard (MHS) research preview — a shared specification designed for AI agents to safely operate physical devices. This marks a pivotal step in AI’s transition from the “purely digital world” to “physical world operation.”
Until now, the capability boundaries of AI agents were largely confined to digital domains: browser operations (Claude in Chrome), desktop automation (Computer Use), and software development tools (Claude Code). With MHS, AI agents can now directly operate microscopes, liquid handlers, and robotic arms — real physical devices that no longer require human experts to write custom integration code. Agents can control them “plug-and-play” through a unified standard protocol, compressing what traditionally took weeks or even months of integration work down to hours or even minutes.
Source: Anthropic Official Blog - Previewing the Model Hardware Standard
MHS Architecture Overview: Unified Drivers, Layered Decoupling
The core design philosophy of MHS is layered decoupling — abstracting the heterogeneity of physical devices layer by layer, ultimately presenting a unified control interface to AI agents. The overall architecture can be abstracted into the following four layers:
┌─────────────────────────────────────────────────────────────┐
│ AI Agent Layer (Claude / Any Model) │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ MCP Protocol │ CLI │ Code Files (API) │ │
│ └──────────┬───────────┬───────────────────────┬───────┘ │
└─────────────┼───────────┼───────────────────────┼──────────┘
│ │ │
┌─────────────┴───────────┴───────────────────────┴──────────┐
│ MHS Core Layer │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ MHS State Dictionary │ │
│ │ Shared memory data exchange layer, R/W by all devices│ │
│ └──────────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Safety Constraints Layer │ │
│ │ Device-level safety boundaries ─ Physical limits │ │
│ │ ─ Permission control │ │
│ └──────────────────────────────────────────────────────┘ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Device Discovery Layer │ │
│ │ mDNS/Zeroconf auto-discovery ─ Registration ─ Query │ │
│ └──────────────────────────────────────────────────────┘ │
└───────────────────────────┬────────────────────────────────┘
│
┌───────────────────────────┴────────────────────────────────┐
│ Unified Driver Layer │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Microscope │ │Liquid Handler│ │ Robotic Arm │ │
│ │ (MHS Driver) │ │ (MHS Driver) │ │ (MHS Driver) │ │
│ │ │ │ │ │ │ │
│ │ read/write │ │ read/write │ │ read/write │ │
│ │ discover │ │ discover │ │ discover │ │
│ │ safety_tags │ │ safety_tags │ │ safety_tags │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
└─────────┼─────────────────┼─────────────────┼──────────────┘
│ │ │
┌─────────┴─────────────────┴─────────────────┴──────────────┐
│ Physical Device Layer │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Microscope│ │Liquid │ │Robotic │ │
│ │(Zeiss/ │ │Handler │ │Arm │ │
│ │ Olympus) │ │(Tecan/ │ │(UR/ │ │
│ │ │ │ CyBio) │ │ Doosan) │ │
│ └──────────┘ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────┘
Figure 1: MHS Layered Architecture — From physical devices at the bottom to AI agents at the top, MHS achieves cross-vendor, cross-protocol unified device control through the Unified Driver Layer, Device Discovery Layer, Safety Constraints Layer, and State Dictionary.
The Unified Driver Layer: MHS’s Core Innovation
MHS’s most significant contribution is the Standardized Driver. In traditional labs, each device has its own unique programming interface, communication protocol, and operation language. Microscopes run in MATLAB, cameras in Python, electrophysiology equipment in C# — they share no common interface and cannot communicate directly.
MHS drivers solve this problem through the following approaches:
1. Basic Primitives
MHS drivers use a minimal set of instruction primitives — “read” and “write” — that any hardware device can understand and execute.
┌─────────────────────────────────────────────────────────────┐
│ MHS Driver Interface Definition │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ interface MHSDriver { │ │
│ │ // Read device state/parameters │ │
│ │ read<T>(path: string): Promise<T> │ │
│ │ │ │
│ │ // Write device parameters/execute commands │ │
│ │ write<T>(path: string, value: T): Promise<void> │ │
│ │ │ │
│ │ // Device discovery information │ │
│ │ discover(): DeviceInfo │ │
│ │ │ │
│ │ // Device metadata (including safety tags) │ │
│ │ getMetadata(): DeviceMetadata │ │
│ │ } │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Figure 2: MHS Driver Core Interface — Any device only needs to implement four basic methods (read/write/discover/getMetadata) to join the MHS ecosystem.
2. Device Metadata and Natural Language Tags
Another major innovation of MHS drivers is Natural Language Tags. Information from traditional device manuals — such as a robotic arm’s weight, a microscope’s maximum laser power, or a liquid handler’s pipetting precision — usually exists in paper manuals, on a user’s computer, or as tacit knowledge. MHS drivers allow users to write this information directly into driver tags in natural language, and the driver automatically generates a Reference File describing the device’s general characteristics, measurable quantities, adjustable parameters, and safety limits.
Here’s a Python implementation example of an MHS driver:
"""
MHS Driver - Robotic Arm Device Driver Implementation Example
"""
from dataclasses import dataclass, field
from typing import Dict, Any, Optional, Callable, Awaitable
import asyncio
import json
@dataclass
class DeviceInfo:
"""Basic device information"""
device_id: str
device_name: str
vendor: str
model: str
protocol: str
endpoint: str
supported_primitives: list[str]
@dataclass
class SafetyLimit:
"""Safety limit definition"""
parameter: str
min_value: float
max_value: float
unit: str
description: str
@dataclass
class DeviceMetadata:
"""Device metadata (with natural language tags)"""
general_description: str
what_it_can_measure: list[str]
what_can_be_adjusted: list[str]
safety_limits: list[SafetyLimit]
weight: float
dimensions: Dict[str, float]
tags: Dict[str, str] = field(default_factory=dict)
class MHSDriver:
"""
MHS Standard Driver Base Class
All physical device drivers must inherit from this class
and implement the core methods
"""
def __init__(self, device_info: DeviceInfo, metadata: DeviceMetadata):
self._device_info = device_info
self._metadata = metadata
self._state: Dict[str, Any] = {}
self._connection = None
async def read(self, path: str) -> Any:
"""
Read device parameter or state
Args:
path: Read path, e.g., "temperature/stage", "position/x"
Returns:
The read value or state
"""
if not self._validate_read_path(path):
raise ValueError(f"Invalid read path: {path}")
return await self._do_read(path)
async def write(self, path: str, value: Any) -> None:
"""
Write device parameter or execute command
Args:
path: Write path, e.g., "speed/move", "laser/power"
value: The value to write
"""
self._enforce_safety_limits(path, value)
if not self._validate_physical_constraints(path, value):
raise ValueError(
f"Physical constraint violation: {path}={value}"
)
await self._do_write(path, value)
self._state[path] = value
def discover(self) -> DeviceInfo:
"""Return device discovery information"""
return self._device_info
def get_metadata(self) -> DeviceMetadata:
"""Return device metadata"""
return self._metadata
async def _do_read(self, path: str) -> Any:
"""Subclass implementation: actual hardware read logic"""
raise NotImplementedError
async def _do_write(self, path: str, value: Any) -> None:
"""Subclass implementation: actual hardware write logic"""
raise NotImplementedError
def _validate_read_path(self, path: str) -> bool:
"""Validate the read path"""
return True
def _enforce_safety_limits(self, path: str, value: Any) -> None:
"""
Enforce safety constraints
Check if the operation value is within the device's safe range
"""
param_name = path.split("/")[-1]
for limit in self._metadata.safety_limits:
if limit.parameter == param_name:
if not (limit.min_value <= value <= limit.max_value):
raise SafetyViolationError(
f"Safety limit exceeded for {param_name}: "
f"{value} not in [{limit.min_value}, {limit.max_value}] {limit.unit}"
)
def _validate_physical_constraints(self, path: str, value: Any) -> bool:
"""
Validate physical constraints
Check if the operation violates physical laws
"""
return True
class SafetyViolationError(Exception):
"""Safety constraint violation exception"""
pass
3. Device Discovery and Auto-Registration
MHS implements automatic device discovery over the network. When an MHS-compatible device connects to the network, it broadcasts its presence via the mDNS/Zeroconf protocol, and the MHS state dictionary automatically registers the device. The AI agent can discover and operate it without any manual configuration.
"""
MHS Device Discovery Module - mDNS-based Auto-Discovery
"""
import asyncio
import socket
from typing import Dict, Callable, Awaitable
class MHSDeviceDiscovery:
"""
MHS Device Discovery Service
Implements automatic discovery of devices on the LAN using mDNS/Zeroconf
"""
def __init__(self):
self._registry: Dict[str, MHSDriver] = {}
self._discovery_handlers: list[Callable] = []
async def start_discovery(self):
"""
Start the device discovery service
Listen for MHS device broadcasts and auto-register discovered devices
"""
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_TTL, 2)
mhs_group = "224.0.0.251"
sock.bind(("", 5353))
print(f"[MHS Discovery] Service started, listening on multicast group {mhs_group}")
while True:
data, addr = sock.recvfrom(1024)
device_info = self._parse_discovery_packet(data, addr)
if device_info:
await self._register_device(device_info)
def _parse_discovery_packet(self, data: bytes, addr: tuple) -> DeviceInfo:
"""Parse device discovery broadcast packet"""
try:
payload = json.loads(data.decode("utf-8"))
return DeviceInfo(
device_id=payload["device_id"],
device_name=payload["device_name"],
vendor=payload["vendor"],
model=payload["model"],
protocol=payload["protocol"],
endpoint=f"{addr[0]}:{payload.get('port', 5000)}",
supported_primitives=payload.get("primitives", ["read", "write"])
)
except (json.JSONDecodeError, KeyError) as e:
print(f"[MHS Discovery] Failed to parse discovery packet: {e}")
return None
async def _register_device(self, device_info: DeviceInfo):
"""Register a discovered device into the MHS ecosystem"""
if device_info.device_id not in self._registry:
print(
f"[MHS Discovery] New device found: "
f"{device_info.vendor} {device_info.model} "
f"({device_info.device_name}) @ {device_info.endpoint}"
)
for handler in self._discovery_handlers:
await handler(device_info)
def on_device_discovered(self, handler: Callable[[DeviceInfo], Awaitable[None]]):
"""Register a device discovery callback"""
self._discovery_handlers.append(handler)
def get_device(self, device_id: str) -> Optional[MHSDriver]:
"""Get a registered device driver by device ID"""
return self._registry.get(device_id)
def list_devices(self) -> list[DeviceInfo]:
"""List all discovered devices"""
return [driver.discover() for driver in self._registry.values()]
Safety Constraints Layer: The Lifeline for Physical World Operations
When AI agents operate physical devices, safety is the most critical concern. A single wrong parameter could cause a microscope lens to crash into a sample, a robotic arm to damage surrounding equipment, or excessive laser power to destroy a specimen. MHS implements a multi-layered safety mechanism:
┌─────────────────────────────────────────────────────────────┐
│ MHS Safety Constraints Layer Architecture │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Layer 1: Device-Level Safety Boundaries (Embedded) │ │
│ │ ──────────────────────────────────────────────── │ │
│ │ • Hardware parameter ranges (max speed, power, etc.)│ │
│ │ • Physical constraint validation (weight, torque) │ │
│ │ • Enforced at driver level, agent cannot bypass │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Layer 2: MHS State Dictionary Layer (Shared Memory) │ │
│ │ ──────────────────────────────────────────────── │ │
│ │ • State consistency checks (mutex for multi-device) │ │
│ │ • Transactional operations (atomic, auto-rollback) │ │
│ │ • Data stream monitoring (real-time anomaly detect) │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Layer 3: Agent Behavior Constraints │ │
│ │ ──────────────────────────────────────────────── │ │
│ │ • Permission levels (read-only/restricted/full) │ │
│ │ • Rate limiting (debounce/throttle) │ │
│ │ • Operation sequence validation │ │
│ │ • Human confirmation triggers (high-risk operations) │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Layer 4: Physical Safety Monitoring │ │
│ │ ──────────────────────────────────────────────── │ │
│ │ • External camera verification │ │
│ │ • Physical collision detection │ │
│ │ • Emergency stop (E-Stop) integration │ │
│ │ • Automatic error recovery procedures │ │
│ └──────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Figure 3: MHS Four-Layer Safety Architecture — From device-level to physical monitoring, establishing a progressively fortified safety protection system.
Here’s an implementation of the safety constraint validator:
"""
MHS Safety Constraint Validator
"""
from enum import Enum
from dataclasses import dataclass
from typing import Optional
import time
class OperationType(Enum):
READ = "read"
WRITE = "write"
EXECUTE = "execute"
class PermissionLevel(Enum):
READ_ONLY = 1
RESTRICTED = 2
FULL_CONTROL = 3
@dataclass
class OperationRequest:
"""Operation request"""
agent_id: str
device_id: str
operation: OperationType
path: str
value: Optional[Any] = None
timestamp: float = 0.0
@dataclass
class SafetyValidationResult:
"""Safety validation result"""
allowed: bool
reason: str = ""
requires_human_confirmation: bool = False
class SafetyConstraintValidator:
"""
Safety Constraint Validator
Central validation entry point for MHS three-layer safety constraints
"""
def __init__(self):
self._device_limits: Dict[str, list[SafetyLimit]] = {}
self._agent_permissions: Dict[str, PermissionLevel] = {}
self._operation_history: Dict[str, list[float]] = {}
self._max_frequency: float = 10.0
def register_device_limits(self, device_id: str, limits: list[SafetyLimit]):
"""Register device safety limits"""
self._device_limits[device_id] = limits
def set_agent_permission(self, agent_id: str, level: PermissionLevel):
"""Set agent permission level"""
self._agent_permissions[agent_id] = level
def validate(self, request: OperationRequest) -> SafetyValidationResult:
"""
Complete operation request validation flow:
1. Permission validation
2. Rate limiting
3. Safety boundary validation
4. Physical constraint validation
5. High-risk operation flagging
"""
# Step 1: Permission validation
perm = self._agent_permissions.get(request.agent_id, PermissionLevel.READ_ONLY)
if request.operation == OperationType.WRITE and perm == PermissionLevel.READ_ONLY:
return SafetyValidationResult(False, "Agent has read-only permission")
if request.operation == OperationType.EXECUTE and perm == PermissionLevel.READ_ONLY:
return SafetyValidationResult(False, "Agent has read-only permission, cannot execute")
# Step 2: Rate limiting
if not self._check_rate_limit(request.agent_id):
return SafetyValidationResult(False, "Operation frequency exceeded limit")
# Step 3: Safety boundary validation
if request.operation in (OperationType.WRITE, OperationType.EXECUTE):
limits = self._device_limits.get(request.device_id, [])
for limit in limits:
if limit.parameter in request.path:
if not (limit.min_value <= request.value <= limit.max_value):
return SafetyValidationResult(
False,
f"Safety boundary violation: {limit.parameter} "
f"value {request.value} {limit.unit} "
f"outside range [{limit.min_value}, {limit.max_value}] {limit.unit}"
)
# Step 4: High-risk operation flagging
requires_confirm = self._is_high_risk_operation(request)
return SafetyValidationResult(
allowed=True,
requires_human_confirmation=requires_confirm,
reason="Validation passed"
)
def _check_rate_limit(self, agent_id: str) -> bool:
"""Check if operation frequency exceeds the limit"""
now = time.time()
if agent_id not in self._operation_history:
self._operation_history[agent_id] = []
self._operation_history[agent_id] = [
t for t in self._operation_history[agent_id]
if now - t < 1.0
]
if len(self._operation_history[agent_id]) >= self._max_frequency:
return False
self._operation_history[agent_id].append(now)
return True
def _is_high_risk_operation(self, request: OperationRequest) -> bool:
"""Determine if this is a high-risk operation requiring human confirmation"""
high_risk_patterns = [
"laser/power",
"speed/max",
"force/apply",
"position/override",
"calibration/write",
]
return any(pattern in request.path for pattern in high_risk_patterns)
Three Control Mechanisms: 3 Paths for Agents to Operate Hardware
MHS provides three different hardware control pathways for AI agents, each suited to different scenarios:
┌─────────────────────────────────────────────────────────────┐
│ MHS Three Control Mechanisms Comparison │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ MCP Protocol │ │ CLI │ │ Code Files │ │
│ │ │ │ │ │ (API) │ │
│ ├───────────────┤ ├───────────────┤ ├───────────────┤ │
│ │ Real-time │ │ Quick debug │ │ Batch exec │ │
│ │ Step-by-step │ │ Manual test │ │ Long-running │ │
│ │ Agent online │ │ Dev env │ │ Offline script│ │
│ ├───────────────┤ ├───────────────┤ ├───────────────┤ │
│ │ Latency: ~100ms│ │ Latency: ~50ms│ │ Latency: ~1ms │ │
│ │ Needs Agent │ │ Needs human │ │ No Agent │ │
│ │ reasoning │ │ operation │ │ reasoning │ │
│ │ Exploratory │ │ Debugging │ │ Production │ │
│ └───────────────┘ └───────────────┘ └───────────────┘ │
│ │
│ Three mechanisms can be used in combination: │
│ Agent explores via MCP → Finds optimal solution → │
│ Packages as Code File → Runs in production │
└─────────────────────────────────────────────────────────────┘
Figure 4: MHS Three Control Mechanisms — MCP for real-time interaction, CLI for debugging/development, Code Files for production-level batch execution.
Code Files: Turning Exploration into Deterministic Scripts
One of MHS’s most fascinating features is that AI agents can perform exploratory operations through MCP, then package the results as Code Files — deterministic scripts that execute without requiring online agent reasoning. This is analogous to a scientist developing an optimal experimental protocol and then writing it as a Standard Operating Procedure (SOP).
"""
MHS Code File Example: Automated BCA Protein Assay
Generated by Claude Agent after exploration via MCP
"""
import asyncio
from mhs import MHSClient
async def bca_protein_assay():
"""
BCA Protein Concentration Assay Automation
Orchestrating: Liquid Handler + Robotic Arm + Plate Reader
"""
# Connect to MHS devices
client = MHSClient()
await client.connect()
# Auto-discover devices
devices = await client.discover_devices()
liquid_handler = devices["cybio_felix"]
robotic_arm = devices["spinnaker_arm"]
plate_reader = devices["varioskan_lux"]
# ====== Phase 1: Standard Preparation ======
print("[Phase 1] Preparing BSA standard dilution series")
await robotic_arm.write("action/grip", {"plate_id": "assay_plate_1"})
await robotic_arm.write("position/place", {"location": "deck_slot_A1"})
await liquid_handler.write("pipette/volume", 200)
await liquid_handler.write("pipette/speed", "slow")
# Serial dilution: 2000→1000→500→250→125→62.5→31.25→0 μg/mL
concentrations = [2000, 1000, 500, 250, 125, 62.5, 31.25, 0]
for i, conc in enumerate(concentrations):
if i == 0:
await liquid_handler.write("aspirate", {
"source": "bsa_stock",
"volume": 100,
"destination": f"well_A{i+1}"
})
else:
await liquid_handler.write("aspirate", {
"source": f"well_A{i}",
"volume": 50,
"destination": f"well_A{i+1}"
})
await liquid_handler.write("dispense", {
"diluent": "pbs_buffer",
"volume": 50,
"destination": f"well_A{i+1}"
})
await liquid_handler.write("mix", {
"well": f"well_A{i+1}",
"cycles": 5,
"volume": 80
})
# ====== Phase 2: Reaction ======
print("[Phase 2] Adding BCA working reagent")
await robotic_arm.write("action/grip", {"plate_id": "assay_plate_1"})
await robotic_arm.write("position/place", {"location": "reaction_station"})
await liquid_handler.write("reagent/prepare", {
"reagent_A_volume": 5000,
"reagent_B_volume": 100,
"destination": "bca_working_reagent"
})
for row in range(8):
for col in range(12):
well = f"well_{chr(65+row)}{col+1}"
await liquid_handler.write("dispense", {
"reagent": "bca_working_reagent",
"volume": 200,
"destination": well
})
# Incubate at 37°C for 30 minutes
await liquid_handler.write("incubator/temperature", 37)
await liquid_handler.write("incubator/time", 30)
print("[Incubating] 37°C, 30 minutes...")
await asyncio.sleep(30)
# ====== Phase 3: Read Results ======
print("[Phase 3] Measuring absorbance at 562nm")
await robotic_arm.write("action/grip", {"plate_id": "assay_plate_1"})
await robotic_arm.write("position/place", {"location": "plate_reader_tray"})
await plate_reader.write("measurement/wavelength", 562)
await plate_reader.write("measurement/mode", "absorbance")
await plate_reader.write("measurement/shake", True)
await plate_reader.write("measurement/shake_duration", 10)
results = await plate_reader.read("measurement/absorbance/all_wells")
print("=" * 50)
print("BCA Protein Assay Results")
print("=" * 50)
for well, absorbance in results.items():
print(f" {well}: {absorbance:.3f} OD")
# ====== Phase 4: Export Data ======
print("[Phase 4] Exporting data")
await plate_reader.write("export/format", "csv")
exported = await plate_reader.read("export/data")
with open("bca_results.csv", "w") as f:
f.write(exported)
print(f"[Done] Results saved to bca_results.csv")
await client.disconnect()
if __name__ == "__main__":
asyncio.run(bca_protein_assay())
Physical Device Control Flow: How an Agent Runs an Experiment
Below is a typical sequence diagram of an AI agent controlling physical devices through MHS:
AI Agent MHS Core Microscope Drv Liquid Handler Drv Robotic Arm Drv
│ │ │ │ │
│ 1. Discover │ │ │ │
│─────────────────>│ │ │ │
│ │ 2. Broadcast │ │ │
│ │<─────────────────│ │ │
│ │ 3. Broadcast │ │ │
│ │<──────────────────────────────────│ │
│ │ 4. Broadcast │ │ │
│ │<──────────────────────────────────────────────────────│
│ │ │ │ │
│ 5. Return list │ │ │ │
│<─────────────────│ │ │ │
│ │ │ │ │
│ 6. Read metadata│ │ │ │
│─────────────────>│ │ │ │
│<─────────────────│ │ │ │
│ (with tags) │ │ │ │
│ │ │ │ │
│ 7. Set params │ │ │ │
│─────────────────>│───Safety───> │ │ │
│ │<───Pass──────│ │ │
│ │─────────────────>│ │ │
│ │ │ │ │
│ 8. Start pipette│ │ │ │
│─────────────────>│──────────────────────────────────>│ │
│ │ │ │ │
│ 9. Read status │ │ │ │
│─────────────────>│──────────────────────────────────>│ │
│<─────────────────│<──────────────────────────────────│ │
│ │ │ │ │
│ 10. Transfer │ │ │ │
│─────────────────>│──────────────────────────────────────────────────────>│
│ │ │ │ │
│ 11. Read result │ │ │ │
│─────────────────>│─────────────────>│ │ │
│<─────────────────│<─────────────────│ │ │
│ │ │ │ │
│ 12. Analyze │ │ │ │
│ Adjust params │ │ │ │
│─────────────────>│───Safety───> │ │ │
│ │─────────────────>│ │ │
│ │ │ │ │
Figure 5: MHS Physical Device Control Sequence Diagram — The agent coordinates multiple devices through MHS Core, with all operations going through the safety validation layer.
MHS vs MCP: Tool Calling Protocol vs Hardware Control Protocol
MHS has a deep connection with Anthropic’s previously launched MCP (Model Context Protocol) — MCP is the protocol for AI models to call software tools, while MHS is the protocol for AI models to control physical hardware. Together, they form a complete protocol stack for AI agents to connect the digital and physical worlds.
┌─────────────────────────────────────────────────────────────┐
│ MCP (Model Context Protocol) │
│ vs │
│ MHS (Model Hardware Standard) │
│ │
│ ┌─────────────────────────┐ ┌─────────────────────────┐ │
│ │ MCP │ │ MHS │ │
│ ├─────────────────────────┤ ├─────────────────────────┤ │
│ │ Domain: Software Tools │ │ Domain: Physical Hardware│ │
│ │ │ │ │ │
│ │ Typical Resources: │ │ Typical Resources: │ │
│ │ • API endpoints │ │ • Microscopes │ │
│ │ • Databases │ │ • Robotic arms │ │
│ │ • File systems │ │ • Liquid handlers │ │
│ │ • Web services │ │ • Plate readers │ │
│ │ • Code repositories │ │ • Lasers │ │
│ │ │ │ • Centrifuges │ │
│ ├─────────────────────────┤ ├─────────────────────────┤ │
│ │ Safety: Access control │ │ Safety: Physical │ │
│ │ Data access control │ │ constraints layer │ │
│ │ No physical risk │ │ Physical damage risk │ │
│ ├─────────────────────────┤ ├─────────────────────────┤ │
│ │ Latency: Milliseconds │ │ Latency: ms to seconds │ │
│ │ No real-time req. │ │ Higher real-time req. │ │
│ ├─────────────────────────┤ ├─────────────────────────┤ │
│ │ Abstraction: Tool def. │ │ Abstraction: Unified │ │
│ │ JSON Schema │ │ driver, read/write │ │
│ │ │ │ primitives, NL tags │ │
│ ├─────────────────────────┤ ├─────────────────────────┤ │
│ │ State: Stateless │ │ State: Shared state │ │
│ │ Each call independent │ │ dictionary for multi- │ │
│ │ │ │ device coordination │ │
│ ├─────────────────────────┤ ├─────────────────────────┤ │
│ │ Status: Open-sourced │ │ Status: Research │ │
│ │ Widely adopted │ │ preview, closed testing │ │
│ └─────────────────────────┘ └─────────────────────────┘ │
│ │
│ Key Relationship: MHS = MCP's Hardware Extension │
│ Agent calls MHS drivers via MCP │
│ MHS drivers are "hardware tools" in the MCP ecosystem │
└─────────────────────────────────────────────────────────────┘
Figure 6: MCP vs MHS Comparison — MCP is a software tool standard, MHS is a hardware control standard, bridged through the MCP protocol.
Real-World Case Studies: MHS is Transforming Scientific Research
1. Carnegie Mellon University: 3x Faster Dose-Response Experiments
CMU researchers used MHS to orchestrate a liquid handler (CyBio Felix), plate reader (Varioskan LUX), robotic arm (Spinnaker), and monitoring cameras to run automated serial dilution dose-response experiments. These devices were spread across three computers with fundamentally incompatible interfaces.
Using MHS, researchers developed drivers for all devices and built an orchestration layer that allowed a Claude Opus 4.8 agent to run the full protocol autonomously in just 8 hours — compared to the several weeks a traditional vendor-built setup would take. The experiments ran approximately 3 times faster than before.
Source: Anthropic - CMU Case Study
2. QuEra Computing: 99.3% Laser Lock Recovery Rate
QuEra Computing builds quantum computers using neutral atoms, with their core operation relying on a laser system. The laser frequency must be held to an astonishing precision of one part in a trillion — equivalent to measuring the distance from Earth to the Moon to within the width of a human hair. Traditionally, when a laser “unlocked,” it required expert manual recovery, taking 5-10 minutes with only a 58% success rate.
Through MHS, a Claude agent autonomously optimized the laser recovery script overnight, compressing recovery time from 150 seconds to 6 seconds and improving the success rate from 58% to 99.3% (695 out of 700 trials). More impressively, Claude also optimized the laser’s 12 PID parameters, reducing residual error from 15.7mV to 1.55mV — a 10x improvement — and the tune held without a single unlock over 19 hours, compared to the expert-tuned PID which unlocked about 1.6 times per hour.
Source: Anthropic - QuEra Case Study & QuEra Blog
3. HHMI Janelia: 7 Vendor Programs Unified into One Interface
Virginie Ruetten, a scientist in the Ahrens lab at HHMI Janelia, studies how sleep helps the body recover from stress. Her microscopy rig combines femtosecond lasers, galvanometer mirrors, photomultiplier detectors, and precision translation stages from different vendors, running 7 different vendor control programs in MATLAB, Python, and C# — with no shared interface.
MHS allowed her to unify all these devices into a shared state dictionary, where an agent can read and write every variable through a single interface. More importantly, MHS enabled Agentic Microscopy — the agent can autonomously search for regions of interest, adjust parameters for zoomed-in observations, and run smarter experiments without human intervention.
4. Genentech: BCA Protein Assay Automation Proof of Concept
Researchers at Genentech implemented and tested MHS as a proof of concept for automating the BCA protein assay — a standard procedure to measure total protein concentration in a sample, coordinating across a liquid handler, a robotic arm, and a plate reader. This marked the first application of MHS in the biopharmaceutical industry.
Source: Anthropic - Genentech Case Study
5. Tetsuwan Scientific: Tracking Environmental Pollution with MHS
Tetsuwan Scientific integrated MHS with its automated biology lab platform, ResearchOS, to run qPCR workflows tracking fecal contamination sources in California’s San Pedro Creek. MHS allowed Claude to detect pipetting errors (such as bubbles) via camera and automatically call a centrifuge for error recovery. During the experiment, Claude and MHS helped refine the compiler’s prediction model, achieving roughly 12% more accurate multi-dispense precision predictions than the manufacturer’s technical specifications.
Source: Anthropic - Tetsuwan Case Study & Tetsuwan Blog
Industry Ecosystem: From Lab to Factory Floor
The MHS announcement is not just a technical release — it’s the launch signal for an industry alliance. Multiple hardware vendors and service providers have already announced support for MHS:
┌─────────────────────────────────────────────────────────────┐
│ MHS Industry Ecosystem Map │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ ┌─────────────┐ ┌────────────┐ ┌────────────┐ │ │
│ │ │ AWS (Strands│ │ Automata │ │ Danaher │ │ │
│ │ │ Robots) │ │ (LINQ) │ │ │ │ │
│ │ └─────────────┘ └────────────┘ └────────────┘ │ │
│ │ ┌─────────────┐ ┌────────────┐ ┌────────────┐ │ │
│ │ │ Doosan │ │ MBF │ │ QIAGEN │ │ │
│ │ │ Robotics │ │ Bioscience│ │ │ │ │
│ │ └─────────────┘ │ (ScanImage)│ └────────────┘ │ │
│ │ └────────────┘ │ │
│ │ ┌─────────────┐ ┌────────────┐ ┌────────────┐ │ │
│ │ │ Tecan │ │ Universal │ │ Hugging │ │ │
│ │ │ (Fluent) │ │ Robots │ │ Face │ │ │
│ │ └─────────────┘ │ │ │ (LeRobot) │ │ │
│ │ └────────────┘ └────────────┘ │ │
│ │ ┌─────────────┐ │ │
│ │ │ Raspberry │ │ │
│ │ │ Pi │ │ │
│ │ └─────────────┘ │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ Coverage: Biotech | Robotics | Quantum Computing | │
│ Electronics Manufacturing | Scientific Research │
└─────────────────────────────────────────────────────────────┘
Figure 7: MHS Industry Ecosystem Map — Covering biotech, robotics, quantum computing, electronics manufacturing, and scientific research.
MHS + MCP Integration: Complete Agent Protocol Stack from Code to Hardware
One of MHS’s most powerful design features is its native integration with MCP. Agents can call MHS drivers through the MCP protocol, enabling seamless orchestration from software tools to physical hardware:
"""
MHS + MCP Integration Example: Agent Controls MHS Devices via MCP
"""
from mcp import MCPClient, Tool
from mhs import MHSClient
class MHSViaMCPAdapter:
"""
Wraps MHS devices as MCP tools
Enables any MCP-compatible agent to control physical devices
"""
def __init__(self, mhs_client: MHSClient):
self.mhs = mhs_client
self.mcp = MCPClient()
async def register_devices_as_mcp_tools(self):
"""Register MHS-discovered devices as MCP tools"""
devices = await self.mhs.discover_devices()
for device_id, device_info in devices.items():
metadata = await self.mhs.get_device_metadata(device_id)
tool = Tool(
name=f"mhs_{device_id}",
description=f"Control {device_info.vendor} {device_info.model} - {metadata.general_description}",
parameters={
"operation": {
"type": "string",
"enum": ["read", "write"],
"description": "Operation type: read / write"
},
"path": {
"type": "string",
"description": f"Parameter path. Available: {metadata.what_can_be_adjusted}"
},
"value": {
"type": "number",
"description": "Write value (only needed for write operations)"
}
},
handler=self._create_device_handler(device_id)
)
await self.mcp.register_tool(tool)
print(f"[MCP+MHS] Device {device_info.device_name} registered as MCP tool")
def _create_device_handler(self, device_id: str):
"""Create an MCP tool handler for a device"""
async def handler(params: dict) -> str:
operation = params["operation"]
path = params["path"]
value = params.get("value")
if operation == "read":
result = await self.mhs.read(device_id, path)
return f"Read {device_id}/{path}: {result}"
elif operation == "write":
await self.mhs.write(device_id, path, value)
return f"Write {device_id}/{path} = {value}: Success"
else:
return f"Unknown operation: {operation}"
return handler
async def orchestrate_experiment(self, agent_prompt: str):
"""Run an agent-orchestrated experiment via MCP"""
await self.mcp.start_session(
system_prompt=(
"You are an experimental operations AI assistant. "
"You can control the following physical devices via MCP tools:\n"
"1. Liquid handler: precision pipetting\n"
"2. Robotic arm: plate transfer\n"
"3. Plate reader: absorbance measurement\n"
"4. Microscope: image acquisition\n\n"
"Orchestrate device operations according to experimental needs.\n"
"Note: All operations are protected by safety constraints."
)
)
result = await self.mcp.run(agent_prompt)
return result
Challenges and Limitations
Despite its immense potential, MHS is still in its early stages and faces the following challenges:
Physical World Understanding Limitations: Claude learns about the physical world through text and images, meaning its spatial and physical reasoning have limitations that still require expert oversight. For example, Genentech researchers had to guide Claude to recognize that errors caused by foaming in samples were physical failures, not software bugs.
Device Compatibility Limitations: MHS currently only works with devices that have a programmable interface. For older devices lacking such interfaces, manufacturers need to integrate MHS drivers.
Safety Evaluations in Progress: Anthropic is working with partners to build safety evaluations and develop best practices for AI systems operating physical equipment, which must be completed before open-sourcing.
Agent Caution May Impact Efficiency: Claude pauses to wait for human confirmation before performing actions it deems even slightly risky, which can cause experiments to pause overnight.
Context Requirements: Agents need significant context to understand experimental goals and operational methods.
Future Outlook
The release of MHS marks a turning point in AI agents’ journey from the digital world to the physical world. Looking ahead, several key directions are worth watching:
Open Source Plans: Anthropic plans to open-source MHS after completing the research preview, along with a safety deployment guide.
Physical Safety Roadmap: Anthropic is developing a physical safety roadmap to strengthen safeguards for AI systems in the physical world.
Broader Device Coverage: The next phase will expand MHS to cover more device types, including developer platforms like Raspberry Pi.
The Vision of Automated Labs: MHS aims to make AI-driven automated laboratories a reality — agents running round-the-clock experiments, adjusting parameters in real-time, and automatically recovering from hardware errors.
From Science to Industry: MHS is applicable not only to scientific research labs but also to advanced manufacturing, quality control, supply chain management, and other industrial scenarios.
Conclusion
Anthropic’s Model Hardware Standard is a significant milestone in the history of AI agent development. For the first time, it provides a unified standard protocol for AI models to control physical hardware, compressing device integration time from weeks to hours, while embedding the safety constraints necessary for physical world operations.
MHS’s significance is comparable to that of MCP for tool calling — if MCP enables AI agents to “call any software tool,” then MHS enables AI agents to “operate any physical device.” When AI agents possess both capabilities simultaneously, from automated scientific research to intelligent manufacturing, from quantum computing to biomedicine, the boundaries of application will extend far beyond our imagination.
Just as Claude optimized laser control parameters overnight at QuEra, accelerated experiments 3x at CMU, and enabled autonomous microscopy at HHMI Janelia — these case studies reveal a clear future: AI agents are no longer just residents of the digital world; they are becoming operators of the physical world.
References: