Agent Harness Engineering: Zustände, Überprüfung und Steuerung rund um das Modell

Wenn ein leistungsstarkes Modell dennoch versagt

Stellen Sie sich einen Agenten vor, der über das beste Modell auf dem Markt verfügt, ein sorgfältig abgestimmtes Systemprompt, Dutzende von Tools sowie ein Kontextfenster, das groß genug für eine ganze Codebasis ist. Dennoch kann er bei einer Aufgabe scheitern, die jeder kompetente Ingenieur als Routineaufgabe betrachten würde. Er wählt die richtige Aktion aus, führt sie jedoch falsch aus. Er findet den entscheidenden Fakt, verliert ihn aber, wenn der Kontext zurückgesetzt wird. Er bearbeitet zehn Dateien korrekt und integriert versehentlich eine leichte Regression in die elfte. Er verbringt eine Stunde damit, ein von ihm selbst verursachtes Problem zu debuggen. Er könnte sogar einen überzeugenden Bericht schreiben, in dem steht, die Arbeit sei abgeschlossen, obwohl nichts überprüft wurde.

Die übliche Reaktion besteht darin, an der Anweisung zu arbeiten: eine weitere Anleitung, ein weiteres Beispiel, mehr Kontext, der Appell, vorsichtig zu sein. Das hilft eine Weile, dann nicht mehr. Der tiefere Fehler liegt im mentalen Modell, das das Modell als Agenten und alles darum herum als Einstellungen betrachtet. Diese Sichtweise bricht zusammen, sobald ein Agent kontinuierlich in einer echten Umgebung laufen muss.

Ein Produktionsagent ist nicht einfach nur ein Modell mit Anweisungen drumherum. Es handelt sich um ein Laufzeitsystem: Es speichert Zustände, führt Aktionen aus, kommuniziert mit externen Systemen, bewältigt Fehler, nimmt Feedback entgegen und benötigt Methoden zur Wiederherstellung, Überprüfung sowie Steuerung. Die Disziplin, die sich um dieses Laufzeitsystem entwickelt hat, wird als Agent-Harness-Engineering bezeichnet. Vergleichen Sie dies mit der Prompt-Technik: Während das Prompt-Engineering darauf abzielt, das Modell anzuweisen, wie es sich verhalten soll, fragt das Harness-Engineering danach, wie eine Umgebung geschaffen werden kann, in der das Modell zuverlässig ein Ziel erreichen kann. Es handelt sich dabei nicht um eine verbesserte Prompt-Technik, sondern um eine andere Abstraktion, die sowohl das beschreibt, was das Modell schreibt, als auch das, was das System tun kann, was nach einem Fehler erhalten bleibt, was erlaubt ist und was als abgeschlossen gilt.

Eine Laufzeitumgebung für ein probabilistisches Modell

Das einfachste Bild eines Agents ist ein Modell mit einer Anweisung und einigen Werkzeugen. Das reicht aus, um eine einzelne Schlussfolgerung zu verstehen, ist jedoch unzureichend für einen Produktionsagenten, der besser als eine laufende Umgebung verstanden werden sollte, die auf einem probabilistischen Modell basiert.

Das Modell übernimmt das Denken. Die Steuerungsstruktur bestimmt die Bedingungen, unter denen dieses Denken in Ausführung umgesetzt wird: Was das Modell wahrnimmt, was es erreichen kann, welche Aktionen erlaubt sind, welcher Zustand beibehalten wird und welche Beweise vor einer Erfolgserklärung benötigt werden.

Nehmen wir einen Programmieragenten, dessen Anweisung lautet, zunächst die Architektur zu überprüfen, Tests auszuführen und unverwandte Komponenten unberührt zu lassen. Diese Anweisungen beschreiben lediglich die Absicht und verpflichten nicht zu etwas Bestimmtem. Ein Framework kann bestimmte Dateien schreibbar machen und andere nicht, nach jeder Änderung Validierungen durchführen, verbotene Operationen blockieren, Fortschritte speichern und sich weigern, die Aufgabe ohne Beweise zu schließen. Somit legt die Anweisung fest, was der Agent tun soll, während das Framework entscheidet, was das System zulässt und was als erledigt gilt. Das Modell liefert die Intelligenz, und das Framework verwandelt sie in etwas, das bedient werden kann.

