Agentic Engineering für physische KI: Warum die Roboterschleife nicht die Software-Agenten-Schleife ist

Ein Software-Agent, der das falsche Tool aufruft, sendet eine fehlerhafte API-Anfrage. Ein physischer Agent, der das falsche Tool aufruft, bewegt einen Greifer in die Hand eines Menschen. Genau dieser Unterschied in den Konsequenzen ist der Grund, warum sich „Agentic Engineering“ – die Disziplin, KI-Agenten zuverlässig zu bauen, zu evaluieren und im Produktivbetrieb zu führen – nicht einfach von Chatbots und Coding-Assistenten auf Roboter übertragen lässt. Der Physical-AI-Stack hat bereits seine eigene Schleife: Sensoren speisen ein Weltmodell, eine Policy entscheidet, eine Steuerungsschicht übersetzt diese Entscheidung in Motorbefehle, Aktoren führen sie aus. Agentic Engineering ersetzt diese Schleife nicht. Es ist die fehlende Disziplin, die diese Schleife wie ein Produktivsystem behandelt statt wie eine Forschungsdemo – mit einem Harness, der eine reale Sicherheitsgrenze hat, mit einem Gedächtnis, das die gesamte Betriebsdauer eines Roboters überdauert, mit einer Evaluation, die in Simulation stattfindet, bevor sich auch nur ein realer Aktor bewegt, und mit einer Aufsicht, die von Anfang an in die Schleife eingebaut ist statt nachträglich angeflanscht zu werden.

Dieser Beitrag überträgt die vier praktischen Säulen des Agentic Engineering – Harness, Gedächtnis, Evaluation, Governance – direkt auf den Physical-AI-Stack, den unser Grundlagenartikel zu diesem Stack beschreibt: Wahrnehmung, Weltmodell, Policy, Steuerung, Aktorik. Ziel ist nicht eine weitere Beschreibung des Stacks selbst, sondern eine konkrete Antwort auf eine engere Frage: Was ändert sich tatsächlich, wenn der „Agent“ im Begriff Agentic Engineering einen Körper bekommt?

Was ist Agentic Engineering, und warum ist es für einen Roboter relevant?

Agentic Engineering ist die Ingenieurdisziplin, KI-Agenten zuverlässig zu entwerfen, zu bauen, zu evaluieren und im Produktivbetrieb zu führen – nicht ein einzelner geschickter Prompt, sondern der vollständige Lebenszyklus eines Systems, das ein Ziel verfolgt, anstatt nur eine einzelne Nachricht zu beantworten. Die Disziplin schöpft aus Prompt Engineering (was man dem Modell in diesem Moment mitteilt), Context Engineering (der Architektur von allem anderen, was das Modell sieht – abgerufene Dokumente, Tool-Ausgaben, Verlauf), Harness Engineering (der Ausführungsumgebung, den Werkzeugen, dem Lebenszyklusmanagement, der Beobachtbarkeit und der Governance rund um das Modell), Inferenz, Gedächtnis, Evaluation und Code Engineering – sie zieht aus jedem dieser Bereiche etwas, lässt sich aber auf keinen davon reduzieren.

Gerade diese letzte Unterscheidung zählt in der Robotik mehr als fast überall sonst, weil man leicht verführt ist, „das Modell wurde klüger“ für die ganze Geschichte zu halten. Branchenbeobachtungen zu produktiven KI-Agenten im Jahr 2026 zeigen konsequent das Gegenteil: Teams, die im Produktivbetrieb erfolgreich sind, investieren tendenziell mehr in den Harness und den Kontext rund um das Modell als in die Raffinesse der Orchestrierung darüber. Ein leistungsfähiges Policy-Modell auf einem fragilen Harness scheitert im Produktivbetrieb aus demselben Grund, aus dem ein leistungsfähiger Coding-Agent ohne saubere Tool-Berechtigungen und Protokollierung scheitert – die Intelligenz war nie der Engpass, sondern die umgebende Ingenieurarbeit. Bei einem Roboter umfasst diese „umgebende Ingenieurarbeit“ Dinge, die ein Software-Team nie bauen muss: einen sicherheitszertifizierten Stopp, eine Steuerungsschleife mit hartem Latenzbudget und einen Zertifizierungsprozess, bevor das System überhaupt in die Nähe eines Menschen darf.

