Harness Engineering 2026: Warum das System zählt

Phillip Pham, AI Developer bei Pexon Consulting | 9 Min. Lesezeit | 21.09.2026

TL;DR: Harness Engineering in drei Sätzen

Harness Engineering ist die Arbeit am System um das Modell: Umgebung, Werkzeuge, Zustand zwischen Sitzungen und die Prüfung, ob ein Agent wirklich fertig ist. Seit Modelle Aufgaben über Stunden allein bearbeiten, entscheidet dieser Rahmen über Erfolg, nicht der Prompt. Pexon Consulting (ISO 27001) baut solche Harness-Schichten für Agenten in Unternehmensdomänen.

Das Problem: der Agent startet jede Sitzung bei null

Ein Agent, der eine Aufgabe in einer Sitzung erledigt, ist gelöst. Schwierig wird es, wenn die Arbeit länger dauert als ein Kontextfenster. Dann beginnt der nächste Lauf ohne Gedächtnis, rät den Stand und macht entweder etwas doppelt oder erklärt die Arbeit für erledigt.

Anthropic hat genau diese zwei Fehler im November 2025 beschrieben, im Artikel „Effective harnesses for long-running agents“. Erstens versucht der Agent, alles auf einmal zu bauen, und hinterlässt halbe Features, wenn der Kontext ausgeht. Zweitens sieht eine spätere Instanz Fortschritt und erklärt den Auftrag für fertig, obwohl Teile fehlen. Beide Fehler behebt kein besserer Prompt. Sie verschwinden erst, wenn die Umgebung den Stand trägt.

Was Harness Engineering ist

Die kurze Antwort: alles, was nicht das Modell ist. Ein Agent besteht aus Modell, Kontext und Harness. Der Harness entscheidet, welche Werkzeuge der Agent hat, wo er seinen Zustand ablegt, wie ein neuer Lauf den Stand erfasst und woran gemessen wird, ob eine Aufgabe erledigt ist.

Der Begriff grenzt sich von zwei Nachbarn ab. Context Engineering fragt, was in ein einzelnes Kontextfenster gehört. Harness Engineering fragt, wie viele Fenster, Sitzungen und Agenten zusammenarbeiten, ohne sich zu verlieren. Was ein Agent Harness technisch ist, erklären wir ausführlich in Agent Harness: warum das Modell nicht alles ist.

Unsere Position dazu ist klar: Wer heute fragt „welches Modell?“, stellt die zweite Frage zuerst. Modelle wechseln im Quartalstakt, der Harness bleibt. In ihm stecken die Regeln Ihrer Domäne, die Prüfstrecken und das Wissen, woran ein gutes Ergebnis erkennbar ist.

Baustein 1: eine lesbare Umgebung

Anthropics Antwort auf die zwei Fehler ist ein Initializer-Agent, der vor der eigentlichen Arbeit die Umgebung einrichtet. Er legt ein Startskript an, eine Fortschrittsdatei und einen ersten Git-Commit. Jeder spätere Agent arbeitet ein Feature nach dem anderen ab, committet mit sprechender Nachricht und pflegt die Fortschrittsdatei.

Die Feature-Liste ist der unterschätzte Teil. Im Beispiel von Anthropic enthielt sie über 200 Einträge, alle zunächst als nicht bestanden markiert. Der Agent darf sich nur hocharbeiten. Anthropic schreibt dazu, es sei inakzeptabel, Tests zu entfernen oder zu ändern, weil dann Funktionen fehlen oder fehlerhaft bleiben. Übertragen auf Unternehmen heißt das: Die Abnahmekriterien stehen vorher fest und gehören nicht dem Agenten.

So kann der Start einer solchen Umgebung aussehen:

#!/usr/bin/env bash
# init.sh: einmalige Einrichtung, jeder spätere Agent startet von hier
set -euo pipefail
npm ci
npm run dev > /tmp/dev-server.log 2>&1 &
# Stand für den nächsten Lauf sichtbar machen
echo "$(date -Iseconds) Umgebung gestartet" >> claude-progress.txt
jq '[.features[] | select(.passes == false)] | length' features.json

Baustein 2: Prüfung wie ein Nutzer

Ein Agent, der seinen eigenen Output nicht prüfen kann, meldet zu früh Erfolg. Anthropic lässt Features deshalb Ende zu Ende über Browser-Automatisierung testen, so wie ein Mensch die Anwendung bedient. Das findet Fehler, die im Code nicht sichtbar sind.

Wir raten, Prüfbarkeit vor Autonomie zu bauen. Bevor ein Agent einen Schritt allein gehen darf, muss feststehen, woran der Schritt als erledigt gilt: ein Test, eine Validierungsdatei, ein Screenshot-Vergleich oder eine Vier-Augen-Freigabe als fester Schritt. In regulierten Umgebungen ist diese Beweiskette zugleich der Nachweis für die Revision. Wer das auf verwalteten Plattformen umsetzt, findet bei Anthropic dafür inzwischen Bewertungsraster mit separatem Prüfer, beschrieben in unserem Guide zu Claude Managed Agents.

Baustein 3: wenige, generische Werkzeuge

