Model Hardware Standard di Anthropic: come MHS consente agli agenti AI di controllare hardware e in cosa differisce da MCP

Il 27 agosto 2026 Anthropic ha aperto un research preview del Model Hardware Standard (MHS), una specifica condivisa pensata per consentire agli agenti AI di scoprire, descrivere e utilizzare in modo più sicuro apparecchiature fisiche programmabili.^[1]

MHS è nato da una collaborazione tra Anthropic e HHMI Janelia Research Campus. I primi progetti hanno collegato microscopi, liquid handler, bracci robotici, plate reader e componenti del sistema laser di un computer quantistico.^[1]

Finora la maggior parte degli agenti AI ha operato soprattutto nel mondo digitale:

file
repository
terminale
API
browser
database
sistemi SaaS

MHS prova a standardizzare uno strato ulteriore:

sensori
telecamere
microscopi
robot da laboratorio
bracci robotici
laser
strumenti di misura
macchinari di produzione

Non bisogna però descrivere l’annuncio come “Claude ora controlla qualsiasi macchina”. MHS è attualmente un research preview limitato, l’accesso avviene tramite candidatura e lo standard non è ancora stato pubblicato come open source. Anthropic dichiara di volerlo aprire dopo la preview e ulteriori lavori sulla sicurezza, ma al 30 agosto non ha pubblicato né una data né una licenza per la futura versione aperta.^[1][2]

MHS non è neppure un nuovo modello AI e non sostituisce il Model Context Protocol (MCP). Anthropic lo definisce model-agnostic. MCP è uno dei tre meccanismi attraverso cui un agente può controllare hardware descritto da MHS; gli altri sono CLI e file di codice/API.^[1]

Conclusione principale: MHS non è “MCP 2.0” e non è un robot. È il tentativo di creare uno strato comune di driver, descrizione dei dispositivi e limiti fisici di sicurezza, così che un agente possa usare macchine diverse tramite un’interfaccia più coerente.

Stato delle informazioni: 30 agosto 2026.

TL;DR

Domanda	Risposta verificata
Cosa ha annunciato Anthropic?	Research preview di Model Hardware Standard
Quando?	27 agosto 2026
Cos’è MHS?	Specifica comune e layer di driver per hardware programmabile
È un nuovo modello Claude?	No
È già open source?	No
Anthropic prevede open source?	Sì, dopo preview e lavoro sulla sicurezza
C’è una data?	No
C’è una licenza futura nota?	Non indicata nei materiali ufficiali verificati
MHS sostituisce MCP?	No
Come usa MCP?	MCP è uno dei meccanismi di controllo
Altri meccanismi	CLI e code/API files
Funziona solo con Claude?	No, è model-agnostic
Quale hardware?	Dispositivi con interfaccia programmabile; i piloti includono laboratorio e robotica
Metrica pubblica più forte	QuEra: 695/700 relock laser corretti, 99,3%
È un benchmark indipendente?	No, è un risultato di un pilot partner
Rischio principale	Gli errori dell’agente possono avere effetti fisici
Principio chiave	Limiti e interlock devono essere applicati fuori dal modello

Cos’è esattamente il Model Hardware Standard?

Anthropic definisce MHS una shared specification for AI agents to safely operate physical devices.^[1]

Un laboratorio o una linea produttiva può contenere strumenti di molti vendor, ognuno con SDK, API, formati dati, applicazioni, documentazione e modelli di errore differenti. Collegarli spesso richiede bespoke glue code.

Anthropic afferma che queste integrazioni possono richiedere settimane o mesi e che MHS può ridurre parte del lavoro a ore o minuti.^[1] È una dichiarazione del produttore, non un benchmark indipendente dell’intero settore.

MHS non è un robot e non è un modello

MHS non è:

• un nuovo modello Claude,
• un sistema operativo robotico,
• una nuova classe di robot,
• un sostituto del firmware,
• un algoritmo autonomo di motion planning,
• un protocollo industriale che sostituisce tutti i sistemi di controllo.

È più corretto considerarlo uno strato di interoperabilità tra agente e hardware fisico programmabile.