Drei Ebenen des Engineerings

Das Agent-Engineering hat sich durch drei zunehmend abstraktere Ebenen entwickelt: Anweisungen, anschließend Kontext und schließlich das Framework.

Prompt-Engineering beantwortet die Frage, was das Modell tun soll. Es verbessert Anweisungen, Beispiele, Toolbeschreibungen sowie Verhaltensgrenzen und funktioniert bei einfachen Aufgaben außergewöhnlich gut. Doch ein Prompt ist lediglich eine Anweisung und verfügt nicht über Durchsetzungskraft. Ein Agent, dem gesagt wird, Tests durchzuführen, kann trotzdem Erfolg vortäuschen, ohne sie tatsächlich auszuführen. Wenn der Laufzeitumgebung unbegrenzter Zugriff gewährt wird, bedeutet die Anweisung, Produktionsdateien unberührt zu lassen, wenig. Die Aufforderung, eine Entscheidung sechs Stunden lang im Gedächtnis zu behalten, steht im Widerspruch zu allen anderen Informationen, die in den Kontext gelangen.

Der Kontextengineering-Ansatz befasst sich mit dem nächsten Problem, nämlich womit das Modell zum Zeitpunkt der Entscheidung vertraut sein sollte. Das Abrufen von Informationen, Fähigkeiten, das Gedächtnis, Ergebnisse von Werkzeugen, strukturierte Zustände, schrittweise Offenlegung von Informationen sowie Komprimierung tragen alle dazu bei, einen besseren Entscheidungskontext zu schaffen – das Ziel verschiebt sich dabei von mehr Kontext hin zu einem besseren Kontext. Dennoch kann das Modell eine falsche Aktion wählen, den Zustand verfälschen, die Validierung überspringen, in einer Schleife stecken bleiben oder den Erfolg zu früh erklären.

Dort beginnt die Ingenieurarbeit, mit der Frage, welches System das Modell umgeben sollte, damit die Aufgabe zuverlässig erledigt wird. Es liefert das, was allein Anfragen und Kontext nicht bieten können: einen dauerhaften Zustand, eingeschränkte Tools, Berechtigungen, Isolation, Überprüfung, Wiederherstellung, Bewertung und Beobachtbarkeit. Zudem verändert es den ingenieurtechnischen Prozesszyklus. Ein Fehler erfordert nicht mehr nur eine Neuformulierung der Anfrage – stattdessen stellt sich die Frage, welche Kontrolle gefehlt hat. Die Antwort könnte ein Validator, ein strengeres Tool-Vertragsmodell, eine Richtliniengrenze, ein Checkpoint, eine Wiederherstellungsstrategie oder bessere Sichtbarkeit sein. Jeder Fehler führt zu einer Änderung des Systems.

Das Ergebnis ist ein Ratchet-Prinzip für die Steuerungssysteme: Zunächst tritt ein Versagen auf, anschließend fehlt eine Kontrolle, danach wird das Steuerungssystem verbessert, gefolgt von einer Überprüfung und schließlich einer stabilen Grundlage. Prompt-Engineering verbessert das, was dem Modell mitgeteilt wird, während Context-Engineering das erweitert, was es weiß. Harness-Engineering verbessert die Bedingungen, unter denen das Modell arbeitet, und sorgt dafür, dass es immer schwieriger wird, auf dieselbe Weise zweimal zu versagen.

Was die Laufzeitverwaltung bewältigt

Falls das Steuerungssystem die Laufzeitverwaltung darstellt, was enthält sie? Anstatt Aufgaben wie Prompts, Tools, Speicher und Orchestrierungskodierung aufzuzählen, ist es nützlicher, die Verantwortlichkeiten der Laufzeitverwaltung zu benennen.

