Anthropic Model Hardware Standard: hoe MHS AI-agents hardware laat bedienen en hoe het verschilt van MCP

Op 27 augustus 2026 opende Anthropic een research preview van de Model Hardware Standard (MHS), een gedeelde specificatie die AI-agents programmeerbare fysieke apparaten veiliger moet laten ontdekken, beschrijven en bedienen.^[1]

MHS ontstond aanvankelijk uit samenwerking tussen Anthropic en HHMI Janelia Research Campus. In vroege pilots werd de standaard gebruikt met microscopen, liquid handlers, robotarmen, plate readers en onderdelen van het lasersysteem van een quantumcomputer.^[1]

De meeste bekende AI-agents werkten tot nu toe vooral in een digitale omgeving:

bestanden
repositories
terminal
API's
browser
databases
SaaS-systemen

MHS probeert een volgende laag te standaardiseren:

sensoren
camera's
microscopen
laboratoriumrobots
robotarmen
lasers
meetinstrumenten
productieapparatuur

De aankondiging betekent echter niet dat “Claude nu elk apparaat kan besturen”. MHS is momenteel een beperkte research preview, toegang verloopt via een aanvraag en de standaard is nog niet publiek als open source uitgebracht. Anthropic zegt MHS na de preview en aanvullende veiligheidswerkzaamheden open source te willen maken, maar op 30 augustus is er geen publieke releasedatum of toekomstige licentie bekendgemaakt.^[1][2]

MHS is evenmin een nieuw AI-model en vervangt Model Context Protocol (MCP) niet. Anthropic noemt MHS model-agnostic. MCP is één van drie mechanismen waarmee een agent MHS-hardware kan bedienen; de andere twee zijn CLI en codebestanden/API's.^[1]

Belangrijkste conclusie: MHS is geen “MCP 2.0” en geen robot. Het is een poging om één gemeenschappelijke laag voor drivers, apparaatbeschrijvingen en fysieke veiligheidsgrenzen te creëren, zodat agents verschillende machines via een consistenter interface kunnen gebruiken.

Informatiestatus: 30 augustus 2026.

TL;DR

Vraag	Geverifieerd antwoord
Wat kondigde Anthropic aan?	Een research preview van Model Hardware Standard
Wanneer?	27 augustus 2026
Wat is MHS?	Een gedeelde specificatie en driverlaag voor programmeerbare hardware
Is MHS een nieuw Claude-model?	Nee
Is MHS nu open source?	Nee
Wil Anthropic het open source maken?	Ja, na de preview en veiligheidswerkzaamheden
Is er een releasedatum?	Nee
Is de toekomstige licentie bekend?	Niet in de gecontroleerde officiële bronnen
Vervangt MHS MCP?	Nee
Welke rol heeft MCP?	MCP is één controlemechanisme voor MHS-hardware
Andere mechanismen	CLI en code/API-bestanden
Werkt MHS alleen met Claude?	Nee, Anthropic noemt het model-agnostic
Welke hardware?	Apparatuur met programmeerbare interface; pilots omvatten laboratorium- en robotica-apparatuur
Sterkste publieke pilotmetriek	QuEra: 695/700 succesvolle laser-relocks, 99,3%
Is dat een onafhankelijke benchmark?	Nee, het is een partnerpilot
Grootste risico	Een agentfout kan fysieke gevolgen hebben
Belangrijkste veiligheidsregel	Limieten en interlocks moeten buiten het model worden afgedwongen

Wat is Model Hardware Standard precies?

Anthropic omschrijft MHS als een shared specification for AI agents to safely operate physical devices.^[1]

Het onderliggende probleem is bekend. Een laboratorium of productielijn gebruikt vaak apparaten van verschillende vendors, elk met een eigen SDK, API, dataformaat, desktopsoftware, documentatie en foutmodel.

Om meerdere apparaten in één workflow te combineren is daardoor vaak bespoke glue code nodig.

Anthropic stelt dat zulke integraties weken of maanden kunnen duren en dat MHS een deel daarvan naar uren of minuten kan terugbrengen.^[1] Dat is een claim van de leverancier, geen onafhankelijke benchmark voor de hele industrie.

MHS is geen robot en geen model

MHS is niet:

• een nieuw Claude-model,
• een robotbesturingssysteem,
• een nieuw type robot,
• een vervanging van firmware,
• een zelfstandig motion-planning-algoritme,
• een industrieel netwerkprotocol dat alle bestaande besturing vervangt.