Hier die Zuordnung, die dieser Beitrag Schicht für Schicht durcharbeitet:

Agentic-Engineering-Aspekt	Software-Agent	Schicht des Physical-AI-Stacks	Was sich physisch unterscheidet
Context Engineering	Abgerufene Dokumente, Tool-Ausgaben, Chatverlauf	Wahrnehmung, die das Weltmodell speist	Kontext ist verrauscht, unvollständig und wird durch die Bewegung des eigenen Sensors erzeugt, nicht auf Abruf bereitgestellt
Harness Engineering	Sandboxing, Tool-Berechtigungen, Notaus	Steuerungsschicht + Aktorik, sicherheitszertifizierter Stopp	Der Notaus muss Bewegung physisch innerhalb von Millisekunden stoppen, nicht nur einen API-Schlüssel widerrufen
Gedächtnis	Kontextfenster, Vektordatenbank, Sitzungsprotokoll	Zustandsschätzung (Arbeit), Aufgabenepisode (Sitzung), Feinabstimmungskorpus (Langzeit)	Eine falsche Zustandsschätzung mitten in der Aufgabe zu „vergessen“ ist kein UX-Problem, sondern ein Sturz oder eine Kollision
Evaluation	Zurückgehaltene Testdatensätze, sandboxbasierte Evaluationsharnesse	Simulation und digitale Zwillinge, Sim-to-Real-Tests	Ein fehlgeschlagener Evaluationslauf in Simulation ist günstig; auf Hardware ist er das nicht
Governance / Aufsicht	Freigabeschritte durch Menschen, Audit-Protokolle	Sicherheitszertifizierung, Teleoperation als Rückfallebene	Aufsicht muss im Voraus in die Sicherheitshülle eingebaut werden – es bleibt keine Zeit, einen einzelnen Motorbefehl freizugeben

Jede Zeile bekommt weiter unten einen eigenen Abschnitt. Zusammen beantworten sie die Frage, für die dieser Beitrag geschrieben wurde: Agentic Engineering für physische KI ist nicht „dieselbe Disziplin, nur auf Roboter angewendet“. Es ist dasselbe Vokabular, das einen grundlegend anderen Satz an Einschränkungen beschreibt – denn die in der Tabelle skizzierte Schleife endet nicht an einem Bildschirm.

Wie unterscheidet sich die Entscheidungsschleife eines Roboters von der eines Software-Agenten?

Die Schleife eines Software-Agenten lässt sich in ihrer einfachsten Form so beschreiben: wahrnehmen (Kontext lesen) → entscheiden (einen Tool-Aufruf oder eine Antwort wählen) → handeln (den Aufruf ausführen) → beobachten (das Ergebnis lesen) → wiederholen. Dieses Muster ist – ob die Autoren der jeweiligen Frameworks das nun anerkennen oder nicht – von jahrzehntealter Regelungstheorie aus der Robotik entlehnt. Die Robotik kam zuerst dorthin, nur unter anderem Namen: Sense-Plan-Act, erstmals im Shakey-Projekt am Stanford Research Institute Ende der 1960er-Jahre umgesetzt, und bis heute das Grundgerüst unter der Wahrnehmungs-Planungs-Handlungs-Schleife, auf der jedes verkörperte System läuft, so viel gelernte Policy auch immer auf der klassischen Architektur aufsetzt.

Das Vokabular hat sich angenähert, weil die Struktur des Problems tatsächlich ähnlich ist: eine Instanz, die einen Zustand wahrnimmt, überlegt, was zu tun ist, handelt und dann im nächsten Zyklus mit einer veränderten Situation umgehen muss. Aber drei Unterschiede in der physischen Version dieser Schleife sind der Grund, warum dieser Beitrag überhaupt existiert, und keiner davon ist kosmetischer Natur.

