Warum KI-Agenten in der Praxis scheitern: Oft ist das Harness wichtiger als das Modell

Der erste Reflex ist fast immer derselbe: Das Modell war nicht gut genug. Der Agent hat eine Datei übersehen, den falschen Absatz geändert, im Browser die falsche Seite geöffnet oder eine Zusammenfassung geliefert, die gut klang, aber niemand verantworten wollte. Danach wird über ein besseres Modell, einen besseren Prompt oder ein längeres Kontextfenster gesprochen.

Manchmal stimmt das. In der täglichen Arbeit sehe ich aber häufiger ein anderes Muster. Das Modell wurde in einen unaufgeräumten Auftrag gesetzt, ohne brauchbare Arbeitsumgebung darum herum.

Diese Umgebung wird inzwischen oft Harness genannt. Ich mag keine Modebegriffe um ihrer selbst willen. Hier hilft das Wort aber, weil es den Teil benennt, der im Betrieb entscheidet: Kontextpaket, Tool-Zugriff, Rechte, Checks, Logs, Übergabe an Menschen und der Weg zurück, wenn etwas blockiert.

Wenn dieses Harness schwach ist, verhält sich auch ein starkes Modell wie ein sehr kluger neuer Kollege, der einen Laptop bekommt, aber keine Einarbeitung und keine klaren Befugnisse. Einmal kann das gut gehen. Verlässlich ist es nicht.

Das Fehlermuster, das ich festnageln wollte

Ich habe das nicht als Funktionsrundgang geschrieben, sondern als Arbeitsprüfung. KI-Agenten scheitern im Alltag selten nur am Modell. Entscheidend sind Kontext, Rechte, Nachweise, Review-Punkte und ein sauberer Weg zurück. Entscheidend war nicht, welche KI am klügsten klingt, sondern ob das Ergebnis ohne stille Nacharbeit weitergegeben werden kann.

Der Agentenablauf als Prüfstand

Der Arbeitsfall war bewusst konkret: Ein Modellwahl-Memo zu dieser konkreten Frage: KI-Agenten scheitern im Alltag selten nur am Modell. Entscheidend sind Kontext, Rechte, Nachweise, Review-Punkte und ein sauberer Weg zurück. Ich habe den Ablauf wie in einem Betrieb betrachtet: Was kommt hinein, was bearbeitet die KI, wer prüft, und wohin muss das Ergebnis danach. OpenAI Codex, ChatGPT, Claude, LangChain, Databricks und KI-Agenten sind nur dann stark, wenn sie diesen Weg verkürzen, ohne die Prüfung schwerer zu machen.

Welche Teile des Harness ich geprüft habe

Prüfpunk	Worauf ich geachtet habe	Warnsignal
Eingangsmaterial	Ob die Quelle klar genug für die KI ist	Das Tool ergänzt fehlenden Kontext durch Raten
Menschliche Prüfung	Ob Freigabe, Korrektur oder Ablehnung schnell möglich sind	Die prüfende Person liest wieder von vorn
Übergabe	Ob das Ergebnis in Dokument, Tabelle, Ticket oder Workflow passt	Die nächste Person formatiert oder deutet alles neu
Wiederholbarkeit	Ob derselbe Ablauf mit anderem Material hält	Der erste Lauf wirkt gut, der zweite driftet

Notizen, die Demo von Betrieb trennten

Beleg	Was ich geprüft habe	Warum es wichtig war
Eingangspaket	Aufgabenbrief, Quelle oder Tabelle und erwartete Übergabeform	Ohne Eingangsform sagt ein Modellvergleich wenig über Arbeit aus
Ausgabeprüfung	Ob das Ergebnis ohne Neubau in Dokument, Tabelle, Ticket oder Anweisung passt	Hier versteckt sich die meiste Nacharbeit
Fehllauf	Das Ergebnis sauber wirkte, die nächste Person aber Tabelle, Quellen und Übergabetext neu bauen musste.	Der misslungene Fall zeigt die Grenze schneller

Wo eine gute Antwort trotzdem steckenblieb

