KI ist ein starkes Werkzeug, wenn ein sauberer Rahmen für die Zusammenarbeit geschaffen wird. Context, Harness und Loop Engineering sind drei Begriffe, die die verschiedenen Ebenen beschreiben, die nahtlos ineinander greifen sollten, um den größtmöglichen Outcome in der Zusammenarbeit mit KI zu erreichen. Prompt Engineering, also die Optimierung des Befehls, wird dabei zweitrangig. Wer die Ebenen nicht trennt, behandelt einen falschen Agentenlauf als Prompt-Problem statt als Systemfehler und nimmt schwächere Ergebnisse in Kauf. Die Sortierung ist deshalb keine Begriffsklauberei, sondern die Voraussetzung dafür, den richtigen Hebel zu finden.

Drei Ebenen, die ständig verwechselt werden

Context Engineering ist die unterste Ebene. Anthropics Applied-AI-Team beschreibt sie als die Arbeit, für jede einzelne Antwort genau die Informationen auszuwählen und aktuell zu halten, die das Modell dafür braucht, und alles andere wegzulassen.¹ Der Unterschied zum Prompt Engineering liegt darin, dass diese Kuratierung nicht einmal stattfindet, sondern vor jedem einzelnen Aufruf neu. Die Regel dazu ist ein Weglass-Auftrag: die kleinstmögliche Menge hochwertiger Token finden, die das gewünschte Ergebnis wahrscheinlich macht.

Harness Engineering sitzt darüber und beschreibt die Umgebung, in der ein einzelner Agent handelt: Systemprompt, Werkzeuge, Skills, MCP-Anbindungen, Sandbox, Rechte, Hooks, Dateigedächtnis und die Prüfungen, an denen ein Ergebnis scheitern kann.

Loop Engineering sitzt noch eine Ebene höher und beschreibt das System, das einen Agenten wiederholt anstößt, Helfer startet, Ergebnisse verifiziert und den Zustand weiterträgt, ohne dass ein Mensch Zug um Zug promptet. Addy Osmani hat den Begriff am 7. Juni 2026 geprägt, ausgelöst von Boris Chernys Satz „I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops".²

Die Reihenfolge ist keine Geschmacksfrage. Jede Ebene erbt die Schwächen der darunterliegenden und ein Loop, der ein lückenhaftes Harness immer wieder aufruft, macht den Fehler nicht kleiner, sondern nur schneller.

Woher Harness Engineering kommt und was der Begriff verrät

Harness Engineering entstand nicht am Reißbrett, sondern als Beschreibung einer Gewohnheit. Mitchell Hashimoto hielt Anfang 2026 eine Stufe seiner KI-Nutzung fest, auf der er einen Agentenfehler nicht mehr korrigiert, sondern eine Vorkehrung baut, damit genau dieser Fehler nicht wiederkommt.³ Kurz darauf berichtete OpenAI von einem Projekt nach derselben Logik, in dem über Monate kein Code von Hand getippt wurde.⁴

Aus dieser Herkunft lässt sich mehr ableiten als eine Arbeitstechnik. Ein Harness wächst aus Fehlern, nicht aus einem Konzept. Wer es vorab durchplant, baut Vorkehrungen gegen Probleme, die er noch nicht hat. Jede Vorkehrung ist eine Annahme darüber, was das Modell nicht allein kann, und sie altert, weil mit jedem Modellwechsel ein Stück Gerüst überflüssig werden kann.⁵ Und die wirksamen sind unspektakulär. Gegen die typischen Fehlmuster langlaufender Agenten hilft kein besseres Modell, sondern eine maschinenlesbare Anforderungsliste, eine Fortschrittsdatei und ein fester Startpunkt.⁶

Das ist der eigentliche Befund hinter dem Begriff. Ein Harness ist keine Modellarbeit, sondern Buchführung über den Zustand einer Aufgabe.

Warum das Produktentscheidungen sind

Die Bestandteile klingen technisch, die Entscheidungen darin sind es nicht.

Auf der Context-Ebene ist ein endliches Aufmerksamkeitsbudget zu verteilen. Jedes Token verbraucht Kapazität und die Genauigkeit sinkt messbar, je voller das Fenster wird.¹ Zu entscheiden, was hineindarf und was draußen bleibt, ist Priorisierung unter Knappheit, also der Kern von Produktarbeit.

Auf der Harness-Ebene entscheidet der Zuschnitt der Werkzeuge über den Funktionsumfang. Ken Aizawa argumentiert, dass gute Agentenwerkzeuge nicht die vorhandene Schnittstelle spiegeln, sondern entlang der Arbeitsabläufe geschnitten werden, die ein Agent wirklich braucht.⁷ Wer die Werkzeuge zuschneidet, legt damit fest, welche Aufgaben überhaupt in Reichweite liegen. Das ist eine Scope-Entscheidung, auch wenn sie in einer technischen Definition steht.

Auf der Loop-Ebene entscheidet die Abbruchbedingung. Ein Loop ohne erreichbares Ziel, ohne Budget und ohne Prüfung, die ihn beendet, ist kein autonomes System, sondern ein unbeaufsichtigter Kostenposten.

