Gurtsystemtechnik: Die Umgebung, die KI-Agenten zuverlässig macht.

Übergeben Sie einem brillanten Ingenieur eine Aufgabe ohne Werkzeuge, ohne Dokumentation, ohne Sicherheitsprüfungen und ohne Möglichkeit, das Ergebnis zu überprüfen – das Ergebnis wäre unvorhersehbar. Ein rohes großes Sprachmodell, das als Agent eingesetzt wird, befindet sich in dieser Situation. Die Ingenieurwissenschaft der Agentenentwicklung ist das Fachgebiet, das dies behebt: Es geht um die Gestaltung der gesamten Umgebung, in der ein Agent arbeitet, einschließlich Werkzeugen, Speicher, Schutzmechanismen, Rückkopplungsschleifen und Ausführungssandboxen.

Die grundlegende Formel lautet Agent = Modell + Harness. Das Modell übernimmt die Logik und Entscheidungsfindung. Alles Weitere gehört zum Harness: wie Tools integriert werden, das Speichermanagement, Sandboxes, Schutzmechanismen, die Auswahl des Kontexts, Planungshilfen sowie die Rückkopplungsschleifen, die sicherstellen, dass ein Produktionsagent zuverlässig und sicher funktioniert. Databricks formuliert es wie folgt: Ohne Harness kann ein Modell zwar Fragen beantworten, aber keinen Code zuverlässig ausführen, APIs aufrufen, auf Dateien zugreifen, frühere Arbeiten merken oder mehrstufige Workflows eigenständig abschließen.

Diese Idee stellt den dritten Schritt in einer Entwicklung dar. Die Prompt-Engineering-Methodik fragte, was gesagt werden soll. Das Context-Engineering fragte, welche Informationen bereitgestellt werden sollen. Das Harness-Engineering fragt, welches System gebaut werden soll.

Sechs Komponenten eines Harness

Branchenartikel weisen im Allgemeinen auf die folgenden Bestandteile hin:

1. Tool-Integration, die das Modell über definierte Protokolle mit externen APIs, Datenbanken, Code-Executoren sowie maßgeschneiderten Tools verbindet.
2. Speicher und Zustand, die als Arbeitskontext, Sitzungszustand und Langzeitgedächtnis strukturiert sind und über ein Kontextfenster hinaus bestehen bleiben.
3. Kontext- und Prompt-Management, das dynamisch bestimmt, was bei jedem Modellaufruf angezeigt wird.
4. Planung und Aufteilung, bei der dem Modell strukturierte Abläufe Schritt für Schritt vorgegeben werden, anstatt alles auf einmal zu verlangen.
5. Überprüfung und Sicherheitsmechanismen, die Validierungsprüfungen, Formatüberprüfungen, Sicherheitsfilter sowie selbstkorrigierende Schleifen umfassen.
6. Modularität, d.h. Komponenten, die unabhängig ein- oder ausgeschaltet oder ersetzt werden können.

Warum das wichtig ist

Agenten breiten sich überall aus – von Support-Bots über Assistenten für finanzielle Analyse bis hin zu autonomen Programmierwerkzeugen. Die meisten, die in der Praxis versagen, tun dies, weil die zugrundeliegende Infrastruktur brüchig, unsicher oder unvorhersehbar ist, und nicht, weil das zugrundeliegende LLM schwach ist. Vier Gründe erklären dies:

• Es verlagert die Arbeit vom Hoffen auf Ingenieurskunst. Anstelle von improvisiertem Programmieren und Glückwünschen sorgen strukturierte Einschränkungen sowie deterministische Rückmeldungen dafür, dass Ergebnisse vorhersehbar und wiederholbar sind.
• Es verringert die Überprüfungsbelastung. Eine gute Infrastruktur erhöht die Chance auf einen korrekten ersten Versuch und bietet außerdem einen Mechanismus, der so viele Probleme wie möglich behebt, bevor ein Mensch sie sieht.
• Es ermöglicht echte Autonomie. Ohne sie ist ein Agent nur ein aufgewerteter Chatbot. Mit ihr kann er Code ausführen, APIs aufrufen, Dateien lesen, frühere Arbeiten speichern und mehrstufige Workflows abschließen.
• Es macht Agenten für die Produktion geeignet. Birgitta Böckeler beschreibt auf Martin Fowlers Website zwei Arten von Steuerung: Leitfäden, die Vorsteuerungen sind, die den Agenten vor seiner Aktion lenken, und Sensoren, die Rücksteuerungen sind, die ihm helfen, nach der Aktion Korrekturen vorzunehmen. Diese Kombination unterscheidet Demo-Agenten von Produktions-Agenten.