L’agente continua ad avere bisogno di modello, harness o applicazione, permessi, driver, interfaccia hardware e protezioni fisiche indipendenti.

Come funziona MHS?

3.1. Driver standardizzato

MHS introduce un driver che traduce le operazioni fra computer e dispositivo.^[1]

Anthropic cita primitive semplici:

read
write

per esempio:

read temperature
write temperature

Non significa che un dispositivo abbia solo due comandi: operazioni complesse possono essere costruite sopra primitive comuni.

3.2. Descrizione standard del dispositivo

MHS rende i dispositivi discoverable in un formato comune, permettendo ad agenti e altri sistemi di trovarli in rete e comprenderne le capacità.^[1]

La descrizione può includere:

• cosa misura il dispositivo,
• quali parametri sono modificabili,
• caratteristiche fisiche,
• vincoli,
• limiti di sicurezza applicati.

Anthropic cita il peso di un braccio robotico come informazione fisica importante per una manipolazione sicura.^[1]

3.3. Tag in linguaggio naturale

Gli utenti possono descrivere proprietà importanti con tag in linguaggio naturale, direttamente oppure attraverso un agente che li intervista sul setup.^[1]

Il driver genera quindi un file di riferimento con caratteristiche, misure, parametri modificabili e safety limits.

Il post pubblico non è una documentazione completa dello schema. Finché MHS resta in preview limitata, non è corretto inventare campi o sintassi presentandoli come ufficiali.

Tre meccanismi di controllo

Anthropic ne elenca tre:^[1]

1. MCP
2. CLI
3. code files / APIs

MCP

Un agente può accedere all’hardware tramite Model Context Protocol. I server MCP possono esporre tools, funzioni eseguibili che il modello può scoprire e invocare.^[4][5]

CLI

L’hardware può anche essere controllato da riga di comando, utile per operatori, scripting, debug e test.

Code files e API

Un agente può combinare i comandi di uno o più dispositivi in codice tradizionale. Anthropic evidenzia questa via per operazioni rapide, ripetibili o lunghe, dove il LLM non dovrebbe fare reasoning a ogni micro-passaggio.^[1]

L’agente può imparare una procedura e poi uscire dal loop

Un modello generativo non deve controllare l’hardware ogni millisecondo.

In un esempio Claude:

1. regolava un laser,
2. osservava il risultato con una telecamera,
3. ripeteva l’esperimento,
4. riconosceva le relazioni,
5. convertiva la procedura in codice deterministico.^[1]

Dopo, lo script poteva funzionare senza reasoning continuo.

Pattern di produzione:

AI esplora
   ↓
AI crea procedura
   ↓
umani / test verificano
   ↓
codice deterministico esegue

QuEra ha usato questo schema per il controller di relock laser: l’agente ha aiutato a sviluppare e validare, ma la logica finale è software deterministico ispezionabile senza modello online a runtime.^[7]

MHS vs MCP: differenza principale

Elemento	MCP	MHS
Obiettivo	Collegare applicazioni AI a tools, dati e sistemi	Standardizzare descrizione e controllo di hardware fisico
Target	Software, API, dati, tools	Dispositivi fisici programmabili
Modello	Host, client, server, JSON-RPC	Driver + descrizione hardware + meccanismi di controllo
Tools	Sì	Possono essere esposti via MCP
CLI	Non è il modello centrale	Una via di controllo documentata
API/code files	Possono esistere dietro MCP	Una via documentata
Limiti fisici	Non sono il focus principale di MCP	Parte della semantica MHS
Open source oggi	Sì	Non ancora
Stato	Protocollo aperto	Research preview limitato

Anthropic ha pubblicato MCP nel 2024 come standard aperto per connessioni bidirezionali fra sistemi AI, fonti dati e tools.^[4] La documentazione descrive host-client-server, capability negotiation, tools, resources e prompts.^[5][6]

MHS non sostituisce questo layer.

Stack concettuale:

MODEL / AGENT
      │
      ├── MCP
      ├── CLI
      └── CODE / API
             │
          MHS DRIVER
             │
      DEVICE INTERFACE
             │
       PHYSICAL HARDWARE

È un diagramma POLPROG, non un diagramma ufficiale Anthropic.

MHS è “MCP per il mondo fisico”?

Come slogan è utile, ma troppo semplificato.

Entrambi riducono integrazioni bespoke e forniscono un’interfaccia comune.

La differenza fondamentale: MCP è un protocollo di comunicazione per sistemi AI e tools. MHS aggiunge la semantica del dispositivo fisico, stato, capacità e limiti.

MHS può usare MCP.

Meglio dire:

MHS completa MCP con uno strato per hardware fisico.

MHS è model-agnostic

Anthropic dichiara esplicitamente che MHS è model-agnostic e può essere usato da qualsiasi agent harness tramite protocolli standard come MCP.^[1]

Non è formalmente limitato a Claude o Claude Code.

I case study pubblici riguardano soprattutto Claude perché provengono da Anthropic e dai partner. Non esiste ancora un benchmark indipendente che confronti più modelli sullo stesso hardware e con gli stessi driver.

La sicurezza deve esistere sotto il modello

Nel software un tool call errato può eliminare un file. Nel mondo fisico può causare una collisione, rovesciare una provetta o danneggiare un dispositivo.

Un prompt non può essere l’unica protezione.

MHS può trasmettere safety limits applicati.^[1] QuEra dichiara che bounds, interlock ed emergency stop erano applicati all’interfaccia hardware indipendentemente dal modello.^[7]

Architettura appropriata:

MODEL
propone

POLICY / APPROVAL
accetta o rifiuta

DRIVER / CONTROLLER
applica limiti

HARDWARE INTERLOCK
protegge anche se il software sbaglia

Genentech: un errore fisico inizialmente frainteso

Genentech ha testato MHS in un BCA protein assay con liquid handler, braccio robotico e microplate reader.^[1]

Durante il mixing si formarono bolle che causavano runtime errors. Claude inizialmente trattò il problema come software e ritentò nello stesso well con parametri diversi, generando ancora più bolle.^[1]

Gli esperti dovettero spiegare la causa fisica, suggerire un well pulito e un mixing più delicato. Il team codificò poi la lezione in reusable liquid-handling skills.^[1]

Lezione:

Un modello può capire il messaggio d’errore e contemporaneamente non capire la fisica che lo genera.

University of Washington: sei strumenti in meno di una settimana

I laboratori Baker e Pinglay hanno usato MHS per monitoraggio remoto, qPCR supervisionato da agente e coordinamento tra braccio robotico e liquid handler.^[1]

In un plate handoff il liquid handler terminava, l’agente riceveva il segnale e circa dieci secondi dopo attivava il braccio. Il report indica assenza di collisioni nei test ripetuti.

Collegare sei strumenti, compresi i driver, avrebbe richiesto meno di una settimana.^[1]

È un risultato locale, non una garanzia.

Carnegie Mellon: sei condizioni di sicurezza indotte

Un team Carnegie Mellon ha usato MHS per esperimenti serial dilution dose-response.^[1]

Il setup comprendeva liquid handler, plate reader, braccio robotico, telecamere e tre computer con interfacce incompatibili.

I ricercatori hanno indotto:

1. piastra mancante,
2. piastra ruotata,
3. reader occupato,
4. camera scollegata,
5. dispositivo irraggiungibile,
6. emergency stop attivo.^[1]

Secondo il report, tutti e sei furono bloccati prima che qualunque dispositivo si muovesse.

È un buon proof-of-concept, non una certificazione.

Correzione autonoma

Il primo run aveva:

R² < 0,9

L’agente ridusse la concentrazione massima:

200 µg/mL
→
100 µg/mL

Il secondo run ottenne:

R² > 0,98

senza intervento umano.^[1]

Il team riporta circa 8 ore dal setup non automatizzato ma pronto a una curva completata con rerun autonomo, contro settimane per una tipica integrazione vendor.^[1]