Die Konsequenzen sind physisch, nicht nur informationell. Wenn ein Software-Agent das falsche Tool aufruft, ist das Fehlerbild eine schlechte API-Antwort, eine beschädigte Datei oder im schlimmsten Fall ein Sicherheitsvorfall – ernst, aber durch ein Rollback, einen Patch oder eine Entschuldigung reversibel. Wenn die Policy eines physischen Agenten die falsche Handlung ausgibt, hat sich der Aktor bereits bewegt, bevor jemand eingreifen kann. Eine fallengelassene Ladung, eine Kollision, eine gequetschte Hand sind keine Zustände, die man zurückrollt. Es ist dieselbe Asymmetrie der Reversibilität, die physische KI generell von generativer KI unterscheidet, und genau deshalb muss jede Schicht des Agentic Engineering – Harness, Evaluation, Governance – nach einem höheren Maßstab gebaut sein, wenn die „Handlung“, die eine Policy ausführt, ein Motorbefehl ist und keine Textvervollständigung.

Latenz hat harte, physikalisch bedingte Fristen, keine UX-bedingten. Ein Software-Agent, der drei Sekunden länger für eine Antwort braucht, verschlechtert die Nutzererfahrung. Ein Roboterarm, der mitten im Greifvorgang drei Sekunden länger für eine Entscheidung braucht, hat bereits fallen gelassen, was er hielt, denn die Schwerkraft wartet nicht auf eine Netzwerkrunde. Genau deshalb muss die Steuerungsschicht des Physical-AI-Stacks lokal, auf dem Roboter selbst, innerhalb eines Echtzeitbudgets laufen – ein Zwang, der sich architektonisch in der Dual-System-Aufteilung moderner Policy-Modelle zeigt, bei der ein schnelles, niedrigstufiges Aktionsmodul mit hoher Frequenz läuft, während ein langsameres Reasoning-Modul seltener plant. Agentic Engineering für physische KI erbt genau diese Einschränkung: Der Harness, der das Policy-Modell umgibt, darf selbst keine Latenz einbringen, die die Steuerungsschleife nicht mehr auffangen kann.

Der Harness muss physische Sicherheit umfassen, nicht nur Ausführungs-Sandboxing. Der Harness eines Coding-Agenten begrenzt den Wirkungsradius innerhalb eines Containers, eines Berechtigungsbereichs, eines Rate-Limits. Keines dieser Konzepte stoppt einen Roboterarm. Das physische Äquivalent einer Sandbox ist eine Reihe technischer Maßnahmen, die teils softwareseitig, teils hardware- und firmwareseitig erzwungen werden: ein sicherheitszertifizierter, überwachter Stopp, Geschwindigkeits- und Abstandsüberwachung, Kraft- und Leistungsbegrenzung, Geofencing. Das sind die vier Methoden der Mensch-Roboter-Kollaboration, die in der Normenreihe ISO 10218 formalisiert sind, und sie existieren genau deshalb, weil „das Modell hat entschieden, das nicht zu tun“ kein akzeptables Sicherheitsargument ist, wenn ein Mensch neben dem Roboter steht. Ein Harness für einen physischen Agenten muss davon ausgehen, dass die Policy irgendwann falschliegt, und die Konsequenz dieses Fehlers physikalisch begrenzen, nicht nur berechtigungstechnisch.

Harness Engineering: Was das Policy-Modell auf einem realen Roboter umgibt

Harness Engineering umfasst im Vokabular des Agentic Engineering die Ausführungsumgebung, die Werkzeuge, das Kontextmanagement, die Lebenszyklusbehandlung, die Beobachtbarkeit, die Verifikation und die Governance rund um ein Modell – alles, was aus einem leistungsfähigen Modell ein System macht, das sich tatsächlich unbeaufsichtigt betreiben lässt. Auf einem Roboter hat jeder dieser Teilbereiche ein physisches Gegenstück, und genau in dieser Übersetzung steckt der Großteil der tatsächlichen Ingenieurarbeit.

