Am 16. August fror mein Betriebsagent – der, der die Server überwacht und Updates einspielt – im Laufe des Tages sechsmal ein. Jedes Mal meldete er dasselbe: Seine Werkzeuge reagierten nicht mehr, nicht einmal auf einen trivialen Befehl.

Es lag nicht an seinen Werkzeugen. Er kam nie an den Punkt, sie aufzurufen.

Ein Fehler, der sich identisch wiederholt

Eine alte Nachricht in seinem Gesprächsverlauf enthielt einen beschädigten Block, den die API des Modells zurückwies. Da jede Anfrage den gesamten Verlauf erneut abspielte, war der Fehler deterministisch: drei automatische Wiederholungen, drei Ablehnungen, dann ein Durchlauf ohne sichtbare Ausgabe. Auf dem Telefon sah das aus wie ein Einfrieren; technisch war es eine reproduzierbare Ablehnung.

Ein Fehler, der sich identisch wiederholt, sieht nach Instabilität aus, wenn man nur seine Folgen sieht. Der Unterschied hängt an einer einzigen Frage: Scheitert es immer an derselben Stelle?

Das unsichtbare Ausmaß

  • 80 fehlgeschlagene Aufrufe an einem Tag, verteilt auf 20 einzelne Ausführungen;
  • ein regelmäßiger Takt, alle dreißig Minuten;
  • ein interner Auslöser: eine Routineprüfung des Agenten.

Und diese Routineprüfung kontrollierte … Dateipfade auf einem alten Server, der elf Tage zuvor bei einer Migration abgeschaltet worden war. Die Anweisungsdatei trug in der ersten Zeile selbst einen Hinweis: „auf dem alten Server geschrieben, vor Verwendung erneut prüfen“. Niemand hat ihn gelesen, weil er in keinem Bericht auftauchte.

Elf Tage lang hat der Agent also alle dreißig Minuten gewissenhaft eine tote Maschine geprüft. Und jede Prüfung wurde abgerechnet, weil sie den gesamten Gesprächsverlauf erneut abspielte: fast 2 MB Kontext bei jedem Durchlauf.

Die Korrektur, an allen drei Ursachen

  1. Die unnötige Arbeit: Die veralteten Anweisungen wurden entfernt.
  2. Die Kosten: Routineprüfungen laufen nun in einer isolierten Sitzung, ohne den Verlauf.
  3. Die Beschädigung: Der defekte Gesprächsverlauf wurde archiviert.

Geprüft, nicht angenommen: Nach der Korrektur null Fehler und null unnötige Aufrufe. Von achtzig abgerechneten Aufrufen auf keinen.

Der Schluss, den ich fast falsch gezogen hätte

Meine eigene Dokumentation führte diese Art von Beschädigung auf Neustarts des Agenten zurück, und davon hatte es an diesem Tag acht gegeben. Die Chronologie schloss das aus: Die Beschädigung lag sechs Stunden vor dem ersten Neustart. Eine plausible Ursache, bereits dokumentiert, vereinbar mit den Fakten des Tages. Es genügte, die Zeitstempel nebeneinanderzulegen, und sie fiel in sich zusammen.

Was eine Geschäftsleitung daraus mitnehmen sollte

Die Kosten waren nicht das Thema: einige Dutzend Euro. Das Thema ist, dass zehn Stunden Stille und achtzig abgerechnete Aufrufe keinen einzigen Alarm ausgelöst haben. Das Ziel „die Kosten bleiben marginal“ stand im Lastenheft. Gemessen wurde es nirgends. Solange ein Ziel nicht messtechnisch erfasst ist, wird es nicht eingehalten – es wird erhofft.

Bevor Sie einem Agenten eine Aufgabe übertragen, fragen Sie Ihren Dienstleister: Wie viele Ausführungen sind gestern fehlgeschlagen, und was haben sie gekostet? Kann er das nicht innerhalb einer Minute beantworten, ist das System nicht im Produktivbetrieb. Es läuft auf Bewährung.