Anthropic MHS: el estándar para agentes en hardware físico

Anthropic presentó esta semana el Model Hardware Standard (MHS), una especificación que define cómo un agente de IA puede operar un dispositivo físico (un microscopio, un liquid handler, un láser, un brazo robótico) sin que cada equipo tenga que escribir su propia integración a medida. La desarrolló junto al HHMI Janelia Research Campus y por ahora está en research preview, con la idea de liberarla como open source cuando termine esa fase. Si te suena a algo conocido es porque la idea es hermana del MCP: un contrato estándar para que cualquier modelo pueda "hablar" con cualquier cosa, en este caso con hardware del mundo real. La diferencia es que MHS está pensado para sistemas donde un error no se traduce en un bug, sino en algo que se mueve, se calienta o se rompe.

Por qué Anthropic publicó MHS ahora

Hasta ahora, los agentes que operaban hardware físico eran proyectos a medida. Cada equipo que quería que Claude, GPT o un modelo local manejara un instrumento tenía que escribir su propio "puente": drivers, parsers de output, límites de seguridad específicos, manejo de errores físicos. Según Anthropic, esa integración puede llevar semanas o meses por dispositivo; con MHS, la promesa es bajarla a horas o minutos.

Además, ese puente es la parte más peligrosa del sistema. Un LLM puede equivocarse de muchas formas nuevas cuando lo que tiene al otro lado es un motor paso a paso en vez de un archivo. La creciente cantidad de incidentes con agentes que se escapan de sandboxes (el caso del agente de OpenAI en Hugging Face es el ejemplo más claro) muestra que la conversación sobre seguridad agéntica necesita estándares, no solo buenas prácticas. MHS es la apuesta de Anthropic por subir el nivel: en vez de pedirle a cada laboratorio que invente su propio sistema, ofrece una especificación común que cualquier fabricante y cualquier modelo pueden implementar.

El cambio de mentalidad: MHS no es un framework de agentes. Es una capa común entre el agente y el dispositivo: describe qué puede hacer el equipo, qué se puede ajustar y qué límites no se pueden cruzar, y hace cumplir esos límites del lado del hardware.

Qué define exactamente el estándar

El anuncio de Anthropic es bastante concreto. MHS tiene cuatro piezas:

Driver estandarizado. Se sienta entre el sistema operativo y el hardware, con primitivas básicas de lectura y escritura, y hace que los dispositivos sean descubribles en un formato estándar, para que un agente los encuentre en la red.
Archivos de referencia del dispositivo. Describes el equipo en lenguaje natural y MHS genera un archivo de referencia con qué puede medir, qué se puede ajustar y qué límites de seguridad aplican. Es lo más parecido a las tool definitions de un LLM, pero con semántica física.
Tres formas de control. El agente puede operar el dispositivo por MCP, por línea de comandos o desde código (APIs). MHS no necesita IA: un humano o un script pueden usarlo igual.
Límites de seguridad en el dispositivo. Los límites se aplican a nivel de equipo, no de modelo. En las pruebas de Carnegie Mellon, MHS bloqueó seis fallos provocados a propósito, entre ellos una parada de emergencia activa, antes de que ningún dispositivo se moviera.

Lo que más me gustó es que MHS no asume que el agente es "bueno" o "alineado". Asume que el agente puede equivocarse y obliga al hardware a defenderse. Es la misma filosofía que el sandboxing que discutimos hace poco: no confíes en el modelo, confina la acción.

El paralelo con MCP y por qué no es competencia

Si sigues el blog, ya te conté cómo MCP se convirtió en el estándar para que los agentes accedan a datos. Y también cubrimos WebMCP, su contraparte para la web. MHS es el tercer pilar de la misma idea, apuntando al mundo físico.

La relación no es competitiva, y de hecho MCP es una de las tres vías para controlar un dispositivo MHS:

MCP responde: "¿qué herramientas y datos tiene disponibles mi agente?"
WebMCP responde: "¿qué puede hacer mi agente en un sitio web?"
MHS responde: "¿qué puede hacer mi agente con un dispositivo físico, y dentro de qué límites?"

