Der Gerätevertrag: Was ein Laborgerät offenlegen muss, damit ein KI-Agent den Kreislauf schliessen kann

Der Gerätevertrag: Was ein Laborgerät offenlegen muss, damit ein KI-Agent den Kreislauf schliessen kann

Eine Wissenschaftlerin oder ein Wissenschaftler führt ein Experiment durch, wartet auf das Ergebnis und entscheidet, was als Nächstes zu tun ist. Dieser Kreislauf ist das Ganze der experimentellen Wissenschaft, und heute schliesst ihn ein Mensch. Soll ihn stattdessen ein KI-Agent schliessen, liegt die Last fast vollständig bei der Schnittstelle des Geräts – nicht bei einer darüber aufgebauten Plattform.

Genau dieses Argument stellt der Grossteil des Marktes auf den Kopf. Die Antwort der Branche auf agentische Laborautomatisierung ist ein Labor-Betriebssystem: ein Orchestrator, ein Scheduler, eine Middleware-Schicht, die alles vereinheitlicht. Dieser Weg ist langsam und teuer, und er beseitigt die Integrationsarbeit pro Gerät nicht – er verlagert sie nur. Der günstigere Weg besteht darin, das Gerät selbst agentenfähig zu machen und dann einen intelligenten Agenten mit einem schlanken Vertrag kommunizieren zu lassen.

Und hier ist der Teil, der fast niemandem bewusst ist: Der grösste Teil dieses Vertrags existiert bereits in SiLA 2. Die Welt der Laborautomatisierung hat ein Jahrzehnt damit verbracht, genau den Standard zu entwickeln, den Agenten, wie sich herausstellt, benötigen – Jahre bevor es LLM-Agenten gab. Die Grundbausteine sind vorhanden. Was fehlt, ist ein Profil, das festlegt, auf welche davon sich ein Agent verlassen kann, sowie eine semantische Schicht darüber, die Bedeutung transportiert. Keines von beiden erfordert einen neuen Standard, und keines von beiden erfordert eine Plattform.

Aktualisierung September 2026: Anthropic hat inzwischen den Model Hardware Standard als Research Preview für von Agenten betriebene physische Geräte vorgestellt. Unsere Analyse von MHS für die Laborautomatisierung erläutert, wo er neben MCP, SiLA 2 und OPC UA LADS seinen Platz finden könnte – und warum der deterministische Gerätevertrag weiterhin notwendig bleibt.

Die wichtigsten Erkenntnisse

• Der Kreislauf lautet: ausführen → beobachten → entscheiden. Ein Agent kann ihn nur schliessen, wenn das Gerät ihm in maschinenlesbarer Form mitteilt, was es kann, wann es fertig ist, was herausgekommen ist und was schiefgelaufen ist.
• Zehn Pflichten bilden den Gerätevertrag. Sechs sind durch SiLA 2 bereits gelöst, drei teilweise, eine nur optional.
• SiLA 2 schreibt genau ein Feature vor – SiLAService – und lässt den Rest optional. Das ist für einen Gerätestandard das richtige Design, und genau deshalb muss ein Agent erkennen und schrittweise zurückfallen (discover-and-degrade), statt Annahmen zu treffen. Was dem Ökosystem fehlt, ist ein Agentenprofil: eine benannte Teilmenge, zu der ein Hersteller Konformität erklären kann.
• Die verbleibende Lücke ist Semantik, nicht Infrastruktur. Die Feature Definition Language von SiLA 2 liefert Bezeichner, Typen, deklarierte Fehler und Einheiten als Constraints. Sie liefert weder Absicht noch Unsicherheit, weder zustandsabhängige Sicherheitsgrenzen noch die Bedeutung eines Ergebnisses – und war dafür auch nie gedacht.
• Eine neuartige Client-Klasse hat bereits einen unveränderten Gerätevertrag genutzt – peer-reviewed, im Produktivbetrieb, auf einem realen Liquid-Handling-Gerät.
• Ein Treiber ist kein Vermieter. Eine vertragsformende Schicht ist gerätespezifisch, in Bezug auf das Labor zustandslos und austauschbar. Eine Plattform ist laborweit, zustandsbehaftet und besitzt Ihre Workflows.

Der Kreislauf, den niemand automatisiert

Beobachten Sie, was zwischen zwei Experimenten tatsächlich geschieht. Die Wissenschaftlerin oder der Wissenschaftler liest das Ergebnis, beurteilt es anhand der Erwartungen und wählt den nächsten Schritt: wiederholen, eine Variable ändern, auf ein anderes Gerät ausweichen oder aufhören. Das Gerät steht während dieser ganzen Zeit still, weil die Entscheidung in einem Kopf stattfindet.