Der zentrale Kreislauf

Die meisten Agenten folgen einem Zyklus aus Überlegen, Handeln und Beobachten:

1. Überlegen: Das Modell liest alles im Kontext ein (Aufgabe, Gedächtnis, vorherige Ergebnisse) und wählt die nächste Aktion aus.
2. Handeln: Die Steuerungssoftware führt diese Aktion aus, beispielsweise indem sie ein Tool aufruft, Code in einer isolierten Umgebung ausführt, eine API aufruft oder etwas im Speicher speichert.
3. Beobachten: Die Steuerungssoftware erfasst das Ergebnis und gibt es dem Modell als neuen Kontext zurück.
4. Wiederholen – das Modell verwendet dieses Ergebnis, um erneut eine Entscheidung zu treffen.

Das zentrale Gestaltungsprinzip ist eine klare Aufteilung der Verantwortlichkeiten. Das Modell schlägt vor, der Handler führt aus und überprüft dabei Schemata, Berechtigungen, Budgets sowie Sicherheitsregeln. Das Modell ruft niemals direkt Tools auf: Es gibt einen strukturierten Aufruf zurück, den der Handler validiert, autorisiert, ausführt und das Ergebnis einfügt. Durch diese Trennung bleiben die Agenten sicher und überprüfbar: Aktionen werden protokolliert, Fehlschläge liefern weiterhin ein strukturiertes Ergebnis, und das Risikoniveau bestimmt den Ausführungsweg.

Ursprung des Begriffs

Die Geschichte ist kurz.

• Von 2022 bis 2024 war die Ära der Prompts. Entwickler verbrachten unzählige Stunden damit, Formulierungen, Strukturen und Beispiele zu optimieren, um bessere Ergebnisse zu erzielen.
• Mitte 2025 wandte sich die Aufmerksamkeit dem Kontext zu. Was das Modell sieht, ist genauso wichtig wie die Art und Weise, wie es gefragt wird, weshalb das Abrufen, Komprimieren sowie das Verwalten des Kontextfensters in den Vordergrund rückten.

Am 5. Februar 2026 veröffentlichte Mitchell Hashimoto, Mitbegründer von HashiCorp und Schöpfer von Terraform, einen Beitrag, in dem er eine Gewohnheit beschrieb: Immer wenn ein Agent einen Fehler machte, baute er eine dauerhafte Korrektur in dessen Umgebung ein, sodass genau dieser Fehler strukturell unmöglich wurde. Er nannte dies „Engineering the harness“ und formulierte es ungefähr so: Immer wenn ein Agent einen Fehler begeht, nehmen Sie sich die Zeit, eine Lösung zu entwickeln, damit er auf diese Weise nie wieder Fehler macht.

Am 11. Februar veröffentlichte OpenAI eine umfassende technische Rückschau zur Entwicklung und Bereitstellung eines Produkts ohne manuell geschriebenen Code, die dieses Konzept bestätigte.

Im März veröffentlichte Anthropic einen Nachfolgebeitrag, in dem eine vollständige Architektur mit drei Agenten beschrieben wurde, und Thoughtworks, Databricks, Red Hat, LangChain sowie andere stellten detaillierte Anleitungen bereit. Der Begriff hatte sich nun durchgesetzt.

Prinzipien, die Bestand haben

1. Das Modell schlägt vor, die Ausführungseinheit setzt um. Lassen Sie niemals das LLM Tools direkt aufrufen. Diese Trennung ist die Grundlage für ein sicheres Agentendesign.
2. Jeder Toolaufruf liefert ein Ergebnis – auch bei Fehlern. Egal ob Erfolg, Genehmigungsverweigerung oder Zeitüberschreitung – all das sollte dem Agenten als strukturierte Beobachtung übermittelt werden. Stiller Versagen ist der Feind der Autonomie.
3. Risiken verändern den Ablauf. Verwenden Sie mindestens drei Ebenen: nur-Lese-Operationen, die autonom ausgeführt werden, Entwürfe, die Arbeit simulieren ohne externe Nebeneffekte, sowie externe Schreibvorgänge, die eine Genehmigung erfordern.
4. Sammeln Sie den Kontext, werfen Sie ihn nicht einfach hin. Anstatt jede gesamte Konversation in jeder Runde weiterzugeben, strukturieren Sie sie in Schichten: systemweite Richtlinien, auf die jeweilige Aufgabe zugeschnittene Anweisungen sowie laufzeitbezogene Hinweise, die gerade rechtzeitig abgerufen werden. Markieren Sie unzuverlässige Daten entsprechend.