• Der Kontext bestimmt, was das Modell für seine nächste Entscheidung wissen muss: Anweisungen, abgerufenes Material, Fähigkeiten, relevante Tool-Ausgaben sowie aktuelle Beobachtungen.

Der Zustand speichert das, was über Neuinitialisierungen des Kontexts und Prozessgrenzen hinaus bestehen muss: Fortschritt, Entscheidungen, Artefakte, Kontrollpunkte und Validierungsresultate.

Aktionen definieren, wie das Reasoning über APIs, Datenbanken, Dateisysteme, Codeausführung, MCP-Server und ähnliche Funktionen auf die Umgebung einwirkt.

Die Steuerung bestimmt durch Autorisierung, Richtlinien, Sandboxing, Ressourcenlimits und andere vorgeschriebene Grenzen, welche Aktionen erlaubt sind.

Feedback gibt an, welche Aktionen zu welchen Ergebnissen geführt haben, und zwar durch Tests, Validatoren, Laufzeitsignale, Health Checks und Evaluatoren.

Die Wiederherstellung legt fest, wie die Arbeit nach einem Fehler fortgesetzt wird – durch Wiederholungsversuche, Neuplanung, Kontrollpunkte, Fortsetzbarkeit oder Eskalation.

Die Beobachtbarkeit sichert die für die Erklärung dessen notwendigen Informationen: Absicht, Kontext, Aktionen, Richtlinienentscheidungen, Zustandsänderungen, Fehler, Überprüfungen und Ergebnisse.

Es handelt sich dabei nicht um sieben unabhängige Funktionen, und es müssen auch keine sieben Dienste sein. Zusammen bilden sie eine Steuerungsschleife um ein probabilistisches Modell. Sobald diese Schleife stundenlang statt nur Minuten lang läuft und Kontextgrenzen, Ausfälle, Wiederholversuche sowie Änderungen der Arbeitsprozesse übersteht, beginnt die Architektur wie etwas auszusehen, was Ingenieure bereits gut kennen – ein verteiltes System.

Das Kontextfenster ist kein Zustandsspeicher

Einer der einfachsten Fehler bei der Konzeption von Agenten besteht darin, das Kontextfenster als Speicher zu betrachten.

Das ist eine verlockende Angewohnheit. Das Modell kann den gesamten Dialog, frühere Toolaufrufe, Entscheidungen sowie Zwischenergebnisse einsehen, weshalb das Hinzufügen weiterer Inhalte harmlos erscheint. Doch das Arbeitsfenster ist ein Arbeitsset und keine Datenbank. Nichts darin ist dauerhaft: Ein Neustart, eine Kürzung oder eine Komprimierung kann es verkleinern oder vollständig ersetzen. Seine Erweiterung erhöht zwar die Kapazität, lässt die Dauerhaftigkeit aber unverändert.

Bei einem langlaufenden Agenten muss der autoritative Zustand der Aufgabe an einem anderen Ort gespeichert werden: das Ziel, abgeschlossene und ausstehende Arbeiten, Entscheidungen, Artefakte, Kontrollpunkte, Validierungsresultate sowie Verweise auf externe Ressourcen. Der Kontext wird anschließend aus diesem Zustand entsprechend dem, was das Modell gerade benötigt, neu aufgebaut. Der Unterschied ist einfach: Der Kontext ist das, was das Modell sieht, und der Zustand ist das, was das System weiß.

Durch Komprimierung wird das deutlich. Ein Agent, der drei Stunden damit verbracht hat, ein Repository zu ändern, kann Hunderte von Tool-Aufrufen, aufgegebene Ansätze sowie gemachte Beobachtungen anhäufen. Die Zusammenfassung dieser Historie kann den nächsten Kontext nutzbar machen, doch eine Zusammenfassung bleibt eine Interpretation dessen, was geschehen ist; daher sollte der kritische Zustand nicht von dem abhängen, was der Kompressor beibehalten hat. Stattdessen kann das Framework einen neuen Kontext aus dem dauerhaften Zustand in dieser Reihenfolge erstellen: Zustand der Aufgabe, relevante Artefakte, aktuelle Beobachtungen, Fähigkeiten und schließlich der Kontext des Modells.