Die Schwachstelle war nicht die erste Antwort. Sie lag in der Übergabe danach. In diesem Thema zeigte sich der typische Bruch so: Das Ergebnis sauber wirkte, die nächste Person aber Tabelle, Quellen und Übergabetext neu bauen musste. Deshalb ist ein sauber klingender Entwurf für mich nur ein Anfang, kein Betriebsnachweis.

Was ich vor mehr Zugriff verlangen würde

Ich würde zuerst Ausgaben von OpenAI Codex, ChatGPT, Claude, LangChain, Databricks und KI-Agenten, eine Vergleichstabelle und ein übergabefähiges Memo sichern und dann entscheiden, ob Tool oder Workflow die Prüfung überstehen. Wenn das Ergebnis nicht in wenigen Minuten kontrollierbar ist, würde ich den Automatisierungsumfang enger schneiden, bevor ich ein anderes Modell oder eine weitere Integration einführe.

Prüfpunkte vor mehr Agentenrechten

Schreibe genau auf, welches Eingangsmaterial die KI bekommt.
Benenne die Person, die freigibt oder ablehnt.
Lege fest, wohin das Ergebnis als Nächstes geht.
Hebe einen misslungenen Lauf auf, nicht nur das saubere Beispiel.
Miss eingesparte Prüfzeit, nicht nur Generierungsgeschwindigkeit.
Stoppe den Ablauf, wenn die nächste Person das Ergebnis ständig neu baut.

Quellen, die ich geprüft habe

Bei veränderlichen Aussagen habe ich offizielle Dokumentation, Produktseiten und Quellenhinweise zu veränderlichen Aussagen herangezogen. Preise, Modellzugang und Plattformfunktionen ändern sich schnell. Darum trenne ich Beleg und Einschätzung bewusst.

Kurzfassung für die Betriebsrunde

Ein KI-Agent ist nicht nur ein Modell mit Werkzeugen. Es ist ein Modell, das in einer Arbeitsumgebung handelt.

Schicht	Was sie steuert	Fehlsignal
Arbeitspaket	Ziel, Dateien, Umfang, aktueller Zustand	Der Agent fragt jedes Mal nach denselben Grundlagen
Tool-Grenze	Browser, Terminal, Dokumente, APIs, Speicher	Er kann zu wenig lesen oder zu viel ändern
Rechte-Modell	Lesen, Entwerfen, Ändern, Löschen, Senden, Veröffentlichen	Eine hilfreiche Aktion wird zum Geschäftsrisiko
Prüfpfad	Tests, Lint, Diff, Screenshots, Quellen, Review-Notizen	Das Ergebnis wirkt gut, lässt sich aber nicht belegen
Recovery-Pfad	Wiederholung, Rollback, zuständige Person, Blocker-Status	Eine unerwartete Seite oder API-Antwort stoppt alles
Gedächtnis	gespeicherte Regeln, Playbooks, wiederkehrende Fehler	Am nächsten Morgen beginnt alles wieder bei null

Das Modell zählt. Natürlich. Aber es ist nur ein Teil des Systems. Ist das Harness dünn, erzeugt jeder Agentenlauf neue Aufsichtsarbeit für Menschen.

Was Harness ohne Fachsprache bedeutet

Bei einem Coding-Agenten ist das Harness nicht nur die IDE. Es umfasst Repository-Zustand, Branch-Regeln, Testbefehle, Paketmanager, lokale Dienste, Umgang mit Secrets, Deployment-Skripte, Review-Gewohnheiten und die Definition von fertig.

Bei einem Browser-Agenten gehören Login-Zustand, erlaubte Domains, Quellenpriorität, Screenshot-Nachweise, Download-Regeln und der Umgang mit blockierten Seiten dazu.

Bei Dokumentenarbeit gehören Quelldateien, Namensregeln, Vorlagen, Tabellenformate, Review-Kommentare, Versionshistorie und die Grenze zwischen Umschreiben und Markieren dazu.

Bei Support- oder Sales-Abläufen gehören Kundendaten-Grenzen, CRM-Felder, Eskalationsregeln, Tonalität, Freigabepunkte und die Frage dazu, ob der Agent senden darf oder nur entwirft.