Ausführung und Werkzeuge werden zur Steuerungsschicht: der Middleware – heute in der Produktivrobotik meist ROS 2 –, die die übergeordnete Absicht einer Policy empfängt („Objekt greifen“, „zehn Zentimeter nach links bewegen“) und sie in niedrigstufige, sicherheitsgeprüfte Motorbefehle übersetzt, die ein Aktor ausführt. Diese Schicht muss in Echtzeit sicherstellen, dass ein Befehl aus einem Vision-Language-Action-Modell das Drehmomentlimit eines Gelenks nicht überschreitet und einen Arm nicht über eine Arbeitsraumgrenze hinausführt, bevor der Befehl den Motor überhaupt erreicht. Der Tool-Aufruf eines Coding-Agenten gelingt entweder sauber oder scheitert sauber; der Tool-Aufruf eines Roboters muss unabhängig davon, was die Policy verlangt hat, durch eine sicherheitsgeprüfte Übersetzungsschicht laufen.

Kontextmanagement wird zur Sensorfusion, die das Weltmodell speist. Der Kontext eines Software-Agenten wird auf Abruf bereitgestellt – ein abgerufenes Dokument, ein zurückgegebenes Tool-Ergebnis. Der Kontext eines Roboters wird kontinuierlich durch die eigene Bewegung des Roboters erzeugt: Das Drehen einer Kamera verändert, was das nächste Bild zeigt; das Schließen eines Greifers verändert, was ein Kraftsensor als Nächstes misst. Der Roboter-Sensor-Stack existiert genau dafür, diesen verrauschten, unvollständigen, selbst erzeugten Strom aus exterozeptiven und propriozeptiven Signalen in eine einzige, brauchbare Zustandsschätzung zu verwandeln – das physische Äquivalent von Context Engineering, nur dass die „Dokumente“ Kamerabilder sind, die dutzende Male pro Sekunde eintreffen, und der Abrufschritt ein Kalman-Filter oder ein trainiertes Fusionsmodell ist statt einer Datenbankabfrage.

Lebenszyklus und Beobachtbarkeit werden zur flottenweiten Überwachung des Betriebszustands eines Roboters – Batterie- und Energiestatus, Zustand von Gelenken und Antriebsstrang, Aufgabenfortschritt, Lokalisierungsgenauigkeit sowie Sicherheitsereignisse, kontinuierlich erfasst und versioniert zusammen mit jedem Update des auf dem Roboter laufenden Policy-Modells. Während Lebenszyklusmanagement bei einem Software-Agenten meist bedeutet, einen Prompt oder einen Modell-Checkpoint zu versionieren, muss Lebenszyklusmanagement bei einem Roboter Firmware, Middleware und Policy-Versionen gemeinsam verfolgen, weil eine Unstimmigkeit zwischen ihnen genau die Art von Integrationsfehler ist, die an der Nahtstelle zwischen Schichten auftritt, nicht innerhalb einer einzelnen Schicht – die Schnittstelle zwischen einem Foundation-Modell wie Isaac GR00T und der Middleware, die dessen Ausgabe übersetzt, ist eine dokumentierte Quelle genau dieser Art von Reibung.

Governance wird zur Sicherheitszertifizierung. Die Governance-Schicht eines Software-Agenten sind Audit-Protokolle, Freigabe-Workflows, Nutzungsrichtlinien. Die Governance-Schicht eines physischen Agenten enthält all das, ergänzt aber um eine formale, externe, auditierbare Anforderung, die in reiner Software-KI kein Äquivalent hat: die Zertifizierung gegen Sicherheitsnormen wie die ISO-10218-Reihe, bevor das System überhaupt in der Nähe von Menschen betrieben werden darf. An einer Zertifizierungspflicht lässt sich nicht per A/B-Test vorbeitesten, und keine noch so ausgefeilte Prompt-Konstruktion ersetzt sie. Das ist wohl der klarste Punkt, an dem Agentic Engineering bei der Anwendung auf physische KI abweicht: Governance ist dann kein Richtliniendokument mehr, sondern ein Hardware-und-Prozess-Tor mit einer Zertifizierungsstelle auf der anderen Seite.