Checkpoints wenden dasselbe Prinzip bei Prozessabstürzen an, und strukturierte Übergaben wenden es bei Agenten oder Arbeitern an. Ein Nachfolger benötigt den Zustand, der zum korrekten Weitermachen erforderlich ist, nicht die gesamte Konversation seines Vorgängers. Die architektonische Frage lautet, welche Informationen unabhängig vom Kontext überleben müssen – und sobald diese Frage gestellt wird, verwandelt sich die Kontextverwaltung in ein Zustandsmanagement-Problem.

Lange laufende Agenten sind verteilte Systeme

Wenn ein Agent stunden- oder tagelang läuft, funktioniert das vertraute Request-und-Response-Modell nicht mehr. Ein Prozess kann absterben, ein Tool kann einen Zeitüberschreitungsfehler aufweisen, oder ein Worker kann nach Abschluss einer Operation, aber vor der Meldung daran, verschwinden. Zwei Worker können dieselbe Aufgabe übernehmen, und der Kontext eines Modells kann mitten im Lauf verschwinden. All das ist nichts Ungewöhnliches, denn es handelt sich um klassische Probleme verteilter Systeme, und ein langlaufender Harness benötigt explizite Ausführungssemantiken, um damit umzugehen.

Falls die Arbeit länger bestehen kann als der Worker, müssen Grenzen für das Eigentum an der Aufgabe gesetzt werden. Ein Leasing ermöglicht es einem Worker, eine Aufgabe für eine begrenzte Zeit für sich zu beanspruchen, und Heartbeats liefern einem externen Beobachter ein Signal über die Aktivität des Workers. Wenn der Worker verschwindet, läuft das Leasing ab, und ein anderer kann von dem dauerhaften Zustand aus fortfahren.

Wiederholte Anfragen erfordern sorgfältige Handhabung. Stellen Sie sich einen Agenten vor, der eine Bereitstellung sendet und die Anfrage vor dem Erreichen eines Ergebnisses abbricht. Eine blinde Wiederholung könnte die Bereitstellung zweimal ausführen. Deshalb benötigen Agentenwerkzeuge die gleichen Garantien wie in anderen verteilten Systemen: Betriebsidentifikatoren, Idempotenz, explizite Fehlerzustände sowie einen klaren Verantwortlichen für das Wiederholungsverhalten.

Dann gibt es das Wiederaufnehmen. Eine lange Aufgabe sollte als dauerhafter Fortschritt dargestellt werden und nicht als Gespräch im Arbeitsspeicher, nach einem Zyklus aus Checkpoint, Ausführung, Beobachtung, Speicherung und Fortsetzung. Wenn die Ausführung auf halbem Weg stoppt, muss das System herausfinden, ob der aktuelle Schritt sicher zum Wiederholen ist, bereits gespeichert wurde, teilweise abgeschlossen ist oder eine Kompensation erfordert. Das Wiederaufnehmen bedeutet nicht, alles noch einmal abzuspielen – es bedeutet vielmehr, den minimalen Zustand wiederherzustellen, der für eine sichere Fortsetzung erforderlich ist. Die Übergabe folgt demselben Muster: Ein neuer Prozess erhält das Ziel, die Entscheidungen, die Ergebnisse, den Validierungsstatus sowie die ausstehende Arbeit – aber nichts vom Chatverlauf eines anderen Prozesses.

Das legt die zentrale Zuverlässigkeitsgrenze fest. Sobald ein Agent länger existieren kann als sein Prozess, ist der Prozess nicht mehr die Zuverlässigkeitseinheit – vielmehr ist es die dauerhafte Aufgabe.

Die Überprüfung ist die andere Hälfte der Agenz