Der Rahmen, der Autonomie erst trägt

Die drei Ebenen sagen, wo ein Problem sitzt, noch nicht, womit man sie füllt. Diese Lücke bearbeitet ein Ansatz, der seit 2025 unter dem Namen Spec-Driven Development läuft. Er dreht die übliche Reihenfolge um: Vor der Umsetzung steht eine Spezifikation und die ist nicht die Vorstufe der Wahrheit, sondern die Wahrheit selbst. GitHub nennt das den Wechsel von „Code ist die Quelle der Wahrheit" zu „Absicht ist die Quelle der Wahrheit".⁸ Birgitta Böckeler fasst das Artefakt schärfer: ein strukturiertes, verhaltensorientiertes Dokument in natürlicher Sprache, das Mensch und Agent gemeinsam als Bezugspunkt nutzen.⁹ Sie vergrößert den Raum, in dem ein Agent allein arbeiten darf, weil sie beschreibt was gelten soll statt wie es hergestellt wird. Kief Morris nennt die tragfähige Haltung „an der Schleife": nicht jedes Ergebnis abnehmen, sondern die Prüfungen bauen, an denen es sich messen lassen muss.¹⁰

Damit schließt sich der Kreis zur Harness-Ebene. Eine Spezifikation ist Rahmen und Prüfmaßstab in einem: Sie sagt vorher, was gelten soll und liefert hinterher das Kriterium, an dem ein Ergebnis scheitern darf. Autonomie entsteht deshalb nicht dadurch, dass man einem Agenten mehr erlaubt, sondern dadurch, dass vorher feststeht, woran sein Ergebnis gemessen wird. Wer keine prüfbare Abnahmebedingung formulieren kann, kann nicht delegieren. Neu ist nur, wie schnell sich das rächt, wenn am anderen Ende niemand sitzt, der stutzt.

Hier endet dieser Artikel bewusst beim Prinzip. Die operative Ableitung, also wie eine solche Spezifikation im Produktalltag konkret aussieht, welche Felder sie trägt und wie man sie in Auftragspakete übersetzt, mit denen ein Agent allein arbeiten kann, nimmt sich der zweite Teil dieser Reihe vor.

Kritische Einordnung

Das Vokabular ist Monate alt und nicht gesetzt. Dieselben drei Wörter werden je nach Sprecher unterschiedlich weit gefasst. In Diskussionen darüber geht mehr Zeit verloren als in der Sache. Besser die Ebene beschreiben, statt sich auf das Etikett zu verlassen.

Bei den Belegen lohnt Zurückhaltung. Der OpenAI-Bericht ist die Erfahrungsbeschreibung eines Anbieters über sein eigenes Werkzeug, die Anthropic-Beiträge stammen von der Firma, deren Modelle darin laufen. Belastbarer ist Harness-Bench: Dort treten Modelle und Harness-Konfigurationen unter gleichen Bedingungen gegeneinander an. Die Leistung variiert erheblich je nach Paarung.¹¹

Der ernstere Einwand kommt von Osmani. Er nennt drei Risiken: fehlende Verifikation („A loop running unattended is also a loop making mistakes unattended"), schleichenden Verständnisverlust und die Bequemlichkeit, zu den Ergebnissen keine eigene Meinung mehr zu haben.² Dazu kommt die Gegenrichtung: Ein Harness kann Prüfungen so lange stapeln, bis von der Autonomie nichts übrig bleibt. Gartner sagt für Ende 2027 voraus, dass über 40 Prozent der agentischen KI-Projekte abgebrochen werden, unter anderem wegen steigender Kosten.¹² Wo die Grenze zwischen genug und zu viel verläuft, muss sich erst zeigen.

Der Übertrag in den Produktalltag

Bei der Fehlersuche. Wenn ein Ablauf nicht liefert, ist die erste Frage nicht, wie man den Prompt umformuliert, sondern auf welcher Ebene das Problem sitzt. Keine Prüfschleife der Welt repariert ein Context-Problem. Drei verschiedene Ebenen bedeuten drei verschiedene Budgets und drei verschiedene Zuständigkeiten.

Bei der Spezifikation. Wer eine KI-gestützte Funktion beschreibt, muss zwei Fragen beantworten, die in klassischen Anforderungen oft implizit bleiben: Was weiß das System vorher, und woran scheitert sein Ergebnis hinterher. Die erste Frage ist eine Context-Entscheidung, die zweite eine Abnahmebedingung. Solange beide fehlen, ist die Autonomie eines Agenten nicht begrenzt, sondern nur unbeobachtet.

Bei der Wartung. Jede Vorkehrung, die als Reaktion auf einen Fehler entstand, hat ein Verfallsdatum, das niemand notiert. Und Prüfungen, die nur auf einem Rechner oder in einer Anleitung existieren, wandern nicht mit. Eine Prüfung, die jemand von Hand wieder anschließen muss, ist keine Prüfung, sondern eine Absichtserklärung.