Zum Hauptinhalt springen
9 – 17 UHR +49 8031 3508270 LUITPOLDSTR. 9, 83022 ROSENHEIM
DE / EN

Model Hardware Standard (MHS): Anthropic bringt KI-Agenten an Laborgeräte und Maschinen

Tobias Jonas Tobias Jonas | | 11 min Lesezeit

Am 27. August 2026 hat Anthropic den Model Hardware Standard (MHS) als Research Preview vorgestellt: eine gemeinsame Spezifikation, über die KI-Agenten physische Geräte sicher bedienen sollen – Mikroskope, Liquid Handler, Roboterarme, Plate Reader, Laser. Anders als bei vielen Ankündigungen im Agenten-Umfeld geht es hier nicht um ein weiteres Protokoll für Textwerkzeuge, sondern um den Schritt vom Bildschirm auf die Laborbank und in die Fertigungshalle.

Für Unternehmen im DACH-Raum ist das aus zwei Gründen relevant. Erstens löst MHS ein Problem, das jeder kennt, der schon einmal Geräte unterschiedlicher Hersteller integrieren musste: Jedes Gerät bringt seine eigene Software, sein eigenes Datenformat und seinen eigenen Treiber mit, und die Integration dauert Wochen bis Monate. Zweitens ist MHS bewusst als Ergänzung zum Model Context Protocol (MCP) gebaut – wer MCP bereits im Einsatz hat, bekommt hier die fehlende Schicht nach unten, zur Hardware.

Dieser Beitrag erklärt, was MHS ist, wie es technisch funktioniert, was die Partnerlabore damit bereits gezeigt haben – und was das für Mittelständler mit Laboren, Prüfständen oder Fertigungslinien bedeutet.

Was MHS ist – und was nicht

MHS ist eine Spezifikation für die Treiberschicht zwischen KI-Agent und Gerät. Der Standard definiert, wie ein Gerät sich beschreibt, wie es angesprochen wird und welche Sicherheitsgrenzen der Treiber selbst durchsetzt. Er funktioniert laut Anthropic mit jedem Gerät, das eine programmierbare Schnittstelle hat – egal ob moderne REST-API, alte COM-Schnittstelle oder nur eine grafische Oberfläche.

MHS ist modellagnostisch. Jeder Agenten-Harness kann über Standardprotokolle wie MCP darauf zugreifen. Die Partnerprojekte laufen mit Claude, die Spezifikation selbst schreibt aber kein Modell vor.

MHS ist noch nicht Open Source. Der Standard liegt aktuell in einer gated Research Preview für eine erste Gruppe aus Forschungslaboren und industriellen Fertigern. Anthropic will die Preview nutzen, um gemeinsam mit den Partnern Sicherheitsevaluationen und Best Practices zu entwickeln, und den Standard anschließend offenlegen. Interessierte Organisationen können sich unter modelhardwarestandard.com bewerben.

MHS ist kein Ersatz für MCP. MCP standardisiert, wie ein Agent Werkzeuge findet und aufruft. MHS standardisiert, wie ein physisches Gerät als Werkzeug überhaupt erst verfügbar wird. Ein MHS-Gerät kann dem Agenten dann über MCP angeboten werden – MCP ist einer von drei Steuerwegen, die MHS vorsieht.

Anthropic hat die Ankündigung mit einem kurzen Video begleitet, das den Grundgedanken in gut zwei Minuten zeigt:

Beim Abspielen wird eine Verbindung zu YouTube (Google) hergestellt. Datenschutzhinweise · Auf YouTube ansehen

Ein zweites Video mit Einblicken in die Partnerlabore gibt es ebenfalls auf dem Anthropic-Kanal: AI models can now help run physical science experiments.

Wie MHS technisch funktioniert

Die vollständige Spezifikation ist noch nicht öffentlich. Aus der Ankündigung, den Beiträgen der Partnerlabore und den Blogposts von QuEra und Tetsuwan lässt sich die Architektur aber bereits gut rekonstruieren. Sie besteht aus vier Bausteinen.

1. Ein standardisierter Treiber mit zwei Primitiven