Ein Agent kann Code schreiben, eine Bereitstellung durchführen, eine Datenbankabfrage erstellen oder die Infrastruktur ändern. Etwas zu generieren ist nicht dasselbe wie es richtig umzusetzen, und das riskante Muster besteht darin, dem Agenten das letzte Wort darüber zu überlassen, ob seine eigene Arbeit erfolgreich war – wie beispielsweise in einer Nachricht, die besagt, der Authentifizierungsablauf sei abgeschlossen und alle Tests bestanden hätten. Das Framework sollte dies nicht als Beweis akzeptieren; es sollte stattdessen die Tests ausführen. Ebenso sollte eine Behauptung, der Dienst sei funktionsfähig, Gesundheitsprüfungen auslösen anstatt die Aufgabe zu beenden. Zudem sollte eine Datenmigration anhand von Schema- und Datenvariablen bewertet werden, statt auf der Interpretation des Modells bezüglich seiner eigenen Toolaufrufe. Der Glaube eines Agents, er habe Erfolg gehabt, ist kein zuverlässiges Signal für eine abgeschlossene Aufgabe.

Deshalb nutzen Produktionsumgebungen drei getrennte Rollen. Der Planer entscheidet, was geschehen muss. Der Ausführende erledigt begrenzte Aufgaben. Der Bewertende prüft, ob der resultierende Systemzustand den Anforderungen entspricht. Ein Modell kann alle drei Rollen übernehmen, doch ihre Verantwortlichkeiten bleiben getrennt.

Die Überprüfung sollte auf beobachtbaren Elementen beruhen, und deterministische Beweise sind die erste Wahl, wo immer sie verfügbar sind: Compiler, Testausführer, Schemavalider, Health Checks, Bereitstellungsstatus, Richtlinienprüfungen oder einfache Aussagen. Modellbasierte Bewertung ist nützlich, wenn die Korrektheit inhärent semantisch ist, erfordert jedoch konkrete Kriterien und nicht nur eine vage Frage danach, ob das Ergebnis gut aussieht. Die Vollendung wird somit zu einer Eigenschaft des Systems und nicht zu etwas, was das Modell aussagt: Anforderungen erfüllt, Validierung bestanden, erforderliche Artefakte vorhanden, Richtlinienprüfungen erfolgreich – erst danach gilt die Aufgabe als erledigt. Mit anderen Worten: Die Überprüfung liefert Beweise, und der Bewertende liest diese, um zu entscheiden, ob die Ausführung fortgesetzt werden darf; der Bewertende fungiert somit als Sensor im Rückkopplungszyklus des Systems. Der Agent treibt den Fortschritt voran, während das System die Beweise erstellt.

Von Anweisungen zur Durchsetzung

Einem Agenten kann mitgeteilt werden, dass er etwas nicht tun soll, ohne dass er dazu unfähig wird. Aussagen wie „Verändern Sie die Produktion nicht“, „Schreiben Sie nur innerhalb des Arbeitsbereichs“ und „Geben Sie niemals Zugangsdaten preis“ sind nützlich, doch keines davon stellt eine Sicherheitsgrenze dar, wenn die Laufzeitumgebung die entsprechende Aktion weiterhin zulässt. Anweisungen kommunizieren Absichten, während die Durchsetzung Invarianten schafft.

Die Tool-Design zeigt den Unterschied deutlich. Geben Sie einem Agenten eine generische execute_sql()-Funktion, so unterscheidet sich ihre Handlungsfläche erheblich von der eines Agenten, dem eine eingeschränkte, nur zum Lesen geeignete Abfrageschnittstelle zur Verfügung steht. Die eingeschränkte Schnittstelle lässt Raum für die Überprüfung der Autorisierung, die Validierung von Parametern, die Auditing von Operationen sowie zur Verkleinerung des Auswirkungsbereichs. MCP-Tools, APIs, Dateisysteme, Shells und externe Dienste funktionieren auf dieselbe Weise: Das Modell schlägt vor, und das Framework entscheidet, ob die Aktion ausgeführt werden darf – unter welcher Identität, mit welchen Berechtigungen, im jeweiligen Umfeld und gemäß welcher Richtlinie.

Eine praktische Faustregel ordnet die Einschränkungen nach ihrem Aufwand ein:

