El 27 de agosto de 2026 Anthropic abrió un research preview del Model Hardware Standard (MHS), una especificación compartida pensada para que los agentes de IA puedan descubrir, describir y operar de forma más segura equipos físicos programables.[1]
MHS nació de una colaboración entre Anthropic y HHMI Janelia Research Campus. Los primeros proyectos conectaron microscopios, liquid handlers, brazos robóticos, plate readers y componentes del sistema láser de un ordenador cuántico.[1]
Hasta ahora, la mayoría de los agentes populares actuaban sobre todo en entornos digitales:
archivos
repositorios
terminal
APIs
navegador
bases de datos
sistemas SaaSMHS intenta estandarizar otra capa:
sensores
cámaras
microscopios
robots de laboratorio
brazos robóticos
láseres
equipos de medición
equipos de producciónPero no debe resumirse como “Claude ya puede controlar cualquier máquina”. MHS es actualmente un research preview limitado, el acceso se concede mediante solicitud y el estándar todavía no se ha publicado como open source. Anthropic afirma que pretende abrirlo después de la fase de preview y de más trabajo de seguridad, pero a 30 de agosto no ha publicado una fecha ni una licencia para esa futura versión abierta.[1][2]
MHS tampoco es un nuevo modelo de IA y no sustituye al Model Context Protocol (MCP). Anthropic lo describe como model-agnostic, y MCP es uno de los tres mecanismos con los que un agente puede controlar hardware descrito por MHS. Los otros dos son CLI y archivos de código/APIs.[1]
Conclusión principal: MHS no es “MCP 2.0” ni un robot. Es un intento de crear una capa común de drivers, descripción de dispositivos y límites físicos de seguridad para que un agente pueda trabajar con máquinas distintas mediante una interfaz más coherente.
Estado de la información: 30 de agosto de 2026.
TL;DR
| Pregunta | Respuesta verificada |
|---|---|
| ¿Qué anunció Anthropic? | Research preview de Model Hardware Standard |
| ¿Cuándo? | 27 de agosto de 2026 |
| ¿Qué es MHS? | Una especificación y capa de drivers para hardware programable |
| ¿Es un nuevo modelo Claude? | No |
| ¿Ya es open source? | No |
| ¿Anthropic piensa abrirlo? | Sí, después de la preview y del trabajo de seguridad |
| ¿Hay fecha? | No |
| ¿Hay licencia futura conocida? | No aparece en los materiales oficiales revisados |
| ¿Sustituye MHS a MCP? | No |
| ¿Cómo usa MCP? | MCP es uno de los mecanismos de control de hardware MHS |
| Otros mecanismos | CLI y archivos de código/API |
| ¿Funciona solo con Claude? | No, Anthropic lo describe como model-agnostic |
| ¿Qué hardware? | Equipos con interfaz programable; los pilotos incluyen laboratorio y robótica |
| Métrica pública más fuerte | QuEra: 695/700 relocks de láser correctos, 99,3 % |
| ¿Benchmark independiente? | No, es un resultado de un piloto de partner |
| Riesgo principal | Un error del agente puede tener consecuencias físicas |
| Principio de seguridad | Límites e interlocks deben imponerse fuera del modelo |
¿Qué es exactamente Model Hardware Standard?
Anthropic define MHS como una shared specification for AI agents to safely operate physical devices.[1]
El problema es conocido: un laboratorio o una línea de producción puede contener dispositivos de múltiples vendors, cada uno con SDK, API, formato de datos, aplicación de escritorio, documentación y modelo de errores distintos.
Conectarlos suele requerir glue code específico.
Anthropic afirma que esas integraciones pueden tardar semanas o meses y que MHS puede reducir parte del trabajo a horas o minutos.[1] Es una afirmación del fabricante, no un benchmark independiente de toda la industria.
MHS no es un robot ni un modelo
MHS no es:
- un nuevo modelo Claude,
- un sistema operativo robótico,
- una nueva clase de robot,
- un sustituto del firmware,
- un algoritmo autónomo de motion planning,
- un protocolo industrial que sustituya todos los sistemas de control.
Es mejor verlo como una capa de interoperabilidad entre un agente y hardware físico programable.
El agente sigue necesitando modelo, harness o aplicación, permisos, driver, interfaz del dispositivo y protecciones físicas independientes.
¿Cómo funciona MHS?
3.1. Driver estandarizado
MHS introduce un driver que traduce operaciones entre el ordenador y el equipo.[1]
Anthropic menciona primitivas simples:
read
writepor ejemplo:
read temperature
write temperatureEso no significa que un dispositivo solo tenga dos órdenes. Funciones complejas pueden construirse sobre primitivas comunes.
3.2. Descripción estándar del dispositivo
MHS hace los dispositivos discoverable en un formato común para que agentes y otras máquinas puedan encontrarlos en la red y comprender sus capacidades.[1]
La descripción puede incluir:
- qué mide el equipo,
- qué puede modificarse,
- características físicas,
- restricciones importantes,
- límites de seguridad impuestos.
Anthropic pone como ejemplo el peso de un brazo robótico, relevante para manipularlo con seguridad.[1]
3.3. Tags en lenguaje natural
Los usuarios pueden describir propiedades del hardware mediante tags en lenguaje natural, directamente o con un agente que les entreviste sobre el setup.[1]
El driver genera un archivo de referencia con características, medidas, parámetros ajustables y safety limits.
El artículo público de Anthropic no es el schema completo. Como MHS sigue en preview limitada, no deben inventarse nombres de campos ni sintaxis presentándolos como oficiales.
Tres mecanismos de control
Anthropic describe tres:[1]
1. MCP
2. CLI
3. code files / APIsMCP
Un agente puede acceder al hardware mediante Model Context Protocol. Los servidores MCP pueden exponer tools, funciones ejecutables que el modelo descubre e invoca.[4][5]
CLI
El equipo también puede controlarse desde línea de comandos, útil para operadores, scripting, debugging y tests.
Código y APIs
Un agente puede agrupar órdenes de uno o varios equipos en software convencional. Anthropic destaca esta vía para operaciones rápidas, repetibles o largas en las que el LLM no debería razonar en cada micro-paso.[1]
El agente puede aprender una operación y salir del loop
Un modelo generativo no tiene que controlar la máquina cada milisegundo.
En un ejemplo Claude:
- ajustó un láser,
- observó el resultado con una cámara,
- repitió el experimento,
- identificó relaciones,
- convirtió el procedimiento en código determinista.[1]
Después, el script pudo ejecutarse sin reasoning continuo.
Un patrón de producción importante es:
IA explora
↓
IA crea un procedimiento
↓
humanos / tests verifican
↓
código determinista ejecutaQuEra siguió este patrón para su controlador de relock: el agente ayudó a desarrollar y validar el código, mientras que la lógica final de producción es software determinista e inspeccionable sin modelo online en runtime.[7]
MHS vs MCP: diferencia principal
| Elemento | MCP | MHS |
|---|---|---|
| Objetivo | Conectar aplicaciones IA con tools, datos y sistemas | Estandarizar descripción y control de hardware físico |
| Destino típico | Software, APIs, datos, tools | Dispositivos físicos programables |
| Modelo | Host, client, server, JSON-RPC | Driver + descripción + mecanismos de control |
| Tools | Sí | Pueden exponerse mediante MCP |
| CLI | No es el núcleo del protocolo | Una vía de control documentada |
| API/code files | Pueden existir detrás de MCP | Una vía documentada |
| Límites físicos | No son el foco central de MCP | Parte de la semántica MHS |
| Open source hoy | Sí | Aún no |
| Estado | Protocolo abierto | Research preview limitado |
Anthropic publicó MCP en 2024 como estándar abierto para conexiones bidireccionales entre sistemas de IA, datos y herramientas.[4] La documentación MCP describe host-client-server, capability negotiation, tools, resources y prompts.[5][6]
MHS no sustituye esa capa.
Stack conceptual:
MODEL / AGENT
│
├── MCP
├── CLI
└── CODE / API
│
MHS DRIVER
│
DEVICE INTERFACE
│
PHYSICAL HARDWAREEs un diagrama conceptual de POLPROG, no un diagrama oficial de Anthropic.
¿Es MHS “MCP para el mundo físico”?
Como resumen es útil, pero técnicamente simplifica demasiado.
Ambos reducen integraciones bespoke y ofrecen una interfaz común.
La diferencia: MCP es un protocolo de comunicación entre sistemas IA y tools. MHS añade semántica del dispositivo físico, estado, capacidades y límites.
Además, MHS puede usar MCP.
Por eso es más exacto decir:
MHS complementa MCP con una capa para hardware físico.
MHS es model-agnostic
Anthropic declara expresamente que MHS es model-agnostic y que cualquier agent harness puede acceder mediante protocolos estándar como MCP.[1]
No está formalmente limitado a Claude o Claude Code.
Los case studies públicos se concentran en Claude porque pertenecen a Anthropic y partners de la preview. Todavía no existe un benchmark independiente de varios modelos sobre el mismo hardware y los mismos drivers.
La seguridad debe existir por debajo del modelo
Un tool call erróneo en software puede borrar un archivo. En el mundo físico puede causar una colisión, derramar una muestra o dañar una máquina.
Un prompt en lenguaje natural no puede ser la única protección.
MHS puede transmitir safety limits aplicados.[1] QuEra señala que bounds, interlocks y emergency stops se aplicaron en la interfaz física de forma independiente del modelo.[7]
Arquitectura adecuada:
MODEL
propone
POLICY / APPROVAL
acepta o rechaza
DRIVER / CONTROLLER
impone límites
HARDWARE INTERLOCK
protege incluso si falla el softwareGenentech: un fallo físico inicialmente mal interpretado
Genentech probó MHS en un BCA protein assay con liquid handler, brazo robótico y microplate reader.[1]
Aparecieron burbujas durante la mezcla, provocando runtime errors. Claude trató inicialmente el problema como un fallo software y repitió en el mismo well con otros parámetros. Eso generó más burbujas.[1]
Expertos humanos tuvieron que explicar la causa física, indicar un well limpio y una mezcla más suave. Después codificaron ese aprendizaje en reusable liquid-handling skills.[1]
Lección:
Un modelo puede entender un error de software y al mismo tiempo no comprender la física que lo causa.
University of Washington: seis equipos en menos de una semana
Los laboratorios Baker y Pinglay usaron MHS para monitorización remota, qPCR supervisado por agentes y coordinación entre brazo robótico y liquid handler.[1]
En un plate handoff, el liquid handler acababa, el agente recibía la señal y unos diez segundos después activaba el brazo. El autor informa de que no hubo colisiones en las pruebas repetidas.
Conectar seis instrumentos, incluido el desarrollo de drivers, habría llevado menos de una semana.[1]
Es un resultado de un laboratorio, no una garantía general.
Carnegie Mellon: seis condiciones de seguridad inducidas
Un equipo de Carnegie Mellon usó MHS para experimentos serial dilution dose-response.[1]
El setup combinaba liquid handler, plate reader, brazo robótico, cámaras y tres ordenadores con interfaces incompatibles.
Los investigadores provocaron seis condiciones:
- placa ausente,
- placa girada,
- reader ocupado,
- cámara desconectada,
- dispositivo inaccesible,
- emergency stop activo.[1]
Según el informe, las seis fueron bloqueadas antes de que se moviera cualquier dispositivo.
Es un buen proof of concept, no una certificación formal.
Corrección autónoma
El primer run produjo:
R² < 0,9El agente redujo la concentración máxima:
200 µg/mL
→
100 µg/mLEl segundo run logró:
R² > 0,98sin intervención humana.[1]
El equipo reporta unas 8 horas desde el hardware listo pero no automatizado hasta una curva completa incluyendo el rerun, comparándolo con semanas para una integración vendor.[1]
HHMI Janelia: una capa de estado para siete programas
En un proyecto de Janelia una investigadora tenía que iniciar siete programas en un orden fijo.
MHS sustituyó conexiones punto a punto por un state dictionary compartido en memoria.[1]
Según el caso:
- una nueva cámara se añadió en minutos en lugar de días,
- el arranque pasó de siete pasos a una operación,
- los data streams pudieron analizarse con herramientas reutilizables independientemente del software vendor.[1]
MHS también imponía límites como potencia máxima del láser para evitar que el agente superase el rango seguro para la muestra.[1]
QuEra: 695 relocks correctos de 700
El piloto más cuantitativo procede de QuEra Computing.
QuEra usó MHS para dar a Claude acceso a parte del sistema láser de un ordenador cuántico.[1][7][8]
Después de la fase experimental se creó un controlador determinista.
QuEra realizó:
700 pruebas
7 clases de perturbación
100 pruebas por claseResultado:
695 / 700
=
99,3 %Casos simples:
0,9–5,4 scasos difíciles:
10–14 sfrente a:
5–10 minutospara un experto humano.[7]
No es un benchmark de Claude al 99,3 %
En el blind test final el agente no controlaba el láser online.
Correcto:
Un agente con MHS ayudó a desarrollar un controlador que después logró 99,3 %.
Incorrecto:
Claude controla hardware con 99,3 % de precisión.
Divergencia entre fuentes
Anthropic describe el desarrollo del script anterior como “several months”.[1]
QuEra habla de unas 2–3 semanas.[7]
Como las fuentes discrepan, no usamos ese tiempo como métrica comparativa dura.
Limitaciones reveladas por QuEra
Los informes también describen límites.
Claude:
- no podía diagnosticar ciertos fallos puramente físicos,
- entendía el rig sobre todo desde su representación programática,
- necesitaba mucho contexto,
- a veces detenía el experimento y esperaba confirmación humana ante una acción mínimamente arriesgada.[1]
En hardware físico, esa cautela puede ser mejor que la sobreconfianza.
Tetsuwan: un equipo detecta el fallo y otro lo corrige
Tetsuwan conectó MHS con ResearchOS en un workflow qPCR relacionado con San Pedro Creek.[1]
Una cámara detectó burbujas. El robot que sostenía la muestra no podía eliminarlas.
El sistema:
- detectó el problema,
- buscó dispositivos MHS,
- encontró una centrifuge,
- Claude propuso usarla,
- tras aprobación envió los comandos.[1]
Es un ejemplo de recuperación entre dispositivos en vez de un workflow rígido.
Ecosistema de partners
Anthropic menciona:[1]
- Amazon Web Services,
- Automata,
- Danaher,
- Doosan Robotics,
- MBF Bioscience,
- QIAGEN,
- Tecan,
- Universal Robots,
- Hugging Face,
- Raspberry Pi.
AWS planea soporte mediante Strands Robots, Hugging Face trabaja en LeRobot y Raspberry Pi en integraciones para ciertos productos.[1]
Eso no significa que todas estén listas para producción pública.
MHS todavía no es open source
La web oficial lo llama limited research preview.[2]
Anthropic quiere primero reunir experiencia, construir safety evaluations, definir best practices y reforzar safeguards.[1]
A 30 de agosto de 2026 no hay:
- fecha pública de release open-source,
- licencia final,
- especificación pública completa comparable a MCP.
Por tanto:
Anthropic planea hacer MHS open source.es correcto.
MHS ya es open source.no lo es.
¿Los resultados son benchmarks independientes?
No.
Las cifras públicas proceden principalmente de Anthropic y los partners.
Reuters confirma de forma independiente el lanzamiento, el alcance general y la intención de abrir el estándar más adelante.[3]
No hay todavía un benchmark público con hardware idéntico, drivers idénticos, varios modelos, un único harness y grading independiente.
Por eso valores como:
99,3 %
3× más rápido
8 horas
menos de una semanadeben permanecer vinculados a cada piloto.
Threat model: ¿qué puede salir mal?
Reasoning incorrecto
Un modelo puede interpretar mal un sensor, error code, imagen o causa física. Genentech ofrece un ejemplo real.[1]
Driver erróneo o malicioso
Unidades equivocadas, estados falsos o falta de validación pueden engañar al agente.
Prompt injection
Texto en imágenes, documentación y datos de red pueden contener instrucciones maliciosas.
Confused deputy
Un agente con acceso a varias máquinas puede usar la herramienta correcta con el objetivo incorrecto.
Race conditions
Dos agentes pueden modificar simultáneamente el mismo estado físico.
Pérdida de conectividad
Debe existir un safe state si falla el modelo, MCP, la red, el driver o el sensor.
Arquitectura de producción más segura
MODEL / AGENT
↓
POLICY + APPROVAL
↓
MCP / CLI / API
↓
MHS DRIVER
↓
DETERMINISTIC CONTROLLER
↓
HARDWARE INTERLOCK / E-STOP
↓
PHYSICAL HARDWAREEs una recomendación POLPROG, no un diagrama oficial de Anthropic.
Un LLM no debe ser el único componente que decide si una operación física es segura.
¿Qué debe imponer la capa determinista?
Por ejemplo:
- rangos de temperatura,
- potencia máxima,
- velocidad del brazo,
- límites de espacio,
- orden de movimientos,
- collision zones,
- límites de presión,
- estado de protecciones,
- emergency stop,
- tiempo máximo de operación.
Una solicitud fuera de rango debe rechazarse independientemente del reasoning del modelo.
Human-in-the-loop sigue siendo importante
La especificación MCP Tools recomienda que el usuario pueda rechazar tool invocations.[5]
Para hardware:
READ
automático
LOW-RISK WRITE
automático dentro de un rango estrecho
MEDIUM-RISK
policy + validación
HIGH-RISK
human approval
EMERGENCY / UNSAFE
siempre bloqueadoPor qué el fallback determinista importa
QuEra muestra un patrón práctico:
IA descubre solución
→ se genera código
→ tests y humanos validan
→ producción ejecuta software deterministaReduce coste, latency, nondeterminism, dependencia de API y riesgo de decisiones inesperadas.
MHS y sistemas de control industriales
MHS no debe verse como sustituto de PLC, SCADA, OPC UA, safety PLC o controladores real-time.
Una posición más realista:
agente
↓
orchestration
↓
MHS
↓
controladores existentes
↓
hardwareAnthropic muestra que operaciones rápidas o largas pueden empaquetarse en código para evitar reasoning del LLM en cada paso.[1]
¿Quién debería seguir MHS ahora?
Especialmente:
- laboratorios con equipos multi-vendor,
- biotech y pharma,
- microscopy,
- robótica,
- quantum computing,
- advanced manufacturing,
- equipos R&D con mucho bespoke integration code.
¿Quién debe ser prudente?
Cuando:
- el sistema es safety-critical,
- se exige especificación pública estable,
- se requiere una licencia open-source conocida,
- hacen falta estándares industriales certificados,
- el equipo no tiene interfaz automatizable,
- faltan interlocks independientes,
- el equipo humano no puede auditar drivers.
Un research preview no es un estándar industrial maduro.
Cómo preparar una empresa
Paso 1: inventario
vendor
model
SDK/API/GUI
unidades
estados
comandos
límites
E-stop
dependenciasPaso 2: separar read y write
Definir qué puede leerse, modificarse, automatizarse y qué requiere approval.
Paso 3: sacar la seguridad del prompt
No depender de:
"nunca superes 80°C"El límite real debe imponerse mediante código o hardware.
Paso 4: registrar todo
Agent/model, operación, parámetros, estado antes/después, resultado, timestamp, policy y approval.
Paso 5: simular primero
digital twin / mock drivery después:
real hardwarePlan mínimo de pruebas
Driver
- unidades,
- ranges,
- timeouts,
- reconnect,
- respuestas inválidas,
- restart.
Agent
- sensor incorrecto,
- datos contradictorios,
- error code desconocido,
- prompt injection,
- contexto insuficiente.
Hardware
- collision prevention,
- E-stop,
- power loss,
- network loss,
- bloqueo mecánico,
- out-of-range values.
Multi-agent
- writes simultáneos,
- stale state,
- resource locking,
- retry tras timeout.
Checklist de seguridad MHS
Arquitectura
- El modelo no controla actuators sin validación.
- Cada driver tiene límites explícitos.
- Valores con unidades y rangos.
- Límites críticos deterministas.
- E-stop independiente de IA.
- Safe state tras pérdida de conexión.
- Device state con timestamp.
- Retry seguro.
Permisos
- El agente ve solo los dispositivos necesarios.
- READ y WRITE separados.
- High-risk actions requieren approval.
- Los permisos caducan.
- No existe un admin token global.
Monitoring
- Cada tool call se registra.
- Los cambios físicos generan telemetría.
- Las alarmas no dependen solo del modelo.
- El operador ve el estado actual.
- Hay event replay.
- Los fallos se clasifican.
Tests
- Mock hardware.
- Physical sandbox.
- Fault injection.
- Prompt injection.
- Race conditions.
- Network partition.
- Agent restart.
- Driver restart.
- Unidades incorrectas.
- Out-of-range values.
Producción
- Rollout empieza read-only.
- Después low-risk writes.
- Safety-critical actions fuera del agente.
- Código determinista sustituye IA cuando sea posible.
- Drivers con code review.
- Existe rollback.
- Existe control manual.
- El equipo conoce el efecto físico de cada comando.
¿Qué hace falta para que MHS sea un estándar real?
Entre otras cosas:
- especificación pública,
- versioning estable,
- modelo de compatibilidad,
- SDK públicos,
- licencia open-source,
- reference drivers,
- conformance tests,
- security evaluations,
- implementaciones independientes,
- soporte de vendors,
- validación de drivers,
- permission model claro.
MCP ganó relevancia al convertirse en ecosistema interoperable. MHS tendrá que recorrer un camino similar.
¿Cambiará MHS la robótica?
Tal vez, pero es demasiado pronto.
El mejor fit inicial está en entornos donde el hardware ya es programable, integrar cuesta mucho y los workflows cambian:
laboratorios
R&D
biotech
microscopy
quantum
advanced manufacturingMHS no resuelve automáticamente percepción robótica, motion planning, real-time control, safety certification o física de manipulación.
Sí puede simplificar la interfaz mediante la que un agente utiliza sistemas ya existentes.
Veredicto POLPROG
Model Hardware Standard es uno de los desarrollos agentic más interesantes de 2026 porque traslada el problema de interoperabilidad del mundo digital al físico.
Lo confirmado
- research preview desde 27 de agosto de 2026.[1][3]
- origen conjunto Anthropic y HHMI Janelia.[1]
- model-agnostic.[1]
- control mediante MCP, CLI y code/API files.[1]
- el driver describe el equipo y safety limits.[1]
- Anthropic quiere abrirlo posteriormente.[1][2]
- QuEra confirma 695 relocks correctos de 700 para el controlador final.[7]
Lo que todavía no sabemos
- schema público final,
- fecha open-source,
- licencia,
- estabilidad API,
- compatibilidad entre implementaciones,
- benchmark independiente,
- rendimiento de modelos distintos sobre el mismo hardware.
El patrón más prometedor
No:
LLM controla todo constantementesino:
agente entiende el objetivo
→ explora un espacio seguro
→ coordina dispositivos
→ crea o elige procedimiento
→ el sistema valida
→ el trabajo repetible pasa a código deterministaSi Anthropic abre la especificación, los vendors publican drivers reutilizables y equipos independientes validan seguridad e interoperabilidad, MHS podría convertirse en una capa importante para physical AI.
Todavía no hemos llegado a ese punto.