HHMI Janelia: uno stato condiviso per sette programmi

In un progetto Janelia una ricercatrice doveva avviare sette programmi in un ordine fisso.

MHS ha sostituito le connessioni punto-punto con uno state dictionary condiviso in memoria.^[1]

Secondo il caso:

• aggiungere una nuova camera ha richiesto minuti anziché giorni,
• l’avvio è passato da sette step a una sola operazione,
• i data stream hanno potuto usare tools riutilizzabili indipendentemente dal software vendor.^[1]

MHS applicava anche limiti come la potenza massima del laser, per evitare che l’agente superasse il range sicuro per il campione.^[1]

QuEra: 695 relock riusciti su 700

Il pilot più quantitativo viene da QuEra Computing.

QuEra ha usato MHS per dare a Claude accesso a parte del sistema laser di un computer quantistico.^[1][7][8]

Dopo la fase sperimentale è nato un controller deterministico.

QuEra ha eseguito:

700 test
7 classi di disturbo
100 test per classe

Risultato:

695 / 700
=
99,3%

^[7]

Guasti semplici:

0,9–5,4 s

più difficili:

10–14 s

contro:

5–10 minuti

per un esperto umano.^[7]

Non è un benchmark Claude al 99,3%

Nel blind test finale l’agente non controllava il laser online.

Corretto:

Un agente con MHS ha aiutato a sviluppare un controller che poi ha raggiunto 99,3%.

Non corretto:

Claude controlla hardware con accuratezza del 99,3%.

Divergenza nelle fonti

Anthropic descrive il precedente script QuEra come un lavoro durato “several months”.^[1]

QuEra parla di circa 2–3 settimane.^[7]

Poiché le fonti divergono, non usiamo quel tempo come metrica comparativa.

Limiti emersi dal pilot QuEra

I report descrivono anche limiti.

Claude:

• non riusciva a diagnosticare alcuni guasti puramente fisici,
• comprendeva il rig soprattutto in modo programmatico,
• richiedeva molto contesto,
• talvolta fermava l’esperimento per chiedere conferma umana su azioni leggermente rischiose.^[1]

Nel mondo fisico, questa cautela può essere preferibile all’eccessiva sicurezza.

Tetsuwan: un dispositivo rileva il problema, un altro lo risolve

Tetsuwan ha integrato MHS con ResearchOS per un workflow qPCR relativo a San Pedro Creek.^[1]

Una camera rilevava bolle. Il robot che teneva il campione non poteva eliminarle.

Il sistema:

1. rilevava il problema,
2. cercava dispositivi MHS,
3. trovava una centrifuge,
4. Claude proponeva di usarla,
5. dopo approvazione emetteva i comandi.^[1]

È un esempio di recovery cross-device invece di workflow completamente hard-coded.

Ecosistema partner

Anthropic cita:^[1]

• Amazon Web Services,
• Automata,
• Danaher,
• Doosan Robotics,
• MBF Bioscience,
• QIAGEN,
• Tecan,
• Universal Robots,
• Hugging Face,
• Raspberry Pi.

AWS prevede supporto via Strands Robots, Hugging Face lavora su LeRobot e Raspberry Pi su alcune integrazioni.^[1]

Non significa che ogni integrazione sia già production-ready e pubblica.

MHS non è ancora open source

Il sito ufficiale parla di limited research preview.^[2]

Anthropic vuole prima raccogliere esperienza, costruire safety evaluations, sviluppare best practices e rafforzare safeguards.^[1]

Al 30 agosto 2026 non sono pubblicati:

• data dell’open-source release,
• licenza finale,
• specifica pubblica completa paragonabile a MCP.

Quindi:

Anthropic prevede di rendere MHS open source.

è corretto.

MHS è già open source.

non lo è.

I risultati sono benchmark indipendenti?

No.

I numeri pubblici provengono soprattutto da Anthropic e dai partner della preview.

Reuters conferma indipendentemente il lancio del preview, l’ambito generale e il piano di apertura futura.^[3]

Non esiste ancora un benchmark con stesso hardware, stessi driver, più modelli, stesso harness e grading indipendente.