• Falls das Verletzen einer Einschränkung tolerierbar ist, reicht möglicherweise eine Anweisung aus.
• Falls das Verletzen kostspielig ist, fügen Sie Überprüfungen hinzu.
• Falls das Verletzen gefährlich ist, setzen Sie die Einschränkung an der Grenze durch.

Sandboxing führt eine zweite Dimension ein. Die Autorisierung entscheidet darüber, ob eine Aktion erlaubt ist. Eine Sandbox regelt hingegen, was geschieht, wenn der Agent unerwartet handelt. Grenzen im Dateisystem und Netzwerk, Ressourcenbeschränkungen sowie eng gefasste Zugangsdaten verhindern, dass unerwünschtes Verhalten größere Auswirkungen hat. Weiter entwickelte Systeme stellen außerdem nicht nur einzelne Toolaufrufe, sondern auch Workflow-Übergänge sicher. Eine Produktionseinrichtung bleibt so unerreichbar, solange die Tests nicht bestanden sind, der Staging-Betrieb stabil ist und jemand die Freigabe erteilt hat. Das Modell kann den Wechsel vorschlagen, doch die Laufzeitregeln entscheiden über seine Legalität. Das ähnelt eher einer Zustandsmaschine als dem Vertrauen in einen Satz in natürlicher Sprache. Es geht nicht darum, Intelligenz einzuschränken, sondern um die Begrenzung der Fähigkeiten und des Einflussradius.

Man kann nicht mit dem arbeiten, was man nicht beobachten kann

Die übliche Beobachtbarkeit beantwortet die Fragen, ob ein Service funktionsfähig ist, wo die Latenz zunimmt und welche Abhängigkeit versagt. Agentensysteme benötigen eine weitere Ebene. Wenn ein Agent versagt, geht es darum herauszufinden, was passiert ist und warum seine Entwicklung genau dorthin geführt hat. Was versuchte er zu erreichen? Welchen Kontext hatte er zur Verfügung? Welche Tools rief er auf? Welche Richtlinien ermöglichten oder blockierten diese Aufrufe? Welcher Zustand änderte sich? Welche Beweise überzeugten ihn davon, dass seine Aufgabe erledigt war? Das ist die Trajektorienbeobachtbarkeit.

Standardmäßige LLM-Metriken wie Tokens, Latenzzeit, Kosten, Modellversion sowie Eingaben und Ausgaben sind notwendig, reichen jedoch nicht aus, denn ein Modellaufruf ist nur ein einzelnes Ereignis innerhalb einer größeren Kette: Absicht, Kontext, Entscheidung, Aktion, Beobachtung, Zustand, Überprüfung und Ergebnis. Angenommen, ein Agent verbringt vierzig Minuten damit, einen Dienst zu migrieren, scheitert anschließend aber. Dass dabei 80.000 Tokens verbraucht wurden, sagt fast nichts aus. Eine nützliche Analyse könnte zeigen, dass das Tool ein veraltetes Migrationshandbuch heruntergeladen hat, der Agent eine nicht mehr unterstützte API verwendet hat, die Bereitstellung technisch erfolgreich war, die Integrationstests fehlschlugen und der Wiederherstellungsversuch genau dieselbe Strategie erneut anwandte. Das ist eine echte Diagnose.

Das bedeutet, dass der Kontext eine Herkunft benötigt: eine Möglichkeit, zu erkennen, welche Fähigkeiten, Dokumente, Zustände und Tool-Ergebnisse eine bestimmte Entscheidung geprägt haben. Auch Tool-Aufrufe benötigen einen kausalen Kontext, der den auslösenden Aufgabenschritt, die verwendete Identität, die bewertete Richtlinie sowie die Folgen umfasst. Richtlinienentscheidungen und Zustandswechsel sollten ebenso sichtbar sein, genauso wie die erfolgreichen Aktionen. Die aussagekräftigsten Metriken sind dabei verhaltensbezogen: Erfolgsrate der Aufgaben, Verifizierungsfehler, Erfolg bei der Wiederherstellung, vorzeitige Beendigung, abgelehnte Richtlinienanfragen, wiederkehrende Fehlermuster, Eskalationen durch Menschen sowie Anzahl der Schritte pro erfolgreicher Aufgabe.