Para los developers: si ya piensas tus agentes en términos de MCP servers, MHS es el siguiente paso lógico. La abstracción mental es la misma: el agente no toca el recurso directamente, pasa por un contrato estándar que describe capacidades y límites.

Esto también explica por qué Anthropic puso MHS en research preview en vez de soltarlo cerrado: necesita feedback de laboratorios, fabricantes y equipos de seguridad antes de congelar la especificación. La primera cohorte incluye grupos de investigación científica y fabricantes avanzados, y empresas como Tecan, AWS o Universal Robots ya están añadiendo soporte en sus productos.

Qué cambia para ti como developer

Si no trabajas con robots ni con equipamiento de laboratorio, es válido preguntarse: ¿y a mí qué me importa? La respuesta corta: más de lo que piensas, por tres razones.

Primero, la integración deja de ser artesanal. Si MHS cumple lo que promete, escribir el driver de un tipo de dispositivo se hace una vez y cualquier agente compatible lo puede usar. Es la misma lógica que hizo explotar el ecosistema de MCP servers durante el último año.

Segundo, el ecosistema open source se va a mover. Carnegie Mellon ya anunció que publicará sus drivers, y en cuanto la especificación se libere es esperable ver implementaciones en los frameworks de robótica más usados. Si mantienes un agente open source que toca hardware, te conviene estar en esa conversación pronto. Y si tu agente es 100% digital, la idea de "describir capacidades y límites, y hacerlos cumplir fuera del modelo" se traslada tal cual: tu "dispositivo" puede ser una API, una base de datos o un navegador.

Tercero, abre una ventana concreta para construir productos. Hoy, quien quiere ofrecer "agentes que controlan el hardware X" tiene que reinventar la rueda de seguridad cada vez. Con un estándar común, ese trabajo se hace una vez por tipo de dispositivo.

El detalle que más me hizo ruido: los límites viven en el dispositivo

De todo el anuncio, lo que más me llamó la atención es dónde ponen la seguridad. Los límites no son una instrucción en el prompt ni una regla del harness: están en el archivo de referencia del dispositivo y se aplican en el driver. Si el agente pide algo fuera de rango, el hardware no lo ejecuta, sin importar qué modelo esté al otro lado.

Por qué importa: cuando un agente se equivoca en software, depuras. Cuando un agente se equivoca con un brazo robótico o un láser, necesitas que el error no llegue a ejecutarse. Que el freno esté en el dispositivo, y no en el modelo, es lo que hace que esto sea aplicable en el mundo real.

Lo que el anuncio no cubre es la auditoría: no habla de logs de acciones ni de trazabilidad. Para entornos regulados (salud, farmacéutica, investigación clínica) es lo primero que van a pedir, así que es uno de los huecos a vigilar.

Para equipos que ya lidian con sandboxing y prompt injection en coding agents (el caso de los agentes que se hablan entre sí es un buen ejemplo de la complejidad creciente), MHS es un recordatorio útil: la próxima frontera de la seguridad agéntica no es solo "que el modelo no haga cosas malas", sino "que el sistema no le deje hacerlas aunque lo intente".

Qué falta y qué mirar de aquí a fin de año

MHS es research preview, no una especificación final. Lo que falta ver:

Adopción fuera de Anthropic. Si OpenAI, Google y los frameworks open source lo implementan, MHS se vuelve estándar de facto. Si no, queda como propuesta de un vendor.
La liberación como open source. Anthropic dice que lo hará después del preview, sin fecha. Hasta entonces, el estándar es abierto en intención, no en código.
Herramientas de desarrollo. Hacen falta emuladores, simuladores y suites de testing compatibles con MHS, igual que existen los MCP inspectors. Sin eso, desarrollar contra MHS es engorroso.
Casos de uso en producción. Los laboratorios y fabricantes de la primera cohorte van a contar sus experiencias en los próximos meses. Esos reportes van a definir si MHS sirve igual para un brazo industrial, un microscopio o un láser, o si cada caso necesita su propia variante.

Si te interesa el cruce entre agentes y hardware, este es el momento de mirar MHS con atención. El estándar todavía está abierto a feedback, y los comentarios que lleguen ahora pesan más que los de después. Igual que pasó con MCP, los primeros seis meses definen quién se sube a la ola y quién llega tarde.