Darum vertraue ich einem einzelnen sauberen Testprompt nicht besonders. Er zeigt, dass das Modell eine Aufgabe lösen kann. Er zeigt nicht, ob der Ablauf nächste Woche noch hält, wenn der Dateiname anders ist, ein Login abläuft, ein Kunde unklar schreibt oder ein Reviewer fragt, was genau geändert wurde.

Wo die Arbeit zuerst bricht

Die Fehler sind selten dramatisch. Genau deshalb werden sie unterschätzt.

Ein Agent fasst ein Produktdokument gut zusammen, weiß aber nicht, dass der juristische Abschnitt nicht umgeschrieben werden darf. Ein anderer Agent liest eine Tabelle, versteht aber nicht, dass eine leere Zelle “noch nicht freigegeben” bedeutet und nicht null. Ein Coding-Agent repariert einen Test, übersieht aber das interne Skript, das die Datei beim Deployment neu erzeugt. Ein Browser-Agent sammelt Quellen, trennt aber offizielle Dokumentation nicht von einem kopierten Blogpost.

Das Modell ist deshalb nicht wertlos. Das Arbeitspaket war unvollständig.

Ich würde solche Fälle nicht zuerst als Prompt-Problem behandeln. Ich würde sie als Harness-Problem markieren.

Was passiert ist	Was ich vor einem Modellwechsel ändern würde
Der Agent hat die falsche Datei bearbeitet	Allow-List und Diff vor jeder Änderung einführen
Die Antwort hatte keine Belege	Quellen, Screenshots oder Befehlsausgabe vor Abschluss verlangen
Die gleiche Ausnahme wiederholt sich	Ausnahme als Regel ins Playbook schreiben
Review-Zeit sinkt nicht	Entwurf, Prüfung und finale Aktion trennen
Niemand weiß, was geändert wurde	Änderungslog mit Dateien, Quellen und Restrisiko erzwingen
Der Agent verlangt mitten im Lauf mehr Zugriff	Erlaubte Tools und blockierte Aktionen vorher festlegen

Das klingt schlicht. Im Betrieb trennt genau das eine spannende Vorführung von Arbeit, die ich näher an echte Systeme lassen würde.

Beispiel aus der Entwicklung

Nehmen wir einen Coding-Agenten wie Codex. Beeindruckend ist nicht, dass er Code schreiben kann. Das können viele Modelle. Die eigentliche Frage lautet, ob er im vorhandenen Projekt arbeiten kann, ohne dem Entwickler eine zweite Kontrollarbeit aufzubürden.

Ein brauchbares Harness für ein Repository enthält etwa:

den aktuellen Branch und ob ein neuer Branch erlaubt ist;
die Dateien, die das Laufzeitverhalten wirklich bestimmen;
den genauen Testbefehl und den Befehl, der für normale Läufe zu langsam ist;
den Build-Befehl, der funktioniert, während die Anwendung läuft;
den Deployment-Pfad und den Nachweis nach dem Deployment;
die Regel, dass Kundendaten, Secrets und fremde Änderungen nicht angefasst werden.

Ohne dieses Paket wirkt der Agent trotzdem produktiv. Er liest Code, erstellt einen Patch und erklärt sich. Danach muss der Entwickler aber prüfen, ob der richtige Test lief, ob eine falsche Grenze berührt wurde, ob eine unausgesprochene Konvention gebrochen ist oder ob ein Deployment-Schritt fehlt.

Das ist keine Automatisierung. Das ist unterstütztes Raten mit zusätzlicher Prüfschleife.

Mit Harness wird derselbe Agent nützlicher. Er weiß, wo er beginnt, wie er das Ergebnis belegt, wann er stoppt und welche Übergabe ein Mensch wirklich prüfen kann.

Beispiel aus Dokumentenarbeit

Dasselbe gilt außerhalb von Code. Stellen wir uns ein Vendor-Memo vor: drei PDFs, eine Tabelle und Notizen aus zwei Gesprächen.

Die schwache Anfrage lautet: “Lies das und erstelle einen Vergleich.”

Das bessere Harness sieht so aus:

Die Vendor-Liste kommt aus der Tabelle, nicht aus den PDFs.
Preise stammen nur aus dem neuesten datierten Dokument.
Fehlende Informationen werden als nicht bestätigt markiert.
Sicherheitsbedenken kommen in einen eigenen Abschnitt, nicht in die Punktzahl.
Jede Aussage mit Einfluss auf die Empfehlung bekommt eine Quellen-Notiz.
Der Agent entwirft das Memo, ändert aber die finale Empfehlung nicht ohne Review.

Das ist unspektakulär. Genau so entsteht Vertrauen. Wenn der Agent bestätigte Fakten und Gesprächsnotizen nicht trennt und die Empfehlung nicht belegen kann, würde ich ihm die Entscheidung nicht überlassen.

Praxisurteil aus dem Betrieb

Bevor ich einem Agenten mehr Reichweite gebe, prüfe ich vier Punkte.

Erstens: Kennt der Agent die Form der Arbeit, bevor er startet? Wenn ein Mensch jedes Mal Ordnerstruktur, Quellenreihenfolge und Ausgabeformat neu erklären muss, ist das Harness nicht reif.

Zweitens: Hinterlässt er Nachweise, ohne dass man darum bittet? Ich will Diffs, Quellen, Befehlsausgaben, Screenshots oder eine Review-freundliche Änderungsliste. Ein selbstbewusster Absatz ist kein Nachweis.

Drittens: Ist die Rechte-Grenze langweilig klar? Nur lesen darf breiter sein. Entwürfe dürfen etwas offener sein. Senden, Löschen, Veröffentlichen, Bezahlen oder Kundendaten ändern sollte eng bleiben, bis die Prüfungen zuverlässig langweilig sind.

Viertens: Macht ein fehlgeschlagener Lauf den nächsten besser? Wenn der Blocker nur mit “noch einmal versuchen” endet, lernt das System nichts. Wird die Ausnahme zu einer Regel, einer Checkliste oder einer gespeicherten Fähigkeit, reift das Harness.

Die bessere Metrik

Die Frage “Ist der Agent gut?” ist zu grob.

Ich schaue auf den Review-Aufwand. Wie viele Minuten brauchte ein Mensch zur Prüfung? Wie viele Fakten mussten repariert werden? Wie oft stoppte der Lauf wegen fehlender Eingaben? Wie oft wurde die finale Aktion abgelehnt? Wie viele Schritte wurden von Hand neu gemacht?

Wenn der Agent einen schöneren Entwurf schreibt, die Review-Zeit aber gleich bleibt, hat das Harness noch keinen Wert geliefert. Wenn der Entwurf weniger glänzt, aber Nacharbeit sinkt und die Übergabe klarer ist, würde ich dieses Ergebnis wählen.

Frage	Gutes Zeichen	Schlechtes Zeichen
Kennt der Agent den Zustand?	Er nennt richtige Dateien, Daten und Verantwortliche	Er fragt nach Dingen, die im System stehen
Nutzt er Tools sicher?	Er liest breit und schreibt eng	Er editiert vor dem Plan
Gibt es Nachweise?	Reviewer können den Weg prüfen	Menschen müssen die Arbeit nachbauen
Verbessert ein Fehler den Ablauf?	Die Ausnahme wird zur Regel	Der nächste Lauf scheitert gleich
Sinkt die menschliche Last?	Review-Zeit fällt	Das Ergebnis ist poliert, aber riskant

Nicht mit Agentenauswahl anfangen

Ich würde nicht mit “Welchen Agenten kaufen wir?” starten. Ich würde einen wiederkehrenden Ablauf wählen, bei dem der Schmerz sichtbar ist.

Gute Kandidaten haben einen klaren Input, einen wiederholbaren Output, einen bekannten Reviewer und eine messbare Übergabe. Schlechte Kandidaten hängen an stiller Politik, vager Beurteilung oder Ausführungsrechten ohne Review-Gewohnheit.

“Erstelle den ersten Entwurf des wöchentlichen Vendor-Risk-Memos mit Quellen” ist ein guter Anfang. “Kümmere dich um Vendor Risk” ist zu groß. Das erste hat ein Harness. Das zweite ist Wunschdenken.