Gedächtnis über die Betriebsdauer eines Roboters: Arbeit, Sitzung, Langzeit

Das dreistufige Gedächtnismuster, das im Design von Software-Agenten üblich ist – Arbeitsgedächtnis (das aktuelle Kontextfenster), Sitzungsgedächtnis (was in dieser Konversation oder diesem Aufgabendurchlauf geschah) und Langzeitgedächtnis (ein persistenter Speicher, auf den der Agent über Sitzungen hinweg zugreifen kann) –, überträgt sich auf physische KI mit denselben drei Stufen, aber die physische Ausprägung jeder Stufe ist neben ihrem Software-Gegenstück kaum wiederzuerkennen.

Das Arbeitsgedächtnis ist die Zustandsschätzung, kontinuierlich durch Sensorfusion im Roboter-Sensor-Stack aufgebaut und verschwindet in dem Moment, in dem sie durch die nächste Sensormessung ersetzt wird. Das Kontextfenster eines Software-Agenten bleibt bestehen, bis es explizit geleert wird oder die Konversation endet. Das Arbeitsgedächtnis eines Roboters wird ständig neu berechnet und kennt kein Äquivalent zum „Zurückscrollen“ – ist die Zustandsschätzung gerade jetzt falsch, handelt der Roboter gerade jetzt auf Basis eines falschen Weltbilds, ohne die Möglichkeit, mitten in der Bewegung auf eine frühere, bessere Schätzung zurückzugreifen. Deshalb wird die Qualität der Sensorfusion als technisches Kernproblem behandelt, nicht als Detail der Vorverarbeitung: Eine fehlerhafte Aktualisierung des Arbeitsgedächtnisses erzeugt bei einem Roboter keine etwas schlechtere Antwort, sondern eine falsche Handlung.

Das Sitzungsgedächtnis ist eine Aufgabenepisode – ein einzelner Greifvorgang, eine einzelne Zustellfahrt, eine einzelne Manipulationssequenz –, die zur Überprüfung, zur Fehlersuche und, entscheidend, zur späteren Verwendung als Trainingsdaten protokolliert wird. Genau hier treffen sich Teleoperation und Datenerfassung mit dem Gedächtnisdesign: Eine aufgezeichnete Episode, in der ein menschlicher Operator die korrekte Handlung demonstriert, ist funktional ein gelabeltes Trainingsbeispiel, keine bloße Protokollzeile. Das Sitzungsgedächtnis eines Software-Agenten beeinflusst den nächsten Zug derselben Konversation. Das Sitzungsgedächtnis eines Roboters beeinflusst häufiger die komplett nächste Version des Policy-Modells über ein Neutraining, als die nächste eigene Handlung des Roboters innerhalb derselben Aufgabe.

Das Langzeitgedächtnis ist der angesammelte Demonstrations- und Simulationskorpus, der in den nächsten Feinabstimmungsdurchlauf eines Foundation-Modells wie Isaac GR00T oder einer vergleichbaren Vision-Language-Action-Policy zurückfließt – keine abrufbare Wissensdatenbank, die ein Agent mitten in der Aufgabe befragt, so wie ein Software-Agent eine Vektordatenbank abfragen könnte. Das ist ein strukturell anderes Verhältnis zum Gedächtnis: Das Langzeitgedächtnis eines Software-Agenten wird zur Inferenzzeit gelesen; das Langzeitgedächtnis eines Roboters wird zur Trainingszeit verbraucht, gebündelt und als neuer Policy-Checkpoint ausgeliefert, statt live abgerufen zu werden. Die praktische Konsequenz ist, dass „das Gedächtnis eines Roboters aktualisieren“ meist einen Neutrainings- und Neuauslieferungszyklus bedeutet, keinen Datenbankschreibzugriff – näher an einem Software-Release als an einem Agenten, der sich selbst eine Notiz anhängt.