Die Automatisierung des Ausführens ist ein gelöstes Problem – genau das leistet Scheduling-Software seit zwanzig Jahren. Die Automatisierung des Entscheidens ist das, wofür Agenten da sind. Was fehlt, ist das Beobachten dazwischen: der maschinenlesbare Kanal, über den ein Agent erfährt, was geschehen ist – präzise genug, um den nächsten Schritt zu wählen.

Wir haben bereits dargelegt, dass die Schnittstelle zwischen Agent und Gerät ein eigenständiges Engineering-Problem ist, verschieden von den Schnittstellen zwischen Agent und Tool sowie zwischen Agent und Agent. Dieser Beitrag geht eine Ebene tiefer: Wenn diese Schnittstelle real ist, was genau schuldet das Gerät dem Agenten?

Dieser Kanal ist die Pflicht des Geräts. Und er lässt sich in genau zehn Punkte zerlegen.

Der Gerätevertrag: zehn Pflichten

Damit ein Agent den Kreislauf mit einem Gerät schliessen kann, muss dieses Gerät Folgendes bereitstellen:

1. Maschinenlesbare Erkennung der Fähigkeiten zur Laufzeit. Der Agent darf kein fest einprogrammiertes Wissen darüber benötigen, was das Gerät kann.
2. Parametrisierte Ausführung mit typisierten Parametern. Befehle mit einer deklarierten, typisierten Signatur.
3. Asynchroner Start mit Rückgabe eines dauerhaften Handles. Ein Lauf dauert Minuten bis Stunden; der Aufruf darf nicht blockieren.
4. Eine Benachrichtigung über den Endzustand, die der Agent abonnieren kann. Wie erfährt der Agent, dass der Lauf beendet ist?
5. Typisierte, strukturierte Ergebnisse, die nach Abschluss abrufbar sind. Ein Ergebnis, mit dem der Agent arbeiten kann – kein PDF.
6. Exklusivität. Ein Agent, ein Gerät, für die gesamte Dauer.
7. Fortschritt und geschätzte Restzeit. Damit der Agent planen kann und damit ein Stillstand von Langsamkeit unterscheidbar ist.
8. Handlungsrelevante, deklarierte Fehler. «Fehlgeschlagen» ist nicht handlungsrelevant. «InsufficientTips» schon.
9. Maschinell prüfbare Grenzwerte, durchgesetzt vor der Aktuierung. Der Agent soll ein Nein erhalten, bevor sich der Arm bewegt.
10. Abbruch, Pause und Fortsetzung. Physische Prozesse müssen anhaltbar sein.

Das ist der gesamte Vertrag. Nichts zu Scheduling, nichts zu einer Datenbank, nichts Laborweites. Zehn Pflichten, alle lokal am Gerät.

Wie viel davon liefert SiLA 2 bereits?

Mehr, als der Markt annimmt. Das ist die kontraintuitive Erkenntnis, und sie lässt sich anhand der normativen Artefakte überprüfen statt anhand von Marketingaussagen.

Sechs gelöst, drei teilweise, eine nur optional – in einem Standard, der fertiggestellt wurde, bevor irgendjemand LLM-Agenten entwickelte. Das ist bemerkenswerte Weitsicht des SiLA-Konsortiums, und es bedeutet, dass die Infrastruktur nicht das Problem ist.

Fazit: Das agentische Labor wird nicht durch einen fehlenden Standard blockiert. Es wird blockiert durch das Fehlen eines Agentenprofils über dem Standard, den wir bereits haben, und durch die fehlende semantische Schicht darüber.

Was noch zu tun ist – und es ist kein neuer Standard

Erstens: ein Agentenprofil. SiLA 2 schreibt ein einziges Feature vor, SiLAService, und lässt den Rest optional. Für einen Gerätestandard ist das die richtige Entscheidung – sie ermöglicht es, dass sowohl ein Barcodeleser als auch ein Liquid-Handling-Gerät konform sein können. Ein Agent muss jedoch vor dem Handeln wissen, ob dieser Server einen Abbruch unterstützt, ob er den Fortschritt ehrlich meldet und ob Grenzwerte deklariert sind. Ein Agent muss daher erkennen und schrittweise zurückfallen: auslesen, was der Server tatsächlich implementiert, und sich weigern, den Rest anzunehmen.