Observabilität ist das, was den Ratschenmechanismus vervollständigt. Ein Fehler sollte mehr hinterlassen als nur einen Eintrag im Protokoll. Sein Verlauf sollte es ermöglichen, herauszufinden, was schiefgelaufen ist, und den fehlenden Kontrollmechanismus zu benennen – sei es eine Quelle im Kontext, ein Bewertungswerkzeug, eine Richtlinie, eine Grenze eines Tools, ein Kontrollpunkt oder eine Wiederherstellungsstrategie. Das Ziel ist ein System, das nicht auf dieselbe Weise zweimal versagen kann.

Eine neue Disziplin der Systementwicklung

Wenn man fragt, wie Agenten effektiver arbeiten können, erweitert sich die Antwort mit zunehmender Autonomie. Prompt Engineering optimiert die Anweisungen, Context Engineering passt die zur Entscheidungszeit verfügbaren Informationen an und Harness Engineering reguliert den gesamten Ausführungsvorgang: Zustand, Aktionen, Grenzen, Rückmeldungen, Wiederherstellung, Überprüfung und Observabilität. Sie ersetzen einander nicht, sondern bilden zunehmend umfassendere Bereiche.

Eine sinnvolle Aufteilung der Aufgaben sichert die Stabilität des Gesamtsystems: Das Modell kümmert sich um das Denken unter Unsicherheit, während die Laufzeit die Invarianten verwaltet. Eine Datei, die niemals geändert werden darf, erhält eine Grenze im Dateisystem. Ein Produktivsystem, das nicht überschrieben werden darf, unterliegt Autorisierungsprüfungen. Eine Migration, die erfolgreich sein muss, wird im Vergleich zum Ergebniszustand überprüft, und der Zustand von Aufgaben, der nach einem Neustart erhalten bleiben muss, wird gespeichert. Garantien dafür, dass die Laufzeit zuverlässiger funktionieren kann, sollten nicht vom Modell verlangt werden.

Produktionsagenten werden versagen, und ein Zeichen für ein ausgereiftes System ist das, was danach geschieht. Jeder Fehler wirkt sich auf den Laufzeitbetrieb aus. Wenn derselbe Fehler immer wieder auftritt, erhält er seinen eigenen Bewertungsfaktor. Wenn eine Aktion als riskant erweist, wird die dahinterliegende Fähigkeit eingeschränkt. Wenn Fortschritte verloren gehen, erscheint an der Stelle, an der sie fehlten, ein Checkpoint, und wenn die Wiederherstellung weiterhin fehlschlägt, übernimmt eine Eskalationsstrategie. Die Ausführung erzeugt Beweise, diese Beweise bringen fehlende Kontrollmechanismen zum Vorschein, und diese Kontrollmechanismen machen den nächsten Ausführungsvorgang stabiler.

Dies verändert auch die Art und Weise, wie Agenten bewertet werden. Die Frage lautet nicht mehr, wie gut das Modell ist, sondern vielmehr, inwieweit das gesamte System diese Art von Aufgaben zuverlässig erledigen kann. Harness Engineering ist kein weiteres Orchestrierungsframework – es handelt sich um ein Systemwissenschaften, das probabilistische Intelligenz zuverlässig macht. Eine Demo zeigt lediglich, dass ein Agent etwas einmal tun kann. Ein Produktionsystem muss dies hingegen zuverlässig, überprüfbar, wiederherstellbar und wiederholt tun, wobei jedes Versagen dazu beiträgt, die nächste Ausführung zu verbessern. Der größte Teil der schwierigen Arbeit findet sich hinter dem Prompt, in der Architektur von Zustands-, Feedback-, Überprüfungs-, Wiederherstellungs- und Steuerungsschleifen, die das Denken der Agenten in dauerhaftes Systemverhalten umwandeln.