Evaluation: Warum Simulation die Testsuite des physischen Agenten sein muss

Die Evaluation eines Software-Agenten lässt einen Agenten gegen zurückgehaltene Aufgaben in einer Sandbox-Umgebung antreten und bewertet die Ergebnisse, bevor irgendetwas den Produktivbetrieb erreicht. Physische KI hat mit Simulation und digitalen Zwillingen ein direktes strukturelles Äquivalent – nur dass die Kostenasymmetrie eines fehlgeschlagenen Evaluationslaufs Evaluation in der physischen KI zu einer deutlich schwereren Investition macht, als sie die meisten Software-Agenten-Teams je aufbringen.

Ein fehlgeschlagener Evaluationslauf in einer sandboxbasierten Software-Umgebung kostet Rechenzeit und schlimmstenfalls einen unangenehmen Protokolleintrag. Ein fehlgeschlagener Evaluationslauf auf realer Roboter-Hardware kann die Hardware selbst kosten, das gehandhabte Produkt, tagelangen Stillstand oder – der Fall, den jede Sicherheitsnorm in diesem Bereich verhindern soll – eine Verletzung. Genau diese Kostenasymmetrie ist der Grund, warum Teams für physische KI Policies durch Tausende oder Millionen simulierter Durchläufe schicken, bevor sich ein einziger realer Aktor bewegt, warum Domain Randomization (Training unter absichtlich variierten simulierten Bedingungen) und Real-to-Sim-Transfer (der Nachbau präziser Simulationen aus Realweltdaten) als Kerndisziplinen behandelt werden und nicht als optionaler Feinschliff, und warum die Sim-to-Real-Lücke – der gemessene Rückgang der Erfolgsquote, laut einer Übersichtsarbeit aus dem Jahr 2025 auch bei aggressiver Domain Randomization etwa 15 bis 30 Prozent – als eigenständige, benannte Kennzahl verfolgt wird, statt in einen allgemeinen „Genauigkeitswert“ einzufließen, wie es eine Evaluationssuite eines Software-Agenten in einer einzigen Zahl tun könnte.

Es gibt eine zweite Ebene der Evaluation physischer KI, die Software-Agenten selten brauchen: Evaluation muss an den Nahtstellen zwischen den Schichten des Stacks stattfinden, nicht nur an der Ausgabe der Policy. Ein Vision-Language-Action-Modell kann auf einem zurückgehaltenen Manipulations-Benchmark gut abschneiden und trotzdem scheitern, sobald seine Ausgaben die sicherheitsgeprüfte Übersetzung der Steuerungsschicht in Motorbefehle durchlaufen – weil der Benchmark die Policy isoliert bewertet hat, nicht den vollständigen Harness, in dem die Policy auf dem tatsächlichen Roboter läuft. Einen physischen Agenten zu evaluieren bedeutet mit anderen Worten, die Schleife zu evaluieren, nicht das Modell – die Lücke zwischen „das Modell ist gut“ und „das System ist sicher zu betreiben“ zu schließen ist der Großteil der eigentlichen Arbeit.

Governance und Aufsicht: Was „Mensch in der Schleife“ bei 200 Hz bedeutet

Menschliche Aufsicht über einen Software-Agenten bedeutet typischerweise einen Freigabeschritt irgendwo in der Schleife – ein Mensch prüft eine vorgeschlagene Handlung vor der Ausführung oder prüft im Nachhinein ein Audit-Protokoll. Dieses Muster bricht in dem Moment zusammen, in dem die Schleife schneller läuft, als ein Mensch sie sinnvoll überprüfen kann. Eine Vision-Language-Action-Policy, die ihr schnelles, niedrigstufiges Aktionsmodul ausführt, kann Motorbefehle in einer Frequenz von mehreren hundert Hertz ausgeben; es gibt keine Version von „ein Mensch gibt diesen Schritt frei“, die in dieses Zeitbudget passt.