Het is beter te zien als een interoperabiliteitslaag tussen een agent en programmeerbare fysieke apparatuur.

Een agent heeft nog steeds een model, harness of applicatie, permissies, een apparaatdriver, het echte hardware-interface en onafhankelijke fysieke beveiligingen nodig.

Hoe werkt MHS?

3.1. Gestandaardiseerde driver

MHS introduceert een standaarddriver die bewerkingen tussen computer en apparaat vertaalt.^[1]

Anthropic noemt eenvoudige primitives:

read
write

bijvoorbeeld:

read temperature
write temperature

Dat betekent niet dat ieder apparaat maar twee opdrachten heeft. Complexere functies kunnen op een kleine, consistente set basisoperaties worden gebouwd.

3.2. Gestandaardiseerde apparaatbeschrijving

MHS maakt apparaten discoverable in een uniform formaat, zodat agents en andere machines ze op het netwerk kunnen vinden en begrijpen wat ze kunnen.^[1]

De beschrijving kan bevatten:

• wat het apparaat meet,
• welke parameters kunnen veranderen,
• fysieke eigenschappen,
• relevante beperkingen,
• afgedwongen veiligheidsgrenzen.

Anthropic noemt het gewicht van een robotarm als voorbeeld van fysieke informatie die voor veilige manipulatie van belang kan zijn.^[1]

3.3. Natural-language tags

Gebruikers kunnen belangrijke eigenschappen via natural-language tags beschrijven, rechtstreeks of via een agent die vragen over de setup stelt.^[1]

De driver genereert vervolgens een referentiebestand met kenmerken, metingen, instellingen en safety limits.

De publieke aankondiging is geen volledige schema-documentatie. Omdat MHS nog in beperkte preview zit, moeten veldnamen of configuraties niet worden verzonnen en als officieel formaat worden gepresenteerd.

Drie manieren om hardware te bedienen

Anthropic noemt drie mechanismen:^[1]

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

MCP

Een agent kan hardware via Model Context Protocol gebruiken. MCP-servers kunnen tools aanbieden, uitvoerbare functies die een model kan ontdekken en aanroepen.^[4][5]

CLI

Apparatuur kan ook rechtstreeks via de commandline worden bediend, nuttig voor operators, scripts, debugging en integratietests.

Codebestanden en API's

Een agent kan opdrachten van één of meerdere apparaten in gewone code combineren. Anthropic benadrukt dit voor snelle, herhaalbare en langlopende taken waarbij een LLM niet over iedere microstap hoeft te redeneren.^[1]

Een agent kan een procedure leren en daarna uit de regelkring verdwijnen

Een generatief model hoeft hardware niet iedere milliseconde aan te sturen.

In een voorbeeld:

1. veranderde Claude een laserinstelling,
2. observeerde het resultaat met een camera,
3. herhaalde experimenten,
4. leerde de relatie tussen acties en resultaten,
5. zette de procedure om in deterministische code.^[1]

Daarna kon het script zonder voortdurend model-reasoning draaien.

Een belangrijk productiepatroon is:

AI verkent
   ↓
AI maakt een procedure
   ↓
mensen / tests verifiëren
   ↓
deterministische code voert uit

QuEra gebruikte dit patroon voor zijn laser-relockcontroller: de agent hielp bij ontwikkeling en validatie, maar de uiteindelijke productielogica is inspecteerbare deterministische software zonder online model tijdens runtime.^[7]

MHS vs MCP: het belangrijkste verschil

Element	MCP	MHS
Hoofddoel	AI-apps verbinden met tools, data en systemen	Beschrijving en besturing van fysieke hardware standaardiseren
Typische target	Software, API's, data, tools	Programmeerbare fysieke apparaten
Model	Host, client, server, JSON-RPC	Driver + hardwarebeschrijving + controlemechanismen
Tools	Ja	Kunnen via MCP worden aangeboden
CLI	Niet het kernmodel	Een gedocumenteerde MHS-route
API/code files	Kunnen achter MCP bestaan	Een gedocumenteerde MHS-route
Fysieke limieten	Niet de primaire scope	Onderdeel van MHS-semantiek
Open source vandaag	Ja	Nog niet
Status	Open protocol	Beperkte research preview