Abhilfe schaffen würde kein neuer Standard, sondern ein Profil – eine benannte Teilmenge bestehender SiLA-2-Features, zu der ein Hersteller Konformität erklären kann, sodass ein Agent beim Verbindungsaufbau weiss, womit er es zu tun hat. Die Bausteine existieren bereits. Niemand hat sie gebündelt und ihnen einen Namen gegeben.

Es gibt eine praktische Besonderheit, die man kennen sollte: progressInfo und estimatedRemainingTime befinden sich in ExecutionInfo als gewöhnliche proto3-Felder. Proto3 kennt keine Pflichtfelder, und ein nicht gesetzter numerischer Wert steht standardmässig auf null – daher kann ein Agent «kein Fortschritt gemeldet» nicht von «0 % Fortschritt» unterscheiden. Behandeln Sie den Fortschritt als Hinweis und verlassen Sie sich auf den Übergang in den Endzustand, der zuverlässig ist.

Zweitens: die semantische Schicht. Dies ist der wichtige Punkt, und es ist nichts, was der Standard jemals bereitstellen sollte. FDL beschreibt, was das Gerät tut – Bezeichner, Typen, deklarierte Fehler, Einheiten als Constraints. Ein Agent muss wissen, was eine Wissenschaftlerin oder ein Wissenschaftler will, einschliesslich der zugehörigen Sicherheitsgrenzen. Absicht, Unsicherheit, parameterübergreifende und zustandsabhängige Grenzwerte sowie die tatsächliche Bedeutung eines Ergebnisses liegen alle oberhalb des Übertragungsformats.

Das ist die Schicht zwischen SiLA 2 und MCP, und dort liegt die Arbeit. Keine Plattform. Eine Übersetzung – pro Gerät und wiederverwendbar für jeden Agenten, der jemals mit ihm kommunizieren wird.

Es wurde bereits einmal umgesetzt – und das ist der Beweis

Der stärkste Beleg dafür, dass ein schlanker Vertrag einer schwergewichtigen Plattform überlegen ist, ist peer-reviewed und fünf Jahre alt.

In SLAS Technology (2023) berichtet der Artikel, der Tecans quelloffenes .NET-SDK für SiLA 2 beschreibt, dass LabVoice – ein Client für natürliche Sprache und Sprachsteuerung, aufgebaut auf einem völlig anderen Technologie-Stack – Tecans FluentControl über dessen veröffentlichte SiLA-2-Schnittstelle gesteuert hat. Eine grundlegend neue Client-Klasse nutzte einen unveränderten Gerätevertrag, und die Arbeit fand auf der Client-Seite statt.

Zwei ehrliche Korrekturen, denn die ungenaue Version dieser Geschichte ist leicht angreifbar. Es war nicht so, dass «Tecan einen Sprachagenten gebaut hat» – LabVoice wurde gegen Tecans SiLA-2-Server integriert. Und «es war keine neue Arbeit am Gerät nötig» stimmt nur, weil Tecan die Arbeit am Gerät bereits geleistet hatte, indem es einen SiLA-2-Server veröffentlichte. Genau das ist die Arbeit. Es ist exakt die Arbeit, die dieser Beitrag als die eine lohnende Aufgabe bezeichnet.

Und darum geht es: Leisten Sie die Arbeit am Gerät einmal, und jeder Client – ein Skript, ein Sprachassistent, ein LLM-Agent, etwas noch nicht Erfundenes – kann den Kreislauf damit schliessen. In dieser Geschichte war keine Plattform beteiligt. Ein Vertrag schon.

Das Plattform-Argument in seiner stärksten Form

Die massgebliche Gegenposition formuliert sich selbst unmissverständlich. Artificial beschreibt sein Produkt in seinem eigenen Paper als «ein umfassendes Orchestrierungs- und Scheduling-System, das Laborabläufe vereinheitlicht, Workflows automatisiert und KI-gestützte Entscheidungsfindung integriert». Das ist die Plattform-These in einem Satz: Die Intelligenz gehört in die Middleware.

Nehmen Sie sie ernst, denn Teile davon sind richtig. Wo unsere These tatsächlich an ihre Grenzen stösst: wenn knappe Ressourcen über viele Geräte und Personen hinweg eingeplant werden müssen, wenn zwei Agenten um dieselbe Zentrifuge konkurrieren und wenn ein reguliertes Umfeld einen laborweiten Audit-Trail verlangt, den kein einzelnes Gerät erzeugen kann. Diese Fälle sind real, und ein gerätespezifischer Vertrag löst sie nicht. Wenn das Ihr Problem ist, brauchen Sie etwas Laborweites – und das würden wir Ihnen auch so sagen.