Was die Freigabe pro Handlung in einem gut konstruierten physischen Agenten ersetzt, ist Aufsicht, die im Voraus in die Sicherheitshülle eingebaut ist, statt Handlung für Handlung ausgeübt zu werden. Die Sicherheitszertifizierung gegen die ISO-10218-Reihe ist ein solcher Mechanismus – Aufsicht, die einmal, rigoros, vor dem Einsatz ausgeübt wird, statt kontinuierlich während des Betriebs, und die begrenzt, wozu das System physisch überhaupt fähig ist, unabhängig davon, was das Policy-Modell in einem gegebenen Zyklus ausgibt. Geschwindigkeits- und Abstandsüberwachung sowie Kraft- und Leistungsbegrenzung sind Aufsicht, ausgedrückt als Hardware- und Firmware-Beschränkung, nicht als Prüf-Workflow. Und Teleoperation – derselbe Kanal, der zur Erfassung von Trainingsdaten dient – fungiert zugleich als Aufsichts-Rückfallebene: Ein menschlicher Operator kann die direkte Kontrolle übernehmen, wenn die Konfidenz der automatisierten Schleife sinkt oder eine Situation außerhalb der Trainingsverteilung der Policy liegt – eine materiell andere Art von „Mensch in der Schleife“ als der Freigabe-oder-Ablehnung-Button eines Chatbots.

Hier gewinnt die Governance-Schicht physischer KI zudem eine regulatorische Dimension, die Software-Agenten größtenteils noch nicht tragen: Das Maschinensicherheitsregelwerk, das ein Roboter erfüllen muss, steht neben der entstehenden KI-spezifischen Regulierung, und für Teams, die in der EU tätig sind, greifen beide zunehmend ineinander – ein Thema, das unser Cluster zu Markt und Regulierung im Kontext von EU-KI-Verordnung und Maschinenverordnung behandelt. Die praktische Konsequenz für ein Ingenieurteam lautet: Governance für einen physischen Agenten ist kein Richtliniendokument, das neben dem Code liegt. Es ist eine Zertifizierungsanforderung, die erfüllt sein muss, bevor der Harness überhaupt laufen darf.

Wo die Praxis des Agentic Engineering für physische KI noch scheitert

Eine Handvoll Fehlermuster wiederholt sich häufig genug, um sie direkt zu benennen, und die meisten davon entstehen dadurch, dass ein mentales Modell aus der Software-Agenten-Welt unverändert übernommen wird, ohne es an die oben beschriebenen physischen Einschränkungen anzupassen.

Simulation als optionalen Feinschliff behandeln statt als primären Evaluationsharness. Teams unter Zeitdruck kürzen die simulierte Evaluation manchmal und verlassen sich auf Tests an realer Hardware, um „die echten Fehler ohnehin zu finden“. Das kehrt die Kostenstruktur um: Ausfälle an realer Hardware sind die teuren. Die Sim-to-Real-Lücke existiert genau deshalb, weil Simulation und Realität auseinanderdriften – aber die Simulation zu überspringen schließt diese Lücke nicht, es verschiebt lediglich die Entdeckung jedes Fehlermodus auf die teuerste mögliche Oberfläche.

Die Gedächtnisarchitektur eines Software-Agenten kopieren, ohne Arbeits-, Sitzungs- und Langzeitgedächtnis physisch wie logisch sauber zu trennen. Ein Team, das die Zustandsschätzung eines Roboters so behandelt, als würde sie wie eine Chat-Sitzung fortbestehen, wird irgendwann auf Basis veralteter Sensordaten handeln. Die physischen Ausprägungen dieser Stufen – eine kontinuierlich neu berechnete Zustandsschätzung, eine protokollierte Aufgabenepisode, ein zur Trainingszeit verbrauchter Trainingskorpus – sind nicht austauschbar, und sie zu vermischen ist eine häufige Quelle subtiler, schwer zu debuggender Fehler.