Anthropic bracht MCP in 2024 uit als open standaard voor tweerichtingsverbindingen tussen AI-systemen, databronnen en tools.^[4] De huidige MCP-documentatie beschrijft host-client-server, capability negotiation, tools, resources en prompts.^[5][6]

MHS vervangt die laag niet.

Conceptueel:

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

Dit is een POLPROG-conceptdiagram, geen officieel Anthropic-diagram.

Is MHS “MCP voor de fysieke wereld”?

Als slogan is dat bruikbaar, maar technisch te simpel.

Beide projecten verminderen bespoke integraties en creëren een gemeenschappelijke interface.

Het fundamentele verschil: MCP is een communicatieprotocol voor AI-systemen en tools. MHS voegt semantiek toe over het fysieke apparaat, de toestand, mogelijkheden en beperkingen.

MHS kan MCP zelf gebruiken.

Nauwkeuriger is:

MHS vult MCP aan met een laag voor fysieke hardware.

MHS is model-agnostic

Anthropic zegt expliciet dat MHS model-agnostic is en dat elke agent harness via standaardprotocollen zoals MCP toegang kan krijgen.^[1]

Het concept is formeel dus niet beperkt tot Claude of Claude Code.

Publieke pilots draaien vooral om Claude omdat ze van Anthropic en previewpartners komen. Een brede onafhankelijke benchmark met meerdere modellen op identieke hardware, dezelfde driver en dezelfde taken bestaat nog niet.

Veiligheid moet onder de modellaag functioneren

In software kan een fout tool call een bestand verwijderen. In de fysieke wereld kan een verkeerde beslissing een robot laten botsen, een sample morsen of apparatuur beschadigen.

Een natural-language prompt mag daarom nooit de enige beveiliging zijn.

MHS kan afgedwongen safety limits doorgeven.^[1] QuEra meldt daarnaast dat bounds, interlocks en emergency stops op het hardware-interface onafhankelijk van het model werden afgedwongen.^[7]

Een passende architectuur:

MODEL
stelt actie voor

POLICY / APPROVAL
accepteert of weigert

DRIVER / CONTROLLER
dwingt limieten af

HARDWARE INTERLOCK
beschermt ook bij softwarefouten

Genentech: een fysieke fout die de agent eerst verkeerd begreep

Genentech testte MHS bij een BCA protein assay met liquid handler, robotarm en microplate reader.^[1]

Tijdens het mengen ontstonden bubbels die runtime errors veroorzaakten. Claude behandelde dit eerst als een softwareprobleem en probeerde hetzelfde well opnieuw met andere parameters. Daardoor ontstonden juist meer bubbels.^[1]

Menselijke experts moesten de fysieke oorzaak uitleggen en aangeven dat een schoon well en voorzichtiger mengen nodig waren. Daarna werd de kennis vastgelegd in reusable liquid-handling skills.^[1]

De les:

Een model kan een foutmelding begrijpen, maar de onderliggende fysica verkeerd interpreteren.

University of Washington: zes apparaten in minder dan een week

De Baker- en Pinglay-labs gebruikten MHS voor remote monitoring, door een agent bewaakte qPCR en coördinatie tussen een robotarm en liquid handler.^[1]

Bij een plate handoff eindigde de liquid handler, ontving de agent het signaal en startte ongeveer tien seconden later de robotarm. Volgens de beschrijving waren er bij herhaalde tests geen botsingen.

Het aansluiten van zes apparaten, inclusief driverontwikkeling, zou minder dan een week hebben gekost.^[1]

Dat is één laboratoriumcase, geen algemene garantie.

Carnegie Mellon: zes bewust geïnduceerde veiligheidscondities

Een team van Carnegie Mellon University gebruikte MHS voor serial dilution dose-response-experimenten.^[1]

De setup combineerde liquid handler, plate reader, robotarm, camera's en drie computers met incompatibele besturing.

De onderzoekers veroorzaakten zes condities:

1. ontbrekende plaat,
2. gedraaide plaat,
3. reader bezet,
4. camera losgekoppeld,
5. apparaat onbereikbaar,
6. emergency stop actief.^[1]

Volgens het rapport werden alle zes geblokkeerd voordat een apparaat bewoog.

Dat is een waardevolle proof of concept, geen formele veiligheidscertificering.

Autonome correctie

De eerste run had:

R² < 0,9

De agent verlaagde de maximale concentratie:

200 µg/mL
→
100 µg/mL

De tweede run haalde:

R² > 0,98

zonder menselijke interventie.^[1]

Het team rapporteert ongeveer 8 uur vanaf gereed maar niet-geautomatiseerd equipment tot een afgeronde curve inclusief autonome rerun, en vergelijkt dat met meerdere weken vendorintegratie.^[1]

HHMI Janelia: één toestandslaag voor zeven programma's

In één Janelia-project moest een onderzoeker eerder zeven programma's in een vaste volgorde starten.

MHS verving point-to-pointverbindingen door één shared state dictionary in gedeeld geheugen.^[1]

Volgens de case:

• kostte een nieuwe camera toevoegen minuten in plaats van dagen,
• werd starten teruggebracht van zeven stappen naar één actie,
• konden datastromen met herbruikbare tools worden geanalyseerd ongeacht de vendorapp.^[1]

MHS legde ook grenzen op zoals maximale laserpower zodat een agent niet buiten het veilige bereik voor het sample kon gaan.^[1]

QuEra: 695 succesvolle relocks van 700

De meest kwantitatieve publieke pilot komt van QuEra Computing.

QuEra gebruikte MHS om Claude toegang te geven tot een deel van het lasersysteem van een quantumcomputer.^[1][7][8]

Na de experimentele fase ontstond een deterministische controller.

QuEra voerde uit:

700 tests
7 verstoringsklassen
100 tests per klasse

Resultaat:

695 / 700
=
99,3%

^[7]

Eenvoudige fouten:

0,9–5,4 s

moeilijke:

10–14 s

tegenover:

5–10 minuten

voor een menselijke expert.^[7]

Dit is geen Claude-benchmark van 99,3%

In de final blind test bestuurde de agent de laser niet online.

Correct:

Een agent met MHS hielp een controller ontwikkelen die later 99,3% behaalde.

Niet correct:

Claude bestuurt hardware met 99,3% nauwkeurigheid.

Verschil tussen bronnen

Anthropic beschrijft het oudere handgeschreven QuEra-script als werk van “several months”.^[1]

QuEra zelf spreekt over ongeveer 2–3 weken.^[7]

Omdat de bronnen verschillen, gebruiken we die ontwikkeltijd niet als harde vergelijkingsmetriek.

Beperkingen uit de QuEra-pilot

De publieke beschrijvingen noemen ook zwakke punten.

Claude:

• kon sommige puur fysieke defecten niet diagnosticeren,
• begreep de rig vooral via de programmeerbare representatie,
• had veel context nodig,
• stopte soms en vroeg menselijke bevestiging voor acties die enig risico leken te hebben.^[1]

Bij fysieke hardware kan die voorzichtigheid beter zijn dan overconfidence.

Tetsuwan: één apparaat detecteert het probleem, een ander lost het op

Tetsuwan koppelde MHS aan ResearchOS voor een qPCR-workflow rond vervuiling van San Pedro Creek.^[1]

Een camera zag bubbels in een sample. De robot die het sample vasthield kon ze niet verwijderen.

Het systeem:

1. detecteerde het probleem,
2. doorzocht MHS-apparaten,
3. vond een centrifuge,
4. liet Claude voorstellen die te gebruiken,
5. stuurde na approval de opdrachten.^[1]

Dit laat cross-device recovery zien in plaats van volledig hard-coded workflows.

Partner-ecosysteem

Anthropic noemt onder meer:^[1]

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

AWS plant ondersteuning via Strands Robots, Hugging Face werkt aan LeRobot en Raspberry Pi aan integraties voor geselecteerde producten.^[1]

Dit betekent niet dat alle integraties vandaag publiek production-ready zijn.

MHS is nog niet open source

De officiële projectsite noemt het een limited research preview.^[2]

Anthropic wil eerst ervaringen verzamelen, safety evaluations ontwikkelen, best practices vastleggen en safeguards versterken.^[1]

Op 30 augustus 2026 zijn in de gecontroleerde officiële bronnen:

• geen publieke open-source-releasedatum,
• geen definitieve licentie,
• geen volledige publieke specificatie met de volwassenheid van MCP-documentatie.

Dus:

Anthropic is van plan MHS open source te maken.

is correct.

MHS is al open source.

is niet correct.

Zijn de resultaten onafhankelijke benchmarks?

Nee.

De publieke cijfers komen vooral van Anthropic en previewpartners.