Kern von MHS ist ein Treiber, der zwischen Betriebssystem und Gerät übersetzt. Statt für jedes Gerät eine eigene Befehlssemantik zu lernen, arbeitet der Agent mit einem sehr kleinen Vokabular: read (zum Beispiel „Temperatur auslesen") und write (zum Beispiel „Temperatur setzen"). Jedes Gerät, das diese Primitive versteht, lässt sich auf dieselbe Art ansprechen – ob es sich um einen Inkubator, einen Galvanometerspiegel oder einen Roboterarm handelt.

Die Carnegie Mellon University beschreibt das Ergebnis so: MHS macht aus jedem Gerät ein einziges Manifest aus Zuständen und Prozeduren. Zustände sind Bedingungen, in denen sich das System befinden kann („Platte an Position 3", „Probe bei 25 °C", „Well gefüllt"), Prozeduren sind die Operationen, die es ausführen kann. Was hinter dem Manifest liegt – ein Verzeichnis-Watcher, eine ActiveX/COM-Schnittstelle oder eine reine GUI ohne API –, ist für den Agenten unsichtbar.

2. Discovery und ein gemeinsames Zustands-Dictionary

Jedes MHS-Gerät macht sich in einem standardisierten Format auffindbar. Geräte und Agenten können sich damit über Netzwerkgrenzen hinweg finden, ohne dass jemand ein Übersetzungsprogramm dazwischenschaltet.

Die Idee dahinter stammt aus dem HHMI Janelia Research Campus, wo MHS gemeinsam mit Anthropic entstanden ist: Der komplette Zustand eines Geräte-Rigs liegt in einem standardisierten Dictionary im Shared Memory – einem Speicherbereich, auf den viele Programme gleichzeitig zugreifen können. Jede Variable, jeder Regler, jeder Sensorwert bekommt dort einen dokumentierten Slot. Ein Detektor in MATLAB, eine Kamera in Python und eine Elektrophysiologie-Software in C# lesen und schreiben in dasselbe Dictionary. Analyse- und Visualisierungscode wird dadurch geräteunabhängig und in beliebiger Sprache wiederverwendbar.

3. Tags in natürlicher Sprache statt Papierhandbuch

Ein Roboterarm hat ein Gewicht, ein Sensor einen Messbereich, ein Motor eine Höchstgeschwindigkeit. Diese Informationen stehen bisher in PDF-Handbüchern, auf dem Rechner eines Kollegen oder gar nicht. Der MHS-Treiber enthält deshalb Tags, in die der Nutzer solche Eigenschaften direkt in natürlicher Sprache schreibt. Alternativ lässt man sich von einem Agenten zu jedem Gerät interviewen. Der Treiber kompiliert die Angaben in Referenzdateien, die dokumentieren, was ein Gerät misst, welche Parameter sich einstellen lassen und welche Sicherheitsgrenzen gelten.

Damit kann ein Agent ein Gerät bedienen, das er noch nie gesehen hat – weil die Referenzdatei ihm nicht nur die API erklärt, sondern auch die Physik dahinter.

4. Drei Steuerwege: MCP, Kommandozeile, Code-Dateien

Sind die Geräte angebunden, braucht der Agent einen Weg, sie zu steuern. MHS bietet drei, die zusammenspielen:

  • MCP für die Anbindung an beliebige Agenten-Harnesses und für interaktives Reasoning über einzelne Schritte.
  • Kommandozeile für direkte Aufrufe und Skripting.
  • Code-Dateien (APIs), in denen der Agent Treiberbefehle mehrerer Geräte verkettet.

Der dritte Weg ist der entscheidende für den Praxisbetrieb. Ein LLM reasoned in Sekunden, ein Laser-Regelkreis braucht Millisekunden. Für lange oder schnelle Abläufe schreibt der Agent deshalb einmal ein deterministisches Programm, das die Geräte dann selbstständig ausführen – ohne dass das Modell bei jedem Schritt nachdenken muss. QuEra bringt es auf den Punkt: Was auf dem Tisch läuft, ist ein deterministisches, vollständig inspizierbares Programm – KI-getrieben in der Entwicklung, menschlich orchestriert, autonom im Betrieb.

Sicherheit sitzt im Treiber, nicht im Prompt

Der für Entscheider wichtigste Punkt: Sicherheitsgrenzen werden auf Geräteebene vom MHS-Treiber durchgesetzt, nicht vom Modell. Das Gerät deklariert seine Limits, Interlocks und unabhängige Notaus-Schalter bleiben in Kraft, und der Treiber blockiert Befehle außerhalb des erlaubten Bereichs, bevor sich etwas bewegt. Die CMU hat das explizit getestet: Sechs künstlich erzeugte Fehlerzustände – fehlende Platte, verdrehte Platte, belegter Reader, getrennte Kamera, nicht erreichbares Gerät, aktiver Not-Halt – wurden alle korrekt abgefangen, bevor ein Gerät sich bewegte.

Was die Partnerlabore bereits gezeigt haben

Die Ankündigung ist ungewöhnlich konkret, weil sechs Partner ihre Ergebnisse mit Zahlen belegen. Ein Überblick:

PartnerAufgabeErgebnis
GenentechBCA-Protein-Assay über Liquid Handler, Roboterarm und Plate ReaderClaude optimierte Flussraten autonom (ca. 140 µL/s für Wasser, 10 µL/s für viskose Proben); Experten bestätigten die Werte
University of Washington (Baker- und Pinglay-Lab)Fernüberwachung, KI-überwachte qPCR, kollisionsfreie PlattenübergabenSechs Instrumente in unter einer Woche integriert, inklusive Treiber
Carnegie Mellon UniversitySerielle Verdünnungsreihen für Dosis-Wirkungs-KurvenRund dreimal schneller; Integration in acht Stunden statt mehrerer Wochen; alle sechs Fehlerszenarien blockiert
HHMI JaneliaMehrkomponenten-Mikroskopie mit sieben Hersteller-ProgrammenEin einziges Interface; neue Kamera in wenigen Minuten statt Tagen eingebunden
QuEra ComputingLaser-Stabilisierung an einem QuantencomputerErfolgsquote beim automatischen Relock von 58 % auf 99,3 % (695 von 700 Versuchen); Recovery in Sekunden statt 5–10 Minuten
Tetsuwan ScientificqPCR-Workflow für Citizen-Science-WassermonitoringKamera-erkannte Blasenfehler lösen automatisch Zentrifugieren aus; 9.143 Dispensiervorgänge zur Kalibrierung vermessen

Zwei Beispiele verdienen einen genaueren Blick.

QuEra hatte für das Wiedereinrasten eines Ti:Saphir-Lasers eine lineare Skriptsequenz, die in 58 % der Fälle funktionierte und pro Versuch rund 150 Sekunden brauchte. Der Agent bekam über MHS Lesezugriff auf die Instrumentendaten und Schreibzugriff innerhalb deklarierter Grenzen. In einer Nacht iterativer Versuche – vorschlagen, auf der Hardware testen, Ergebnis lesen, verfeinern – baute er die Sequenz in eine Entscheidungsbaum-Logik um, die Störungen zuerst klassifiziert und dann gezielt behebt. Beim PID-Tuning sank der Restfehler von 15,7 mV auf 1,55 mV. Der Punkt, der über die Zahlen hinausgeht: Für eine neue Wellenlänge, die ursprünglich Wochen gekostet hatte, brauchte das Team mit dem erworbenen Wissen eine Nacht.

Tetsuwan zeigt, wie MHS in eine bestehende Automatisierungsarchitektur passt. Das Unternehmen hat seinen bisherigen Scheduler durch ein MHS-basiertes System ersetzt und Geräte ohne Herstellerunterstützung über kleine Einplatinenrechner als MHS-Connector angebunden. Ein Protokoll sagt nur noch „Platte bei 15.000 rpm zentrifugieren" – das System fragt ab, welche Geräte verfügbar sind, und Claude übersetzt die Parameter auf die konkrete Maschine. Erkennt die Kamera Blasen in der Pipettenspitze, schlägt der Agent eine Korrektur vor, die ein Operator per Slack freigibt, bevor sie ausgeführt wird.

Grenzen: Wo aktuelle Modelle noch scheitern

Anthropic und die Partner benennen die Schwächen genauso offen wie die Erfolge. Der wiederkehrende Befund: Frontier-Modelle sind stark im allgemeinen Reasoning, aber schwach in physikalischer Intuition.

Das anschaulichste Beispiel liefert Genentech. Im ersten Lauf wählte Claude für Wasser und viskose Proteinlösung dieselbe Flussrate. Ergebnis: Blasen in der viskosen Lösung, ungenaue Transfers, Fehlercodes der Füllstandssensoren, verzerrte optische Messwerte. Das Modell konnte den Fehlercode lesen, aber nicht auf die physikalische Ursache schließen. Erst nachdem ein Mensch erklärt hatte, dass Blasen das Problem sind und weniger Mischzyklen helfen, behielt das Modell diesen Kontext für den Rest des Laufs. Genentech hat die Erkenntnisse anschließend in wiederverwendbare Skills gegossen, damit Claude beim nächsten Mal sinnvolle Standardparameter für Flüssigkeiten unterschiedlicher Viskosität wählt.

Die Konsequenz für den Betrieb: Das Verständnis der Agenten bleibt vorerst programmatisch statt physisch. Sie brauchen viel Kontext, und bei risikobehafteten Entscheidungen halten sie häufig an und fragen nach – was in dieser Phase gewollt ist. Die CMU plant weitere Sicherheitsprüfungen und klare Regeln, wann eine menschliche Freigabe zwingend ist.

Wer den Standard unterstützt

Ein Standard ist so viel wert wie die Geräte, die ihn sprechen. Anthropic nennt zum Start Hersteller und Plattformen, die MHS-Unterstützung aufbauen: Amazon Web Services (über die Strands-Robots-Bibliothek), Automata (LINQ-Laborplattform), Danaher, Doosan Robotics, MBF Bioscience (ScanImage-Mikroskopiesoftware), QIAGEN (QIAsymphony Connect), Tecan (Fluent-Liquid-Handler) und Universal Robots.

Mit Universal Robots und Doosan sind zwei der relevanten Anbieter für kollaborative Roboterarme dabei, die in deutschen Fertigungsbetrieben verbreitet sind. Das ist der Hinweis darauf, dass MHS nicht auf Life-Science-Labore beschränkt bleiben soll.

Einordnung: MCP, SAM, MHS – die Schichten sortieren sich

Wer die Agenten-Standards der letzten anderthalb Jahre verfolgt, erkennt ein Muster. Die Schichten trennen sich sauber:

  • MCP definiert, wie ein Agent Werkzeuge findet und aufruft – die Semantik.
  • Google SAM definiert, wie MCP-Aufrufe autorisiert über Netzgrenzen transportiert werden – der Transport.
  • MHS definiert, wie ein physisches Gerät zu einem Werkzeug wird, das ein Agent sicher bedienen kann – die Hardware-Abstraktion.

Für IT-Entscheider heißt das: Eine Investition in MCP-Kompetenz verfällt nicht, wenn Hardware ins Spiel kommt. Im Gegenteil – die Governance-Fragen, die wir in MCP als Standard für Agent-Tool-Usage: Ja, aber bitte sicher beschrieben haben, werden bei physischen Geräten nur dringlicher. Ein falsch autorisierter Tool-Aufruf löscht im Bürokontext eine Datei. Im Labor bewegt er einen Roboterarm.

Was das für den Mittelstand bedeutet

MHS ist heute eine Research Preview für Labore und Fertiger. Trotzdem lohnt es sich, jetzt drei Dinge zu tun.

Erstens: Geräte mit programmierbarer Schnittstelle inventarisieren. Prüfstände, Messgeräte, Kameras, Cobots, Klimakammern, Analysegeräte – alles, was eine API, ein SDK, eine serielle Schnittstelle oder auch nur eine bedienbare GUI hat, ist ein potenzieller MHS-Kandidat. Die CMU hat einen Plate Reader ohne jede Programmierschnittstelle angebunden. Die Frage ist nicht, ob Ihre Geräte integrierbar sind, sondern welche Prozesse am meisten von einer Integration profitieren würden.

Zweitens: Die MCP-Basis legen. MHS wird über MCP an Agenten angebunden. Wer bereits einen sauber abgesicherten MCP-Layer mit Berechtigungen, Audit-Logs und Freigabeprozessen betreibt, hat den schwierigen Teil der Governance erledigt. Wie so ein Layer im Unternehmen aussieht, besprechen wir in unserer KI-Strategieberatung.

Drittens: Die Compliance-Fragen früh stellen. Ein KI-Agent, der Maschinen bewegt, berührt Maschinenrecht, Produktsicherheit und – je nach Einsatz – die Anforderungen des EU AI Act an Sicherheitskomponenten. Das Muster, das alle MHS-Partner nutzen, ist auch aus Compliance-Sicht das richtige: deterministische Programme im Betrieb, Sicherheitsgrenzen im Treiber statt im Prompt, menschliche Freigabe bei riskanten Entscheidungen. Welche Dokumentations- und Kontrollpflichten konkret gelten, klären wir in der KI-Compliance-Beratung.

Fazit

Der Model Hardware Standard ist der erste ernsthafte Versuch, die Integration physischer Geräte für KI-Agenten zu standardisieren – mit einem kleinen Treiber-Vokabular, einem gemeinsamen Zustands-Dictionary, natürlichsprachigen Referenzdateien und Sicherheitsgrenzen auf Geräteebene. Die Partnerzahlen sind belastbar: Integrationszeiten von Wochen auf Stunden, Erfolgsquoten von 58 % auf 99,3 %, sechs Instrumente in unter einer Woche.

Genauso klar sind die Grenzen. Die Modelle verstehen Code, nicht Physik. Der Betrieb funktioniert, weil Menschen den Rahmen setzen, Sicherheitsgrenzen im Treiber liegen und der Agent im Zweifel nachfragt. Das ist kein Mangel des Konzepts, sondern seine Architektur.

Für Unternehmen mit Laboren, Prüfständen oder Fertigungslinien ist jetzt der richtige Zeitpunkt, die eigene Gerätelandschaft zu sichten und die MCP-Grundlagen zu legen. Wenn MHS nach der Preview Open Source wird, entscheidet nicht die Technik über den Vorsprung, sondern die Vorbereitung.

Wenn Sie prüfen möchten, welche Prozesse in Ihrem Unternehmen für agentengesteuerte Hardware in Frage kommen, sprechen Sie uns an.


Quellen: Anthropic: Previewing the Model Hardware Standard (27.08.2026) · Model Hardware Standard – Research Preview · Anthropic auf YouTube: Model Hardware Standard: AI operating physical equipment · QuEra: Holding the Light – Teaching an AI to Lock and Tune Our Quantum Computer’s Lasers · Tetsuwan Scientific: MHS · CNBC: Anthropic pushes into physical world with new standard to help AI agents operate machines

Tobias Jonas
Geschrieben von

Tobias Jonas

Co-CEO, M.Sc.

Tobias Jonas, M.Sc. ist Mitgründer und Co-CEO der innFactory AI Consulting GmbH. Er ist ein führender Innovator im Bereich Künstliche Intelligenz und Cloud Computing. Als Co-Founder der innFactory GmbH hat er hunderte KI- und Cloud-Projekte erfolgreich geleitet und das Unternehmen als wichtigen Akteur im deutschen IT-Sektor etabliert. Dabei ist Tobias immer am Puls der Zeit: Er erkannte früh das Potenzial von KI Agenten und veranstaltete dazu eines der ersten Meetups in Deutschland. Zudem wies er bereits im ersten Monat nach Veröffentlichung auf das MCP Protokoll hin und informierte seine Follower am Gründungstag über die Agentic AI Foundation. Neben seinen Geschäftsführerrollen engagiert sich Tobias Jonas in verschiedenen Fach- und Wirtschaftsverbänden, darunter der KI Bundesverband und der Digitalausschuss der IHK München und Oberbayern, und leitet praxisorientierte KI- und Cloudprojekte an der Technischen Hochschule Rosenheim. Als Keynote Speaker teilt er seine Expertise zu KI und vermittelt komplexe technologische Konzepte verständlich.

LinkedIn