Annehmen, ein cloudgehosteter Policy-Aufruf sei unproblematisch, weil „das Modell klug genug ist“. Die Fähigkeit eines Modells lockert kein hartes Echtzeitbudget. Braucht die Steuerungsschleife eine Entscheidung innerhalb von Millisekunden und beinhaltet der Policy-Aufruf eine Netzwerkrunde, ist die Genauigkeit des Modells irrelevant dafür, ob das System sicher ist – das ist genau die Spannung zwischen schneller und langsamer Schleife, um die herum der Physical-AI-Stack gebaut ist, und keine noch so große Modellverbesserung ersetzt es, den sicherheitskritischen Pfad lokal zu halten.

Sicherheitszertifizierung erst am Ende anflanschen, statt den Harness von Anfang an darum herum zu entwerfen. Teams, die die ISO-10218-Konformität als letzten Punkt einer Checkliste behandeln, statt als Einschränkung, die von Beginn an Steuerungsschicht und Aktorenauswahl formt, stellen regelmäßig spät fest, dass ihre Architektur überarbeitet werden muss, um die Zertifizierung zu bestehen – ein teurer Zeitpunkt, um eine Governance-Lücke zu entdecken.

Beobachtbarkeit unterinvestieren und einen flottenweiten Fehlermodus erst entdecken, wenn er bereits weit verbreitet ist. Weil die Fehlermodi eines physischen Agenten sicherheitsrelevant sind und nicht nur qualitätsrelevant, ist das Argument für eine frühe Investition in flottenweite Telemetrie und Anomalieerkennung stärker als das entsprechende Argument bei einem Software-Agenten, bei dem eine schlechte Ausgabe meist durch die nächste Nutzerinteraktion aufgefangen wird und nicht durch einen Verletzungsbericht.

Eine Startcheckliste für Teams, die agentische physische KI bauen

Ordnet man die oben genannten Bausteine in eine grobe Reihenfolge: Definieren Sie zuerst die Harness-Grenze, bevor Sie eine Zeile Policy-Code schreiben – welcher sicherheitszertifizierte Stopp, welche Geschwindigkeits- und Kraftgrenzen, welches Geofencing begrenzt dieses System, unabhängig davon, was das Modell entscheidet. Bauen Sie danach den Evaluationsharness in Simulation auf und behandeln Sie die Sim-to-Real-Lücke als verfolgte Kennzahl, nicht als nachträglichen Gedanken, bevor reale Hardware die Policy unbeaufsichtigt ausführt. Entwerfen Sie die drei Gedächtnisstufen ausdrücklich und getrennt voneinander – Zustandsschätzung, Episodenprotokollierung und Neutrainingskorpus –, statt anzunehmen, dass sich das Kontextfenster-Muster eines Software-Agenten übertragen lässt. Halten Sie den sicherheitskritischen Steuerungspfad lokal und innerhalb eines Echtzeitbudgets, und behandeln Sie jede cloudgehostete Modellinferenz als langsame Schleife, die die schnelle niemals blockiert. Und bauen Sie Governance von Anfang an ein: Zertifizierungsanforderungen und menschliche Aufsichts-Rückfallkanäle wie Teleoperation gehören in die ursprüngliche Architektur, nicht in die Checkliste vor dem Rollout.

Nichts davon ersetzt den zugrunde liegenden Physical-AI-Stack – die Weltmodelle, VLA-Policies, ROS-2-Middleware und Edge-Computing, die das eigentliche Wahrnehmen, Entscheiden und Bewegen leisten. Was Agentic Engineering hinzufügt, ist die Disziplin, diesen Stack zuverlässig, unbeaufsichtigt und im großen Maßstab zu betreiben – eine andere Aufgabe, als das Modell klüger zu machen, und bei einem Roboter eine Aufgabe mit einer deutlich höheren Messlatte dafür, was „zuverlässig“ bedeuten muss. Die vollständige, Schicht für Schicht aufgebaute Darstellung des Stacks, auf dem dieser Rahmen aufsetzt, finden Sie im Themen-Hub zum Physical-AI-Stack; präzise Definitionen der in diesem Beitrag verwendeten Begriffe bietet das Glossar.