Beachten Sie aber, was eine Plattform nicht leistet. Das peer-reviewte Paper zum Tecan-SDK benennt die zugrunde liegende Last unverblümt: «Viele Geräte in einem Labor verfügen nur über proprietäre Schnittstellen. Ihre Integration in ein Automatisierungssystem erfordert in der Regel die Implementierung eines eigenen Gerätetreibers.» Eine Plattform beseitigt diese Kosten pro Gerät nicht. Sie verlagert sie – in den Integrations-Backlog des Plattformanbieters, nach dessen Zeitplan und mit Ihrer Abhängigkeit (Lock-in). (Dieser Vergleich ist unsere Schlussfolgerung, nicht die Aussage des Papers; die Abhilfe, die das Paper selbst vorschlägt, ist dieselbe geräteseitige Standardisierung, die wir befürworten – was uns gelegen kommt, und das sagen wir auch offen.)

Die Trennlinie lautet: Eine vertragsformende Schicht ist gerätespezifisch, in Bezug auf das Labor zustandslos und austauschbar. Eine Plattform ist laborweit, zustandsbehaftet und besitzt Ihre Workflows. Das eine ist ein Treiber. Das andere ist ein Vermieter.

Konvergierende Belege: Ein anderes Normungsgremium kam zur selben Struktur

Wäre der Gerätevertrag eine Idee, die wir erfunden hätten, um Treiber zu verkaufen, würde man erwarten, dass nur wir ihn beschreiben. Stattdessen ist ein unabhängiges Normungsgremium von der Seite der analytischen Geräte her zur selben Struktur gelangt.

OPC UA LADS (OPC 30500-1, veröffentlicht im November 2023) modelliert Methoden als vollwertige Programmvorlagen, die von einem Program Manager verwaltet werden, stellt StartProgram bereit, definiert zweistufige Zustandsautomaten – einen für das Gerät, einen pro Funktionseinheit – und behandelt Ergebnisse als vollwertige, adressierbare, mit Herkunftsangaben versehene Objekte in einem ResultSet.

Anderes Konsortium, anderes Übertragungsformat, derselbe Vertrag: erkennen, parametrisieren, starten, Zustand beobachten, ein Ergebnisobjekt abrufen. Eine ehrliche Einschränkung: LADS garantiert die Struktur auf Ebene der Hülle, nicht der Nutzdaten – die Spezifikation erlaubt, dass ein Ergebnis seine Daten als Dateien in einem FileSet enthält. Ein LADS-konformes Gerät kann Ihrem Agenten also nach wie vor eine undurchsichtige Datei übergeben.

Fazit: Zwei unabhängige Normungsgremien sind beim selben geräteseitigen Vertrag angekommen – ein starkes Signal dafür, dass dies die richtige Zerlegung ist.

Was wir gemessen haben: Der Vertrag allein genügt nicht

Den Vertrag offenzulegen ist notwendig. Es ist aber nicht hinreichend – denn wie Sie ihn dem Agenten präsentieren, entscheidet darüber, ob der Agent Erfolg hat.

Wir haben unseren eigenen digitalen Zwilling eines Liquid-Handling-Geräts, LiquidBridge, mit drei unterschiedlichen Designs der MCP-Tool-Oberfläche über demselben zugrunde liegenden Gerät getestet. Gleiches Gerät, gleiches Modell, gleiche Aufgaben – nur die Form der bereitgestellten Tool-Oberfläche änderte sich:

Rund 16-mal weniger Tokens und 11-mal schneller, ohne Einbusse bei der Korrektheit – allein durch die Neugestaltung der Tool-Oberfläche über einem unveränderten Gerät. Und beachten Sie die mittlere Zeile, die gefährliche: Die günstige, schmale Oberfläche scheiterte nicht lautstark. Sie tat stillschweigend nichts.

Ehrliche Einschränkungen: Es handelt sich um einen digitalen Zwilling, nicht um physische Hardware; es ist eine einzige Modellfamilie; die Anzahl Wiederholungen ist gering. Wir berichten eine Richtung, keinen Benchmark. Doch genau um die Richtung geht es – die Schicht zwischen dem Gerätevertrag und dem Agenten ist der Ort, an dem Zuverlässigkeit gewonnen oder verloren wird, und fast niemand misst sie.

Was also zu bauen ist

