Warum Produktions-KI-Agenten leise versagen und wie man falsche Antworten erkennen kann

Der gefährlichste Produktionsfehler für einen KI-Agenten ist weder ein Absturz noch eine Zeitüberschreitung. Es handelt sich vielmehr um eine Antwort, die richtig aussieht, alle Gesundheitsprüfungen besteht und dennoch falsch ist. Die folgende Fallstudie beschreibt ein kleines Softwareunternehmen, das innerhalb eines Quartals zwölf Agenten in die Produktion schickte und nur drei davon beibehielt. Sie erklärt, was die Überlebenden von den anderen unterschied, damit Sie vor dem Einsatz eine Erkennungsmethode entwickeln können.

Das Team, die Tools und die Grundregeln

Es handelte sich um ein B2B-SaaS-Unternehmen mit etwa vierzig Mitarbeitern, darunter neun Ingenieuren – kein Forschungslabor. Zwischen dem 6. Januar und dem 27. März 2026 startete das Team zwölf Agenten. Diejenigen, die im Code-Repository liefen, wurden mit Claude Code betrieben; die anderen waren maßgeschneiderte Agenten, die auf der Anthropic-API basierten und hinter einem kleinen internen Service gehostet wurden, sodass jeder Agent ein gemeinsames Audit-Log sowie einen einzigen Abschaltmechanismus hatte.

Zwei Regeln wurden bereits vom ersten Tag an angewandt, und beide erwiesen sich als sinnvoll:

• Jeder Agent protokolliert jede Aktion in einem Prüfkanal, einschließlich nur-Lese-Aktionen.
• Jeder im Team kann jederzeit einen Agenten ausschalten, ohne Genehmigung und ohne Ticket.

Erfolg wurde auf absichtlich anspruchsvolle Weise definiert. Ein Agent galt nur dann als erfolgreich, wenn er nach dreißig Tagen noch lief und jemand gegen seinen Ausschaltvorschlag protestierte. Nutzungsmetriken können leicht durch Neuheit überhöht werden; Menschen, die ein Tool verteidigen, auf das sie angewiesen sind, lassen sich deutlich schwerer fälschen.

Leistungsübersicht: drei Überlebende, neun Abschaltungen

Am Ende des Quartals liefen noch drei Agenten:

• ein Autor von Pull-Request-Beschreibungen
• ein Assistent für die Erstellung von Unterstützungstickets zur Priorisierung
• ein Sammler von Informationen zum Vorfallkontext

Nine wurden innerhalb eines Monats deaktiviert: ein automatischer Code-Prüfer, ein Antworter auf Analysefragen, ein Bot zur Aktualisierung von Abhängigkeiten, ein Quarantäne-Tool für unzuverlässige Tests, ein Antworter auf E-Mails von Kunden, ein Konverter von Meeting-Notizen in Tickets, ein Aktualisierer der Wiki-Dokumentation, ein Antworter auf Protokollanomalien und ein Veröffentlichungs-Tool für Changelogs.

Der Hilfshinweis, der nicht half

Wie die meisten Teams begann auch dieses Team mit einem Hilfshinweis, der in den Systemhinweis jedes Agenten eingefügt wurde und das Modell aufforderte, Unsicherheiten einzugestehen, unüberprüfbare Werte zu vermeiden und für jede Zahl eine Quelle anzugeben:

If you are not confident in an answer, say "I don't know" and stop.
Never state a value you cannot verify from the tools available to you.
Cite the source of every number you report.

In der Praxis hatte diese Anweisung fast keinen Effekt, und der Grund dafür ist die wichtigste Lektion dieser ganzen Übung. Dies wird im unten stehenden Analysefehler ausführlich erläutert.

Auch die Berechtigungen wurden zunächst zurückhaltend gewährt: Jeder Agent hatte bei der Einführung nur Lesezugriff. Im Laufe des Quartals erhielten vier Agenten Schreibzugriff. Drei von diesen vier wurden später deaktiviert.

Was die überlebenden Agenten gemeinsam hatten

Der Autor von Pull-Request-Beschreibungen

Auf Claude Code laufend konnte dieser Agent den Diff sowie das zugehörige Issue lesen und anschließend eine Beschreibung in den Körper des Pull-Requests einfügen. Ein Ingenieur überarbeitete diese und führte den Merge durch. Der Agent bearbeitete etwa 35 Pull-Requests pro Woche, und die Beschreibungen waren in der Regel besser als die, die die Ingenieure von Hand schrieben – hauptsächlich weil ein müder Entwickler am Ende des Tages tendenziell „Bug beheben“ schreibt, während der Agent nicht müde wird.

Der Entwerfer für die Support-Triage