Reuters bevestigt onafhankelijk de start van de preview, de algemene scope en het plan voor latere open source.^[3]

Maar er bestaat nog geen benchmark met identieke hardware, identieke drivers, meerdere modellen, één harness en onafhankelijke grading.

Getallen zoals:

99,3%
3× sneller
8 uur
minder dan een week

moeten dus altijd gekoppeld blijven aan de betreffende pilot.

Threat model: wat kan misgaan?

Verkeerd reasoning

Een model kan een sensor, error code, beeld of fysieke oorzaak verkeerd begrijpen. Genentech is een echt voorbeeld.^[1]

Foutieve of kwaadaardige driver

Verkeerde units, foute status of ontbrekende validatie kunnen de agent een vals beeld geven.

Prompt injection

Tekst in beelden, documentatie of netwerkdata kan kwaadaardige instructies bevatten.

Confused deputy

Een agent met meerdere apparaten kan het juiste tool voor het verkeerde doel inzetten.

Race conditions

Twee agents kunnen tegelijkertijd dezelfde fysieke toestand wijzigen.

Verbindingsverlies

Er moet een safe state bestaan als model, MCP, netwerk, driver of sensor uitvalt.

Een veiligere productiearchitectuur

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

Dit is een POLPROG-aanbeveling, geen officieel Anthropic-diagram.

Een LLM mag nooit de enige component zijn die bepaalt of een fysieke handeling veilig is.

Wat moet de deterministische laag afdwingen?

Bijvoorbeeld:

• temperatuurbereiken,
• maximaal vermogen,
• armsnelheid,
• werkgebied,
• bewegingsvolgorde,
• collision zones,
• druklimieten,
• beschermkapstatus,
• emergency stop,
• maximale duur.

Een request buiten het toegestane bereik moet worden geweigerd ongeacht het reasoning van het model.

Human-in-the-loop blijft belangrijk

De MCP Tools-specificatie adviseert dat gebruikers tool invocations moeten kunnen weigeren.^[5]

Voor hardware:

READ
automatisch

LOW-RISK WRITE
automatisch binnen klein bereik

MEDIUM-RISK
policy + extra validatie

HIGH-RISK
human approval

EMERGENCY / UNSAFE
altijd geblokkeerd

Waarom deterministische fallback belangrijk is

QuEra laat een praktisch patroon zien:

AI ontdekt oplossing
→ code wordt gegenereerd
→ tests en mensen verifiëren
→ productie draait deterministische software

Dit verlaagt inferencekosten, latency, nondeterminism, API-afhankelijkheid en het risico op onverwachte modelbeslissingen.

MHS en industriële besturingssystemen

MHS moet niet worden gezien als vervanging van PLC, SCADA, OPC UA, safety PLC of real-timecontrollers.

Waarschijnlijker zit het erboven:

agent
↓
orchestration
↓
MHS
↓
bestaande controllers
↓
hardware

Anthropic laat zelf zien dat snelle of langdurige bewerkingen in code kunnen worden verpakt zodat geen LLM-reasoning per stap nodig is.^[1]

Wie zou MHS nu moeten volgen?

Vooral:

• labs met multi-vendorapparatuur,
• biotech en pharma,
• microscopy,
• robotica,
• quantum computing,
• advanced manufacturing,
• R&D-teams met veel bespoke integration code.

Wie moet voorzichtig zijn?

Wanneer:

• het systeem safety-critical is,
• een stabiele publieke specificatie verplicht is,
• een bekende open-source-licentie vereist is,
• gecertificeerde industriestandaarden nodig zijn,
• hardware geen automatiseerbare interface heeft,
• onafhankelijke interlocks ontbreken,
• het team drivers niet kan auditen.

Een research preview is geen volwassen industriestandaard.

Hoe kan een organisatie zich voorbereiden?

Stap 1: inventaris

vendor
model
SDK/API/GUI
units
states
commands
limits
E-stop
dependencies

Stap 2: scheid read en write

Definieer wat gelezen, gewijzigd, automatisch uitgevoerd of goedgekeurd moet worden.

Stap 3: haal veiligheid uit de prompt

Vertrouw niet op:

"stel de temperatuur nooit boven 80°C"

Een echte limiet moet door code of hardware worden afgedwongen.

Stap 4: log alles

Agent/model, operatie, parameters, toestand voor/na, resultaat, timestamp, policy en approval.