Valori come:

99,3%
3× più veloce
8 ore
meno di una settimana

devono restare associati ai singoli pilot.

Threat model: cosa può andare storto?

Reasoning errato

Il modello può interpretare male sensori, error code, immagini o cause fisiche. Genentech mostra un caso reale.^[1]

Driver errato o malevolo

Unità sbagliate, stato falso o assenza di validazione possono ingannare l’agente.

Prompt injection

Testi nelle immagini, documentazione e dati di rete possono contenere istruzioni dannose.

Confused deputy

Un agente con accesso a più macchine può usare lo strumento corretto per uno scopo sbagliato.

Race conditions

Due agenti possono modificare contemporaneamente lo stesso stato fisico.

Perdita di connessione

Serve un safe state se falliscono modello, MCP, rete, driver o sensore.

Architettura di produzione più sicura

MODEL / AGENT
      ↓
POLICY + APPROVAL
      ↓
MCP / CLI / API
      ↓
MHS DRIVER
      ↓
DETERMINISTIC CONTROLLER
      ↓
HARDWARE INTERLOCK / E-STOP
      ↓
PHYSICAL HARDWARE

È una raccomandazione POLPROG, non un diagramma ufficiale Anthropic.

Un LLM non dovrebbe essere l’unico componente che decide se un’operazione fisica è sicura.

Cosa deve imporre il layer deterministico?

Per esempio:

• range di temperatura,
• potenza massima,
• velocità del braccio,
• limiti dello spazio operativo,
• sequenza dei movimenti,
• collision zones,
• limiti di pressione,
• stato delle protezioni,
• emergency stop,
• durata massima.

Una richiesta fuori range deve essere respinta indipendentemente dal reasoning.

Human-in-the-loop resta importante

La specifica MCP Tools raccomanda che l’utente possa negare tool invocations.^[5]

Per hardware:

READ
automatico

LOW-RISK WRITE
automatico entro range ristretto

MEDIUM-RISK
policy + validazione

HIGH-RISK
human approval

EMERGENCY / UNSAFE
sempre bloccato

Perché il fallback deterministico è importante

QuEra mostra un pattern pratico:

AI scopre soluzione
→ genera codice
→ test e umani verificano
→ produzione esegue software deterministico

Riduce costo, latency, nondeterminism, dipendenza dall’API e rischio di decisioni inattese.

MHS e sistemi industriali

MHS non va considerato un sostituto di PLC, SCADA, OPC UA, safety PLC o controller real-time.

Più realisticamente sta sopra:

agente
↓
orchestration
↓
MHS
↓
controller esistenti
↓
hardware

Anthropic mostra che operazioni rapide o lunghe possono essere trasformate in codice per evitare reasoning LLM a ogni step.^[1]

Chi dovrebbe seguire MHS ora?

In particolare:

• laboratori multi-vendor,
• biotech e pharma,
• microscopy,
• robotica,
• quantum computing,
• advanced manufacturing,
• team R&D con molto bespoke integration code.

Chi dovrebbe essere prudente?

Quando:

• il sistema è safety-critical,
• serve una specifica pubblica stabile,
• serve una licenza open-source nota,
• sono richiesti standard industriali certificati,
• l’hardware non ha interfaccia automatizzabile,
• mancano interlock indipendenti,
• il team non sa auditare i driver.

Un research preview non è uno standard industriale maturo.

Come preparare un’azienda

Step 1: inventario

vendor
model
SDK/API/GUI
unità
stati
comandi
limiti
E-stop
dipendenze

Step 2: separare read e write

Definire cosa può essere letto, modificato, automatizzato o richiede approval.

Step 3: togliere la sicurezza dal prompt

Non affidarsi a:

"non superare mai 80°C"

Il limite reale deve essere imposto da codice o hardware.

Step 4: loggare tutto

Agent/model, operazione, parametri, stato prima/dopo, risultato, timestamp, policy e approval.

Step 5: simulare prima

digital twin / mock driver

poi:

real hardware

Piano minimo di test

Driver