Dieser Agent las jedes eingehende Ticket, wies es mit einem Label aus und erstellte eine Antwort als interne Notiz im Helpdesk. Er hatte niemals die Möglichkeit, etwas zu senden. Etwa 60 Prozent seiner Entwürfe wurden nach geringfügiger Bearbeitung versandt, und die mittlere Zeit bis zur ersten Reaktion verringerte sich von etwas über vier Stunden auf etwa achtzig Minuten.

Der Incident-Kontext-Sammler

Jedes Mal, wenn eine Benachrichtigung jemanden alarmierte, postete dieser Agent genau eine Nachricht im Incident-Kanal, die die drei neuesten Bereitstellungen mit Zeitstempeln, die Änderung der Fehlerrate pro Service sowie Links zu ähnlichen Vorfällen aus den vorangegangenen neunzig Tagen enthielt. Er unternahm keine Maßnahmen und bot keine Diagnose an; er sammelte lediglich die Dashboards und Links, die ein auf Abruf bereiter Ingenieur sonst manuell öffnen würde. Es handelte sich um den am wenigsten ausgefeilten Agenten, den das Team je entwickelt hatte – und zugleich um denjenigen, den das Team am meisten schätzte.

Anatomie eines selbstsicher falschen Agenten

Ursprünglich war der Analytics-Agent das am besten konzipierte von insgesamt zwölf. Er hatte Zugriff auf eine Lesereplik, ein handschriftliches Schema-Dokument in seinem Kontext sowie eine Slack-Schnittstelle; seine Aufgabe bestand darin, Fragen zu Metriken zu beantworten, damit das Daten-Team nicht zwanzigmal am Tag gestört wurde.

Am 3. Februar bat jemand ihn um die wöchentlichen Einnahmen. Er erstellte eine Abfrage, die Bestellungen mit Zahlungen verknüpfte, und behandelte dabei Rückerstattungszeilen als positive Beträge. Das Ergebnis lag etwa 12 Prozent zu hoch, war aber dennoch vollkommen glaubwürdig: Der Betrag war korrekt, die wöchentliche Entwicklung stimmte, und sogar der saisonale Rückgang nach dem Ende einer Januar-Aktion war erkennbar.

Die überhöhte Zahl erschien im Bericht vom Montag sowie in den beiden folgenden Montagsberichten. Der Fehler trat erst am 24. Februar während der Abrechnung für Januar zutage, als die Gesamtsummen des Finanzteams und des Agenten nicht übereinstimmten.

Betrachten Sie, was in diesen drei Wochen nicht geschah: Es gab keine Ausnahmen, keine Warnungen und keinen Anstieg der Verzögerung. Die SQL-Anfragen waren gültig, die Datensätze wurden zurückgegeben, und der Agent zitierte seine Quelle genau so, wie es von ihm verlangt wurde. Herkömmliche Überwachungssysteme dienen dazu, Systeme zu erkennen, die aufhören zu funktionieren – dieses System hingegen hat niemals aufgehört zu arbeiten.

D genau hier versagt die Guardrail-Anweisung. Eine Anweisung, bei Unsicherheit „Ich weiß es nicht“ zu sagen, funktioniert nur, wenn das Modell ein internes Signal für seine eigene Unsicherheit hat. Hier war das Modell nicht unsicher – es lag einfach falsch. Von außen ist ein selbstbewusster Fehler nicht von der Richtigkeit zu unterscheiden, weshalb eine Anweisung dies nicht filtern kann.

Daraus folgt ein nützlicher allgemeiner Punkt: Eine Verknüpfung, die stumm das Zeichen oder die Anzahl der Zeilen ändert, ist ein klassischer Analysefehler – auch für Menschen. Der Unterschied besteht darin, dass ein menschlicher Analyst in der Regel eine Vorstellung davon hat, welche Zahlen von der Finanzabteilung überprüft werden, während ein Agent kein Interesse an der Abstimmung hat, es sei denn, man schafft eines für ihn.

Wenn ein korrekter Agent ignoriert wird

Der automatische Code-Reviewer versagte auf eine Weise, die viele Teams nicht erwartet hatten: Er lag nicht falsch. Jeder Pull Request erhielt etwa 40 Kommentare davon; die meisten waren gerechtfertigt, und viele handelten von Kleinigkeiten wie der Benennung oder dem Stil der Fehlerbehandlung.

Bereits nach drei Wochen behoben die Ingenieure die Kommentare, ohne sie zu lesen. Dann stellte der Reviewer ein wirklich ernstes Problem dar – eine Anfrage ohne den entsprechenden Tenant-Filter – und dieser Kommentar geriet unter 38 Stilbemerkungen. Zwei Tage später fand jemand den Fehler in der Staging-Umgebung. Der Reviewer hatte recht, doch das übermäßige Volumen übertönte seine Signale.

Warum die neun Systeme abgeschaltet wurden

Die Ausfälle ließen sich klar einteilen:

• sechs lieferten zuversichtliche, aber falsche Ergebnisse
• Zwei lieferten Ergebnisse, die niemand las
• Eines wurde abgeschaltet, weil man nicht erkennen konnte, ob es überhaupt etwas tat

Die Gestaltungsregel: Einen Schritt vor dem Handeln des Menschen stoppen

Die drei verbleibenden Agenten teilen eine Eigenschaft – es ist weder das Modell noch die Anweisung oder der Rahmen. Jeder von ihnen hält sich einen Schritt vor einer menschlichen Handlung zurück. Sie erzeugen einen Entwurf, eine Zusammenfassung oder einen Satz an Kontextinformationen, und ein Mensch führt den letzten Schritt aus. Dieser letzte Schritt zwingt die Person dazu, das Ergebnis zu lesen.

Jeder Agent, der abgeschaltet wurde, handelte entweder eigenständig oder erzeugte Ausgaben, die ohne echte Überprüfung zu einer Handlung führten. Der Analyseagent ist ein typisches Beispiel: Er hatte überhaupt keinen Schreibzugriff, doch seine Ergebnisse flossen direkt in Geschäftsentscheidungen ein, weil Menschen ihm vertrauten.

Die daraus resultierende Grenze ist einfach: Lassen Sie Agenten Material sammeln; erlauben Sie ihnen jedoch nicht, den letzten Schritt zu übernehmen, bei dem ein Fehler zu ernsthaften Konsequenzen führen kann.

Diese Grenze ist kein Urteil über die Fähigkeiten des Modells, und ein leistungsstärkeres Modell wird sie nicht beseitigen. Es geht um die Erkennung. Ein typischer Fehler eines Agenten besteht darin, eine plausibel klingende, aber falsche Antwort zu liefern, anstatt abzustürzen – und die meisten Teams verfügen über nur sehr begrenzte Werkzeuge, um solche falschen Antworten aufzudecken.

Kosten waren niemals das Engpassproblem. Alle zwölf Agenten zusammen verbrauchten im Quartal etwas weniger als 900 Dollar an Tokens. Die knappe Ressource war die menschliche Aufmerksamkeit.

Drei Änderungen, die Sie diese Woche vornehmen können

• Vor der Veröffentlichung dokumentieren Sie, wie eine mit Sicherheit falsche Antwort erkannt werden kann. Es geht nicht darum, wie man einen Absturz bemerkt, sondern wie man feststellt, dass die Ausgabe falsch ist. Wenn Sie diesen Satz nicht formulieren können, sollte der Agent nur Entwürfe erstellen und nicht direkt handeln.

Stellen Sie regelmäßig sicher, dass jede von einem Agenten erzeugte Zahl mit einer zweiten Quelle abgeglichen wird. Ein wöchentlicher automatisierter Vergleich mit den Finanzdaten hätte den Einnahmefehler bereits am zweiten Tag aufgedeckt, und seine Erstellung hätte nur einen Nachmittag in Anspruch genommen.

Liefern Sie die Ergebnisse der Agenten an Orte, an denen die Nutzer bereits nachschauen, und begrenzen Sie deren Menge. Ein völlig neuer Kanal wird in der Regel ignoriert, während eine Wand aus vierzig Kommentaren nur überflogen wird – lediglich wenige gezielte Kommentare erhalten tatsächlich Aufmerksamkeit.

Die Zahl gegen eine zweite Quelle prüfen

Vergleichen Sie die Zahl des Agenten mit dem Hauptbuch und brechen Sie ab, wenn die Lücke größer als ein halbes Prozent oder eine Währungseinheit ist.

const reconcile = (agentRevenue: number, ledgerRevenue: number) => {
  const delta = Math.abs(agentRevenue - ledgerRevenue);
  const tolerance = Math.max(1, Math.abs(ledgerRevenue) * 0.005);
  return { ok: delta <= tolerance, delta };
};

Lassen Sie den Vergleich nach Zeitplan laufen. Der Absturz-Monitor bleibt grün; diese Prüfung ruft einen Menschen.

Kernpunkte

• Der zu berücksichtigende Fehlermodus ist ein plausibel erscheinendes Falschergebnis, nicht Ausfallzeiten; herkömmliche Überwachungsmethoden erkennen dies nicht.
• Anweisungen zur Angabe der Zuverlässigkeit können Fehler nicht aufdecken, von denen das Modell nichts weiß.
• Lesezugriff bedeutet nicht unbedingt Harmlosigkeit: Ergebnisse, die Entscheidungen beeinflussen, stellen im Grunde eine Handlung dar.
• Das Volumen ist an sich eine Fehlerart; ein korrektes Signal, das im Rauschen untergeht, ist wertlos.
• Ein nützlicher Test für jeden Agenten ist, ob jemand Einwände hätte, wenn er morgen ausgeschaltet würde.