Darum enttäuschen Prompt-Sammlungen oft. Ein Prompt verbessert einen Moment. Ein Harness verbessert den Weg vor und nach diesem Moment.

Abbruchkriterien vor dem Ausbau

Ich würde Stoppregeln notieren, bevor der Agent überzeugend wirkt.

Stoppen, wenn der Agent die Quelle einer Empfehlung nicht nennen kann.
Stoppen, wenn ein Mensch jede Zeile neu prüfen muss.
Stoppen, wenn für Routinearbeit ständig mehr Rechte nötig sind.
Stoppen, wenn externe oder produktionsnahe Inhalte vor Review geändert werden.
Stoppen, wenn dieselbe Ausnahme dreimal auftaucht.
Stoppen, wenn der Verantwortliche nicht erklären kann, was der Agent getan hat.

Das wirkt vorsichtig. Es ist billiger, als einen selbstbewussten Fehler nach Zugriff auf echte Systeme aufzuräumen.

Was ich zuerst bauen würde

Vor dem Modellwechsel würde ich ein kleines Harness-Dokument bauen. Eine Seite reicht.

Welche Arbeit geht an den Agenten?
Was darf der Agent lesen?
Was darf der Agent ändern?
Welche Nachweise muss er hinterlassen?
Wer prüft das Ergebnis?
Was passiert bei einem Blocker?
Welcher wiederholte Fehler wird zur neuen Regel?

Dann würde ich denselben Ablauf fünfmal laufen lassen und Review-Zeit vergleichen. Wenn der fünfte Lauf dieselbe menschliche Erklärung braucht wie der erste, ist das Problem nicht gelöst.

Häufige Fragen

Gilt Harness Engineering nur für Coding-Agenten?

Nein. Coding-Agenten machen das Problem sichtbar, weil Repositories, Tests und Diffs konkret sind. Das Muster gilt genauso für Dokumente, Browser-Recherche, Support, Sales Operations und internes Reporting.

Macht ein besseres Modell das Harness überflüssig?

Nein. Es reduziert einzelne Fehler. Das Betriebsproblem bleibt. Ein besseres Modell braucht weiterhin richtigen Kontext, sichere Tools, Nachweise und Review.

Sollte jeder Ablauf zu einem Agentenablauf werden?

Nein. Seltene, politisch sensible oder stark urteilsabhängige Arbeit kann mit Checkliste und guter Verantwortlichkeit besser laufen. Agenten verdienen ihren Platz, wenn Wiederholung, Nachweis und Übergabe klar sind.

Woran merkt man, dass das Harness funktioniert?

Der Agent wird weniger dramatisch. Er fragt weniger Grundlagen, hinterlässt bessere Nachweise, stoppt sicher bei Blockern und macht den Review kleiner statt lauter.

Letztes Urteil

Die nächste brauchbare Welle von KI-Agenten wird nicht nur durch größere Modelle entstehen. Sie wird von Teams getragen, die Arbeit sauber verpacken, Tools begrenzen, Ergebnisse belegen und wiederkehrende Fehler in Regeln verwandeln.

Darum zählt Harness Engineering. Es ist keine Dekoration um das Modell. Es trennt einen beeindruckenden Einzellauf von einem Ablauf, dem man am nächsten Tag wieder Arbeit anvertrauen kann.

Workflow-Pfad

Wo dieser Guide einzuordnen ist

Dieser Abschnitt verbindet den aktuellen Guide mit dem größeren Workflow, den er unterstützt.

Tool-Stack-Entscheidungen Den Stack wählen, der zur operativen Reife des Teams passt.

Ein Pfad zum Vergleich von Automationsplattformen, App-Buildern, Agent-Buildern, Buchhaltungstools und KI-Assistenten.

Workflow-Pfad öffnen

Passt gut für: Teams zwischen einfachem Toolkauf, internem Workflow-Aufbau und breiter Plattformentscheidung
Weniger passend, wenn: Du brauchst konkrete Setup-Schritte stärker als einen Entscheidungsrahmen.

Geprüfte öffentliche Quellen

Öffentliche Seiten, die für gemeldete Fakten, offizielle Dokumentation, politischen Kontext, Produktinformationen und veränderliche Aussagen geprüft wurden.