• unità,
• range,
• timeout,
• reconnect,
• risposte invalide,
• restart.

Agent

• sensore errato,
• dati contraddittori,
• error code ignoto,
• prompt injection,
• contesto mancante.

Hardware

• collision prevention,
• E-stop,
• power loss,
• network loss,
• blocco meccanico,
• out-of-range values.

Multi-agent

• write simultanei,
• stale state,
• resource locking,
• retry dopo timeout.

Checklist sicurezza MHS

Architettura

• Il modello non controlla actuator senza validazione.
• Ogni driver ha limiti espliciti.
• Valori con unità e range.
• Limiti critici deterministici.
• E-stop indipendente dall’AI.
• Safe state dopo perdita connessione.
• Device state con timestamp.
• Retry sicuro.

Permessi

• L’agente vede solo i dispositivi necessari.
• READ e WRITE separati.
• High-risk actions richiedono approval.
• I permessi scadono.
• Nessun admin token globale.

Monitoring

• Ogni tool call è loggato.
• Cambiamenti fisici generano telemetria.
• Gli allarmi non dipendono solo dal modello.
• L’operatore vede lo stato.
• Event replay disponibile.
• Errori classificati.

Test

• Mock hardware.
• Physical sandbox.
• Fault injection.
• Prompt injection.
• Race conditions.
• Network partition.
• Agent restart.
• Driver restart.
• Unità errate.
• Out-of-range values.

Produzione

• Rollout parte read-only.
• Poi low-risk writes.
• Safety-critical actions fuori dall’agente.
• Codice deterministico sostituisce AI quando possibile.
• Driver con code review.
• Rollback disponibile.
• Controllo manuale disponibile.
• Il team conosce l’effetto fisico dei comandi.

Cosa serve perché MHS diventi un vero standard?

Serviranno:

1. specifica pubblica,
2. versioning stabile,
3. modello di compatibilità,
4. SDK pubblici,
5. licenza open-source,
6. reference drivers,
7. conformance tests,
8. security evaluations,
9. implementazioni indipendenti,
10. supporto vendor,
11. validazione driver,
12. permission model chiaro.

MCP è diventato rilevante grazie a un ecosistema interoperabile. MHS dovrà seguire una strada simile.

MHS cambierà la robotica?

Forse, ma è presto.

Il fit più immediato è dove l’hardware è già programmabile, integrare costa e i workflow cambiano:

laboratori
R&D
biotech
microscopy
quantum
advanced manufacturing

MHS non risolve automaticamente robot perception, motion planning, real-time control, safety certification o fisica della manipolazione.

Può però semplificare l’interfaccia con sistemi di controllo esistenti.

Verdetto POLPROG

Model Hardware Standard è uno degli sviluppi agentic più interessanti del 2026 perché porta il problema dell’interoperabilità dal digitale al fisico.

Cosa è confermato?

• research preview dal 27 agosto 2026.^[1][3]
• origine Anthropic + HHMI Janelia.^[1]
• model-agnostic.^[1]
• controllo via MCP, CLI e code/API files.^[1]
• driver con descrizione dispositivo e safety limits.^[1]
• Anthropic prevede open source successivamente.^[1][2]
• QuEra conferma 695 relock riusciti su 700 per il controller finale.^[7]

Cosa non sappiamo ancora?

• schema pubblico finale,
• data open-source,
• licenza,
• stabilità API,
• compatibilità fra implementazioni,
• benchmark indipendente,
• comportamento di modelli diversi sullo stesso hardware.

Il pattern più promettente

Non:

LLM controlla tutto continuamente

ma:

agente comprende l’obiettivo
→ esplora uno spazio sicuro
→ coordina dispositivi
→ crea o sceglie procedura
→ il sistema valida
→ il lavoro ripetibile passa a codice deterministico

Se Anthropic aprirà davvero la specifica, i vendor pubblicheranno driver riutilizzabili e team indipendenti convalideranno sicurezza e interoperabilità, MHS potrebbe diventare uno strato importante per physical AI.

Non siamo ancora a quel punto.