Stap 5: simuleer eerst

digital twin / mock driver

en daarna:

real hardware

Minimaal testplan

Driver

• units,
• ranges,
• timeouts,
• reconnect,
• ongeldige antwoorden,
• restart.

Agent

• foutieve sensorwaarde,
• conflicterende data,
• onbekende error code,
• prompt injection,
• ontbrekende context.

Hardware

• collision prevention,
• E-stop,
• power loss,
• network loss,
• mechanische blokkade,
• out-of-range values.

Multi-agent

• gelijktijdige writes,
• stale state,
• resource locking,
• retry na timeout.

MHS-veiligheidschecklist

Architectuur

• Model bestuurt actuators niet zonder validatie.
• Iedere driver heeft expliciete limieten.
• Waarden hebben units en ranges.
• Kritieke grenzen zijn deterministisch.
• E-stop werkt onafhankelijk van AI.
• Safe state na verbindingsverlies.
• Device state heeft timestamp.
• Retry is veilig.

Permissies

• Agent ziet alleen benodigde apparaten.
• READ en WRITE zijn gescheiden.
• High-risk actions vereisen approval.
• Permissies verlopen.
• Geen globale admin-token.

Monitoring

• Iedere tool call wordt gelogd.
• Fysieke wijzigingen genereren telemetrie.
• Alarmen hangen niet alleen van het model af.
• Operator ziet actuele toestand.
• Event replay is beschikbaar.
• Mislukte acties zijn geclassificeerd.

Tests

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

Productie

• Rollout start read-only.
• Daarna low-risk writes.
• Safety-critical actions blijven buiten de agent.
• Deterministische code vervangt AI waar mogelijk.
• Drivers krijgen code review.
• Rollback bestaat.
• Handmatige overname bestaat.
• Team kent de fysieke impact van elke commandoklasse.

Wat is nodig voordat MHS een echte standaard wordt?

Onder meer:

1. publieke specificatie,
2. stabiele versioning,
3. compatibiliteitsmodel,
4. publieke SDK's,
5. open-source-licentie,
6. reference drivers,
7. conformance tests,
8. security evaluations,
9. onafhankelijke implementaties,
10. vendor support,
11. driver validation,
12. helder permission model.

MCP werd belangrijk dankzij een interoperabel ecosysteem. MHS zal een vergelijkbare route moeten afleggen.

Zal MHS robotica veranderen?

Misschien, maar het is te vroeg voor een stevige conclusie.

De beste korte-termijnfit is waar hardware al programmeerbaar is, integratie duur is en workflows vaak veranderen:

laboratoria
R&D
biotech
microscopy
quantum
advanced manufacturing

MHS lost niet automatisch robotperceptie, motion planning, real-time control, safety certification of manipulatiefysica op.

Het kan wel het interface vereenvoudigen waarmee een agent bestaande besturingssystemen gebruikt.

POLPROG-conclusie

Model Hardware Standard is een van de interessantere agentontwikkelingen van 2026 omdat het interoperabiliteit van digitale systemen naar fysieke apparatuur verplaatst.

Wat is bevestigd?

• research preview sinds 27 augustus 2026.^[1][3]
• oorsprong in Anthropic + HHMI Janelia.^[1]
• model-agnostic.^[1]
• control via MCP, CLI en code/API files.^[1]
• driver beschrijft het apparaat en safety limits.^[1]
• Anthropic wil het later open source maken.^[1][2]
• QuEra bevestigt 695 succesvolle relocks van 700 voor de finale controller.^[7]

Wat weten we nog niet?

• definitief publiek schema,
• open-source-releasedatum,
• licentie,
• API-stabiliteit,
• compatibiliteit tussen implementaties,
• onafhankelijke benchmark,
• prestaties van verschillende modellen op dezelfde hardware.

Het meest veelbelovende patroon

Niet:

LLM bestuurt alles voortdurend

maar:

agent begrijpt het doel
→ verkent een veilige ruimte
→ coördineert apparaten
→ maakt of kiest procedure
→ systeem valideert
→ herhaalbaar werk gaat naar deterministische code

Als Anthropic de specificatie werkelijk opent, vendors herbruikbare drivers leveren en onafhankelijke teams veiligheid en interoperabiliteit bevestigen, kan MHS een belangrijke laag voor physical AI worden.

Daar zijn we nog niet.