Modelle kennen bash, grep und git aus sehr vielen Trainingsdaten. Eigens gebaute Werkzeuge mit langen JSON-Schemas kennen sie nicht, und jedes zusätzliche Werkzeug braucht Beschreibung, Pflege und Tests. Die Erfahrung aus unseren Agenten-Projekten: Ein kleines Set generischer Werkzeuge plus klare Rechte schlägt eine lange Liste spezieller Funktionen.

Das heißt nicht, dass Fachwerkzeuge verschwinden. Ein Zugriff auf das ERP oder die Dokumentenablage bleibt ein eigenes Werkzeug, oft über MCP. Die Frage lautet nur bei jedem Werkzeug: Kann der Agent das auch mit Dateien und Shell lösen? Wie diese Debatte zwischen MCP und Kommandozeile gerade geführt wird, zeigt unser Beitrag MCP vs CLI. Ein Satz, der hängen bleiben sollte: Wird Ihr Harness mit jedem neuen Modell komplexer, bauen Sie ihn zu groß.

Harness Engineering im Unternehmen: fünf Fragen vor dem Start

Im Mittelstand beginnt Harness Engineering selten mit Code, sondern mit Klarheit über den Prozess. Diese fünf Fragen klären wir, bevor ein Agent die erste Aufgabe allein bearbeitet:

1. Woran erkennt man „fertig“? Ohne vorher feste Abnahmekriterien, etwa eine Liste prüfbarer Punkte je Vorgang, erklärt der Agent früher oder später etwas für erledigt, das es nicht ist.
2. Wo liegt der Zustand? Fortschritt, offene Punkte und Zwischenergebnisse brauchen einen festen Ablageort, den jeder neue Lauf zuerst liest. Eine Datei oder ein Ticket reicht, ein Chatverlauf nicht.
3. Welche Werkzeuge braucht der Agent wirklich? Jedes Werkzeug ist Angriffsfläche und Pflegeaufwand. Wir starten mit dem kleinsten Set und ergänzen erst, wenn eine Aufgabe nachweislich daran scheitert.
4. Wer darf was freigeben? Schreibende Aktionen auf Systemen wie ERP, E-Mail oder Buchhaltung brauchen eine feste Freigaberegel. Sie gehört in den Harness, nicht in den Prompt.
5. Wie wird es im Betrieb gemessen? Fehlerquote, Nacharbeit und Kosten je erledigter Aufgabe, nicht je Anfrage. Erst diese Zahlen zeigen, ob der Agent Arbeit abnimmt oder nur verlagert.

Unsere Erfahrung ist eindeutig: Die ersten zwei Fragen entscheiden über den Erfolg. Wer sie offen lässt, landet trotz gutem Modell bei einem Agenten, dem niemand die Arbeit überlässt.

Harness, Loop und Graph: wie es zusammenhängt

Harness Engineering ist die Grundlage, auf der die nächsten Begriffe aufsetzen. Loop Engineering fragt, was einen Agenten weckt, wenn niemand promptet: ein Zeitplan, ein Ereignis, ein Ziel. Wie das mit Claude Code praktisch aussieht, beschreibt unser Artikel zu Loop Engineering. Graph Engineering zerlegt Aufgaben in Knoten, Kanten und Zustand, also in das, was Unternehmen seit Jahrzehnten Prozess nennen.

Alle drei scheitern an derselben Stelle, wenn der Harness fehlt: ohne lesbaren Zustand vergessen Loops ihre Ergebnisse, ohne Prüfung liefern Graphen nur eine Reihenfolge ohne Beweis.

Häufig gestellte Fragen

Was ist Harness Engineering?

Harness Engineering ist die Gestaltung des Systems um ein Sprachmodell: Umgebung, Werkzeuge, Zustand zwischen Sitzungen und die Prüfung von Ergebnissen. Es sorgt dafür, dass Agenten über mehrere Kontextfenster hinweg den Stand kennen und Aufgaben nicht zu früh für erledigt erklären.

Was ist der Unterschied zwischen Context Engineering und Harness Engineering?

Context Engineering optimiert, was in ein einzelnes Kontextfenster gehört. Harness Engineering optimiert, wie viele Fenster, Sitzungen und Agenten zusammenarbeiten: Fortschrittsdateien, Feature-Listen, Werkzeuge und Prüfstrecken. Das eine ist Teil des anderen.

Brauche ich für Claude Code einen eigenen Harness?

Für Programmieraufgaben meist nicht, Claude Code ist selbst ein ausgereifter Harness. Ein eigener lohnt sich, wenn Ihre Aufgabe weit von dem entfernt ist, worauf Modelle trainiert sind, etwa bei Fachprozessen mit eigenen Regeln, Freigaben und Nachweispflichten.

Welche Rolle spielt Loop Engineering?

Loop Engineering baut auf dem Harness auf. Es legt fest, was einen Agenten ohne menschlichen Prompt startet, etwa ein Zeitplan oder ein Ereignis, und wie Ergebnisse für den nächsten Lauf abgelegt werden. Ohne lesbaren Zustand im Harness vergessen Loops, was sie gefunden haben.

Was kostet ein eigener Agent Harness?

Das hängt an Domäne, Prüfstrecken und Betrieb, deshalb nennen wir keinen Pauschalpreis. Der Einstieg ist ein kurzes Gespräch, danach steht ein Festpreis für den vereinbarten Umfang, wenn Anwendungsfall, Abnahmekriterien und Betrieb feststehen.

Nächster Schritt

Verwandte Themen