Weisen Sie langfristigen Aufgaben Budgets zu. Jeder Zyklus benötigt Grenzen für die Anzahl der Schritte, die verstrichene Zeit, die Token (pro Zug und kumulativ) sowie die Kosten in Dollar.

Verwandeln Sie wiederkehrende Fehler in Funktionen des Tools. Wenn ein Tool ständig fehlerhafte Antworten liefert, ist eine Anpassung der Anfrage nicht die richtige Lösung. Schreiben Sie einen Validator ins Tool, wo dauerhafte Reparaturen stattfinden sollten.

Kombinieren Sie rechnerische und inferenzielle Sensoren. Linter, Typprüfer und Testläufer liefern schnelle, zuverlässige Rückmeldungen. KI-basierte Code-Reviews sowie LLMs als Urteilsinstanz kümmern sich um semantische Fragen, die deterministische Tools nicht bewältigen können. Die erfolgreichsten Teams legen Wert auf deterministische Einschränkungen, die Garantien bieten.

Verwalten Sie die Entropie. Von KI erzeugter Code sammelt im Laufe der Zeit Unordnung an, daher sollten regelmäßig Reinigungsmechanismen für die Konsistenz der Dokumentation, Scans nach Konstruktionsverstößen, Durchsetzung von Mustern und Abhängigkeitsprüfungen ausgeführt werden.

Beginnen Sie einfach. Philipp Schmids Rat lautet, große Kontrollflüsse zu vermeiden und stattdessen solide, atomare Werkzeuge bereitzustellen, das Modell den Plan erstellen zu lassen sowie Schutzmechanismen, Wiederholungsversuche und Überprüfungen hinzuzufügen. Die bittere Lektion ist, dass Pipelines, die 2024 umfangreiche manuelle Programmierung erfordern, 2026 oft bereits mit einem einzigen Prompt abgewickelt werden können – daher sollten Hilfsmittel so konstruiert werden, dass die kluge Logik von gestern entfernt werden kann, sobald das Modell aufgeholt hat.

Drei Säulen

Einige Praktiker organisieren die Arbeit anhand von drei Säulen statt sechs Komponenten:

• Kontextengineering: Dem Agenten zur richtigen Zeit die richtigen Informationen zur Verfügung zu stellen, indem statische Dokumente mit aktuellen Überwachungsdaten kombiniert werden.
• Architektonische Einschränkungen: Durch maschinelle Kontrolle gute Codequalität durchzusetzen, unter Verwendung von schichtweisen Abhängigkeiten, Lintern, Strukturtests und pre-commit Hooks.
• Entropieverwaltung: geplante Aufräumarbeiten, damit Codebasen, die von KI erstellt wurden, nicht verfallen.

Ein günstiger Trick mit großem Effekt

LangChain berichtete, dass bereits eine Änderung auf der Ebene des Harnesses allein seine Punktzahl im Terminal Bench 2.0 von 52,8 % auf 66,5 % steigerte – was einen Sprung von außerhalb der Top 30 in die Top 5 bedeutete. Die Änderung bestand aus einem „Reasoning-Sandwich“: hoher Aufwand für Planung und Überprüfung sowie mittlerer Aufwand für die Implementierung. Das Modell blieb unverändert, was zeigt, wie weit alleinige Änderungen am Harness gehen können. Die Tiefe des Harnesses variiert bei den heutigen führenden Programmieragenten erheblich.

Fazit

Die Frage hat sich von der Suche nach besseren Anfragen hin zur Entscheidung darüber verschoben, welches System entwickelt werden soll. Das Modell ist nicht mehr das Produkt, sondern das Framework. Was eine beeindruckende, kontrollierte Demonstration von einem in der realen Welt funktionierenden Produktionsystem unterscheidet, ist das Framework – daher benötigt jeder, der 2026 Agenten entwickelt, dieses. Ein praktischer erster Schritt besteht darin, eine aktuelle Konfiguration anhand der oben genannten sechs Komponenten und neun Prinzipien zu überprüfen, die fehlenden Elemente zu identifizieren und sie in das Framework einzubauen.