Eine Frage, die mir im Workshop und im Meetup immer wieder begegnet, klingt ungefähr so: „Manchmal macht der Agent genau das, was ich will, manchmal halluziniert er sich was zusammen — und ich weiß vorher nie, welcher Tag heute ist.“
Das liegt weder am Modell noch am Pech, sondern an einem fehlenden Bild davon, was da passiert. Und das passt in einen Satz: Ein Agent ist ein Modell plus ein Harness. Wer diese Trennung im Kopf hat, kann bei jedem Fehlschlag sagen, welcher Teil versagt hat — statt am einzigen Regler zu drehen, den er kennt, und den Prompt zum zehnten Mal umzuformulieren.
Die zwei Teile
Erst das Verhalten, dann der Begriff. Schau dir an, was passiert: Cursor liest selbst eine Datei. Es ändert sie. Es führt einen Test aus. Es schreibt nochmal. Zwischen diesen Schritten hast du nichts getippt. Genau das nennt man einen Agent.
Technisch stecken zwei Teile dahinter.
Das Modell — Claude, GPT, Gemini. Es sieht Text und schreibt Text. Es hat ein Kontextfenster, also einen begrenzten Platz für alles, was es gerade „weiß“. Und es schreibt nicht direkt in deine Dateien. Es schickt Anfragen: „Bitte lies diese Datei“, „bitte ändere jene Zeile“.
Der Harness — die App drumherum: Cursor, Claude Code, Codex CLI. Er stellt dem Modell die Werkzeuge bereit, mit denen es etwas tun kann: Dateien lesen, Dateien ändern, Befehle ausführen, im Projekt suchen. Er bestimmt, was im Kontext landet — System-Prompt, geöffnete Dateien, bisheriger Verlauf. Und er kann vor und nach jedem Werkzeug eigene Prüfungen laufen lassen, sogenannte Hooks, die etwas auch blockieren können.
Dazwischen läuft eine Schleife: Der Harness schickt dem Modell eine Anfrage. Das Modell antwortet, oft mit dem Wunsch, ein Werkzeug zu benutzen. Der Harness führt das Werkzeug aus und gibt das Ergebnis zurück. Das Modell antwortet erneut. So lange, bis es „fertig“ sagt.
Der erste praktische Schluss daraus: Cursor ist nicht „der Agent“, sondern der Harness. Der Agent ist ein Modell, das in diesem Harness arbeitet. Anderer Harness, gleiches Modell — und du bekommst anderes Verhalten.
Warum die Trennung der eigentliche Hebel ist
Der Nutzen zeigt sich, sobald etwas schiefgeht. Statt eines diffusen „der Agent spinnt“ hast du jetzt zwei getrennte Fragen:
- Hat das Modell falsch geraten — oder war der Kontext schlicht nicht da, den es gebraucht hätte?
- War das Werkzeug falsch erlaubt (oder gar nicht erlaubt) — oder war das Modell für die Aufgabe zu schwach?
Ohne die Trennung kannst du das nicht auseinanderhalten. Du drehst am Prompt, weil das der einzige Regler ist, den du siehst, und wunderst dich, dass es nicht besser wird.
Tatsächlich ist der Prompt der schwächste der Regler. Er steuert nur, was du sagst. Härter wird es beim Kontext: Was sieht das Modell überhaupt? Am härtesten sind Hooks und Werkzeug-Rechte: Was darf der Agent tun, deterministisch erzwungen, egal wie das Modell gerade gelaunt ist. „Mehr Prompt“ ist fast nie die Antwort. Die wirksamen Regler liegen im Harness — und den hast du selbst in der Hand.
Augen oder Hände — die Frage bei jeder Harness-Erweiterung
Wenn du dem Agenten etwas Neues gibst, ist das immer eine von zwei Entscheidungen: Gibst du ihm Augen oder Hände?
Augen sind Werkzeuge, die nur lesen dürfen. Ein Werkzeug, mit dem der Agent Test-Logs einsehen kann, ist risikoarm und sofort nützlich. Geht etwas schief, hat er nichts kaputt gemacht, nur geschaut.
Hände sind Werkzeuge, die etwas verändern oder ausführen — Dateien schreiben, Skripte starten. Ein Werkzeug, das den Agenten ein Migrations-Skript laufen lässt, braucht einen Hook davor, der prüft und im Zweifel stoppt.
Die meisten Teams geben unbewusst zu früh zu viele Hände. Die nützlichere Frage bei jedem neuen Werkzeug ist: Braucht der Agent hier wirklich Hände, oder reichen Augen? Augen sind billig und sicher. Hände brauchen eine Sicherung.
Das ist nicht meine private Theorie
Falls das nach einer hübschen Vereinfachung für Workshops klingt: Die Formel hat eine nachvollziehbare Herkunft und breite Übernahme. Geprägt hat sie Vivek Trivedy im LangChain-Blog, „The Anatomy of an Agent Harness“ (März 2026):
„Agent = Model + Harness.“
Ein Harness ist dort alles an Code, Konfiguration und Ausführungslogik, was nicht das Modell selbst ist. Birgitta Böckeler von Thoughtworks greift die Formel auf martinfowler.com auf — „Harness“ habe sich als Kurzformel für genau diese Trennung etabliert. Und Addy Osmani von Google Chrome bringt die Konsequenz auf den Punkt:
„A decent model with a great harness beats a great model with a bad harness.“
Sogar Anthropic, der Hersteller eines der Modelle, veröffentlicht selbst Rezepte für den Bau guter Harnesses — etwa den Essay „Effective harnesses for long-running agents“ (November 2025). Der Kerngedanke dahinter: Jede Komponente im Harness steckt eine Annahme darüber ab, was das Modell allein nicht zuverlässig kann.
Und OpenAI verdichtet die Rollenverteilung auf vier Worte:
„Humans steer. Agents execute.“
Menschen steuern, Agenten führen aus.
Es bleibt nicht bei der Begrifflichkeit. Stripe, Ramp und OpenAI haben unabhängig voneinander beschrieben, wie sie ihre eigenen Agent-Systeme bauen — und sind auf dieselben Grundentscheidungen gekommen: eine isolierte Arbeitsumgebung statt des Laptops, eine kuratierte Auswahl an Werkzeugen statt „alle“, knapp gehaltene Regel-Dateien, deterministische Schritte rund um den Agenten herum, und Augen-und-Hände, die in echte Systeme verdrahtet sind. Bei Stripe gehen auf diese Weise nach eigener Darstellung über 1.300 vom Agenten erzeugte Pull Requests pro Woche durch — jeweils von Menschen reviewt.
Das wichtigere Detail steckt in OpenAIs eigener Modell-Doku: Ein neues Modell sei kein einfacher Austausch, man müsse den Harness drumherum neu einstellen — Werkzeug-Beschreibungen, Stop-Kriterien, Ausgabeformat. Wenn schon der Hersteller sagt, dass die Arbeit im Harness sitzt und nicht im Modellwechsel, dann ist das Argument „ein Modell-Upgrade reicht“ erledigt. Und der Harness gehört dir — unabhängig davon, welches Modell gerade vorne liegt.
Was du ab heute anders machst
Drei Dinge, die ohne weiteres Tooling auskommen:
Sortier den nächsten Fehlschlag, bevor du reagierst. Modell-Problem oder Harness-Problem? Hat das Modell falsch geschlossen, oder hat ihm Kontext gefehlt, war ein Werkzeug falsch gesetzt? Die Antwort entscheidet, wo du eingreifst — und erspart dir die Prompt-Würfelei.
Mach den Kontext einmal sichtbar. Frag dich: Was sieht das Modell, wenn ich Enter drücke? Wenn du das nicht benennen kannst, ist das dein nächster Hebel — nicht ein besserer Prompt, sondern besserer Kontext.
Bau eine Harness-Verbesserung statt zehn Prompt-Versuche. Ein Fehler, der immer wiederkommt, gehört nicht in den nächsten Prompt, sondern in einen Hook, eine Regel oder ein Stück Kontext. Das wirkt dann bei jedem weiteren Lauf, nicht nur bei diesem einen.
Genau dieser dritte Schritt — einen Fehler in eine feste Regel zu übersetzen — ist der Punkt, an dem aus deinem persönlichen KI-Coding eine Sache wird, die ein ganzes Team trägt. Aber das ist ein eigenes Thema.
Das Modell wird besser, weil Anthropic, OpenAI oder Google ein neues ausliefern — darauf hast du keinen Einfluss. Auf deinen Harness schon, denn der wird besser, weil du dazulernst.
Verwandt dazu, warum dieselbe KI starke Teams stärker und schwache schneller chaotischer macht: KI ist kein Gleichmacher.
Ich schreibe regelmäßig über solche Patterns aus der täglichen Arbeit mit Claude Code und Codex. Lies weitere Artikel oder, wenn du das an deiner eigenen Codebase einüben willst: Im 1:1 KI Coding Coaching arbeiten wir 90 Minuten auf deinem echten Code statt an einem Spielzeugbeispiel.