Keine Plattform. Drei Dinge, pro Gerät, und dann sind Sie fertig:

1. Den Vertrag offenlegen – wenn das Gerät SiLA 2 spricht, haben Sie bereits den grössten Teil davon, und das ist die günstigste Ausgangslage; wenn es REST spricht, generieren Sie den Treiber.
2. Deklarieren, was Sie unterstützen – geben Sie an, auf welche optionalen Features sich ein Agent verlassen kann: Abbruch, deklarierte Fehler, Grenzwerte. Ein Agent, der weiss, womit er es zu tun hat, ist ein sicherer Agent.
3. Die semantische Schicht hinzufügen – Tools auf Absichtsebene mit den zugehörigen Sicherheitsgrenzen, damit der Agent über das Experiment nachdenkt statt über vierzig Grundbausteine.

Übergeben Sie es dann an einen beliebigen Agenten. Die Intelligenz ist nicht Ihr Problem. Der Vertrag ist es.

Häufig gestellte Fragen

Was braucht ein KI-Agent von einem Laborgerät?

Zehn Dinge: Erkennung der Fähigkeiten zur Laufzeit, typisierte parametrisierte Ausführung, ein asynchrones Handle, eine Benachrichtigung über den Endzustand, strukturierte abrufbare Ergebnisse, Fortschritt und ETA, deklarierte handlungsrelevante Fehler, vor der Aktuierung durchgesetzte Grenzwerte, Abbruch sowie Exklusivität. Sechs davon sind durch SiLA 2 bereits gelöst; der Rest ist optional oder fehlt.

Brauche ich ein Labor-Betriebssystem, um KI-Agenten auf Geräten zu betreiben?

Nicht, um den Kreislauf Ausführen–Beobachten–Entscheiden an einem einzelnen Gerät zu schliessen – das ist ein Problem des Gerätevertrags, kein Plattformproblem. Sie brauchen etwas Laborweites, wenn Sie knappe Ressourcen über viele Geräte hinweg einplanen, Konkurrenz zwischen Agenten auflösen oder einen laborweiten Audit-Trail für einen regulierten Prozess erzeugen müssen.

Macht SiLA 2 ein Gerät agentenfähig?

Es bringt Sie den grössten Teil des Weges – bemerkenswert für einen Standard, der verfasst wurde, bevor es LLM-Agenten gab. Erkennung, typisierte Befehle, beobachtbare Ausführung, eine vierteilige Fehlertaxonomie, 17 Typen von Parameter-Constraints und Sperrmechanismen sind allesamt spezifiziert. Zwei Dinge bleiben: ein Agentenprofil, das benennt, auf welche optionalen Features sich ein Agent verlassen darf, und eine semantische Schicht oberhalb des Übertragungsformats, die Absicht, Unsicherheit und Sicherheitsgrenzen transportiert – was SiLA 2 nie bereitstellen sollte.

Was fehlt zwischen SiLA 2 und MCP?

Bedeutung. SiLA 2 beschreibt in Typen und Bezeichnern, was das Gerät tut – und tut das gut. Ein Agent muss wissen, was eine Wissenschaftlerin oder ein Wissenschaftler will, einschliesslich der zugehörigen Sicherheitsgrenzen. Diese Übersetzungsschicht – Tools auf Absichtsebene über einem validierten Gerätevertrag – muss dazwischen aufgebaut werden, und unsere eigenen Messungen zeigen, dass dort die Zuverlässigkeit von Agenten gewonnen oder verloren wird.

Kann ein KI-Agent den experimentellen Kreislauf heute wirklich schliessen?

An einem einzelnen Gerät mit vollständigem Vertrag: ja – der Mechanismus existiert, und eine neuartige Client-Klasse hat im Produktivbetrieb bereits einen unveränderten Gerätevertrag genutzt. Nicht gelöst ist die Zuverlässigkeit über lange Zeithorizonte und viele Schritte hinweg; das ist ein Engineering-Problem in der Schicht oberhalb des Geräts – an der Schnittstelle zwischen Agent und Gerät – und kein fehlender Standard.

---

Wir bauen diese Schicht. Unsere Generatoren für SiLA 2 und MCP sind Open Source, und wir haben den Kreislauf an unserem eigenen Gerät durchgängig umgesetzt. Nennen Sie uns ein Gerät und einen Workflow, und wir sagen Ihnen genau, welche der zehn Pflichten es bereits erfüllt, welche nicht und was nötig wäre, um den Kreislauf damit zu schliessen. Kontaktieren Sie uns.