Verlässliche Wirkung: Verifikation, Idempotenz, ehrliches Scheitern

Der Aufruf antwortet mit Erfolg, und das Ticket bleibt offen — weil eine Statusregel den Übergang asynchron ablehnt. In sechs Prozent der als erfolgreich verbuchten Läufe war die Aufgabe nicht erledigt. Der Unterschied zwischen dem, was ein Agent meldet, und dem, was tatsächlich eingetreten ist, ist die interessanteste Kennzahl eines agentischen Systems.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-04

Zwei Fragen, die nie zusammenfallen

Wenn ein Agent eine Aktion ausführt, gibt es zwei völlig verschiedene Fragen, und praktisch jedes unzuverlässige System behandelt sie als eine: Hat der Aufruf geantwortet, und ist die Wirkung eingetreten?

Aufruf erfolgreich, Wirkung eingetreten: Der Normalfall. Nichts zu tun.
Aufruf gescheitert, keine Wirkung: Der einfache Fehlerfall. Wiederholen oder aufgeben.
Aufruf gescheitert, Wirkung doch eingetreten: Der teure Fall. Eine Wiederholung erzeugt die Wirkung ein zweites Mal.
Aufruf erfolgreich, Wirkung nicht eingetreten: Der stille Fall. Der Agent meldet Erfolg, und niemand prüft nach.

Die beiden unteren Zeilen sind der eigentliche Inhalt dieses Moduls. Sie entstehen nicht durch Modellfehler, sondern durch verteilte Systeme — und sie treten mit jeder zusätzlichen Runde häufiger auf, weil jede Runde eine weitere Gelegenheit dafür ist.

MerksatzEin Agent, der die Rückmeldung eines Werkzeugs für die Wirkung nimmt, hat keine Verifikation, sondern eine Vermutung mit gutem Ausgang in den meisten Fällen.

Verifikation heißt, den Zustand zu lesen

Die Gegenmaßnahme ist unspektakulär und wird selten eingebaut, weil sie eine Runde kostet: Nach einer wirkenden Aktion wird der Zielzustand gelesen und gegen die Erwartung geprüft. Nicht die Antwort des Schreibaufrufs, sondern eine unabhängige Abfrage.

Der Agent, der Tickets schließt, die offen bleiben

Szenario

Ein Support-Agent schließt bearbeitete Tickets über ein Werkzeug close_ticket. Das Werkzeug antwortet mit einem Erfolgsobjekt. In etwa zwei Prozent der Fälle bleibt das Ticket trotzdem offen, weil eine nachgelagerte Statusregel den Übergang ablehnt — die Ablehnung passiert asynchron, nach der Antwort.

Anforderungen

Ein gemeldeter Abschluss muss dem tatsächlichen Zustand entsprechen
Der Agent soll nicht bei jedem Ticket doppelt so lange brauchen
Ein abweichender Zustand muss auffallen, nicht nur protokolliert werden

Schritte

Befund: Der Erfolgsbericht bezieht sich auf die Annahme des Auftrags, nicht auf den Endzustand. Das ist keine Fehlfunktion, sondern die Semantik des Aufrufs.
Erste Korrektur: Nach dem Schreiben den Ticketstatus lesen und gegen den erwarteten Wert prüfen — als eigener, unabhängiger Aufruf.
Zweite Korrektur: Weil die Ablehnung asynchron erfolgt, ist ein sofortiges Lesen zu früh. Nötig ist eine kurze, begrenzte Wiederholung des Lesens, nicht des Schreibens.
Dritte Korrektur: Weicht der Zustand nach dem letzten Versuch ab, gilt der Lauf als nicht abgeschlossen und geht mit dieser Aussage weiter.
Vierte Korrektur: Die Abweichungsquote wird als Kennzahl geführt. Zwei Prozent sind ein Befund über die Statusregel, nicht über den Agenten.
Gegenprobe: ein Testticket, das die Statusregel bewusst verletzt — der Lauf muss es als offen melden, nicht als geschlossen.

Merksatz: Verifikation ist keine doppelte Arbeit, sondern die einzige Stelle, an der aus einer Behauptung ein Ergebnis wird. Sie kostet einen Leseaufruf und ersetzt eine Vermutung.

Idempotenz, präzise

Wiederholen darf man nur, was wiederholbar ist. Für diesen Begriff gibt es eine exakte Definition, und sie ist enger, als der Alltagsgebrauch vermuten lässt.

Idempotent — Eine Anfragemethode gilt als idempotent, wenn die beabsichtigte Wirkung mehrerer identischer Anfragen mit dieser Methode auf dem Server dieselbe ist wie die Wirkung einer einzelnen solchen Anfrage.

Im HTTP-Standard sind GET, HEAD, PUT, DELETE und OPTIONS idempotent — POST ausdrücklich nicht. Daran hängt eine Erlaubnis, die für Agenten zentral ist: Ein Client darf eine Anfrage mit einer idempotenten Methode automatisch wiederholen, wenn vor einer Zeitgrenze keine Antwort eintrifft, ohne befürchten zu müssen, dass die Anfrage bereits verarbeitet wurde.

Feinheit, die oft fehltIdempotenz bedeutet nicht, dass der Server die Anfrage jedes Mal gleich verarbeitet oder denselben Zustand vorhält — nur, dass ihre Semantik eine gefahrlose Wiederholung erlaubt. Ein zweites DELETE darf also einen anderen Statuscode liefern; die Wirkung bleibt dieselbe.

Für Agentenwerkzeuge folgt daraus eine Aufgabe, die man einmal erledigt und danach hat: Jedes schreibende Werkzeug bekommt eine ausdrückliche Einstufung. set_ticket_status auf einen festen Zielwert ist idempotent, weil zweimal dasselbe Ergebnis entsteht. append_comment ist es nicht, weil der zweite Aufruf einen zweiten Kommentar erzeugt. increment_counter ist es nicht, und refund_payment erst recht nicht.

Diese Einstufung gehört an die Werkzeugdefinition, nicht in ein Wiki. Dann kann die Ausführungsschicht im Fehlerfall automatisch entscheiden, ob eine Wiederholung zulässig ist — und muss das Urteil nicht dem Modell überlassen, das die Semantik des Zielsystems nicht kennt.

Der zweideutige Fehler

Fehler unterscheiden sich nicht nur in ihrer Ursache, sondern darin, was man nach ihnen weiß. Diese Unterscheidung entscheidet über die richtige Reaktion, und genau eine Klasse ist gefährlich.

Abgelehnt: Ein klarer Fehlercode vor der Verarbeitung — ungültige Eingabe, fehlende Berechtigung. Man weiß: keine Wirkung. Wiederholung sinnlos.
Gedrosselt: Ausdrücklich abgewiesen mit Hinweis auf einen späteren Versuch. Man weiß: keine Wirkung. Wiederholung nach Wartezeit richtig.
Zeitüberschreitung oder Verbindungsabbruch: Man weiß nichts. Die Anfrage kann angekommen und verarbeitet worden sein. Eine Wiederholung ist nur bei Idempotenz gefahrlos.
Fehler nach Teilausführung: Man weiß, dass ein Teil gewirkt hat. Eine Wiederholung des Ganzen wiederholt diesen Teil.

Die dritte Zeile ist der Kern. Ein Agent, der bei jeder Zeitüberschreitung wiederholt, doppelt bei nicht idempotenten Aktionen die Wirkung — und weil er es nicht merkt, meldet er am Ende Erfolg. Die naheliegende Antwort, bei Zeitüberschreitung nie zu wiederholen, ist ebenfalls falsch: Dann scheitert jeder Lauf an einem vorübergehenden Netzproblem.

Die tragfähige Antwort ist, die Wiederholbarkeit zur Eigenschaft der Aktion zu machen statt zur Entscheidung im Fehlerfall. Dann muss der Agent im Fehlerfall nichts abwägen, sondern nur nachsehen, wie die Aktion eingestuft ist.

Idempotenz herstellen, wo sie nicht gegeben ist

Viele nützliche Aktionen sind von Natur aus nicht idempotent: eine Zahlung auslösen, eine E-Mail versenden, einen Datensatz anlegen. Für genau diesen Fall gibt es ein etabliertes Verfahren.

Der Aufrufer erzeugt einen eindeutigen Schlüssel je fachlichem Vorgang→Er schickt ihn im Feld Idempotency-Key mit der Anfrage→Der Server erkennt an diesem Schlüssel eine Wiederholung derselben Anfrage→Bei Wiederholung liefert er das gespeicherte Ergebnis statt die Wirkung erneut zu erzeugen

Am hervorgehobenen Schritt entscheidet sich, ob das Verfahren trägt. Der Schlüssel muss den fachlichen Vorgang identifizieren, nicht den technischen Versuch. Ein je Versuch neu erzeugter Zufallswert macht jede Wiederholung zu einem neuen Vorgang — das Verfahren ist dann eingebaut und wirkungslos. Bei einem Agenten heißt das: Der Schlüssel gehört zum Auftrag und wird beim Wiederholen mitgenommen.

Zwei Pflichten liegen auf der Serverseite: Sie muss ihre Idempotenz-Regeln veröffentlichen, und diese Angabe muss eine Ablaufregel enthalten, falls es eine gibt. Ein Schlüssel, dessen Gültigkeit nach 24 Stunden endet, schützt einen Lauf nicht, der nach zwei Tagen wiederaufgenommen wird — das ist keine Randnotiz, sondern der Grund, warum langlaufende Agenten hier eigene Regeln brauchen.

MerksatzWo kein Schlüsselfeld angeboten wird, bleibt der natürliche Schlüssel: eine fachliche Eindeutigkeit, die das Zielsystem selbst durchsetzt — etwa eine Rechnungsnummer mit Eindeutigkeitsbedingung. Auch das ist Idempotenz, nur eine, die man nicht abschalten kann.

Die Teilwirkung

Ein Agentenlauf mit mehreren schreibenden Schritten kann in der Mitte scheitern. Damit gibt es einen Zustand, der in keinem Entwurf vorkommt und in jedem Betrieb: halb erledigt.

Schritte einzeln idempotent machen — dann ist eine Wiederaufnahme von vorn ungefährlich, weil erledigte Schritte nichts mehr verändern.
Fortschritt außerhalb des Laufs festhalten — dann kann die Wiederaufnahme beim ersten offenen Schritt beginnen statt von vorn.
Reihenfolge nach Rückholbarkeit — reversible Schritte zuerst, unumkehrbare so spät wie möglich. Dann trifft ein Abbruch möglichst wenig Unumkehrbares.
Kompensationsschritt je unumkehrbarem Schritt — kein Rollback, sondern eine ausdrückliche Gegenaktion, die den fachlichen Effekt aufhebt.

Der dritte Punkt ist der billigste und wird am häufigsten übersehen. Eine Reihenfolge zu ändern kostet nichts, verschiebt aber den Erwartungswert des Schadens: Ein Lauf, der zuerst den unumkehrbaren Versand auslöst und danach die reversible Datenbankänderung, hinterlässt beim Abbruch das Maximum an Nichtrückholbarem.

Wichtig ist dabei die Abgrenzung zu einer Transaktion. Über mehrere Fremdsysteme hinweg gibt es kein gemeinsames Zurückrollen — was in System A geschrieben wurde, bleibt dort, auch wenn System C ausfällt. Die Frage lautet deshalb nie „wie mache ich das transaktional“, sondern „welche Gegenaktion hebt den fachlichen Effekt auf, und existiert sie überhaupt“. Für einen versendeten Newsletter lautet die ehrliche Antwort: Es gibt keine.

Ehrlich scheitern

Ein Agent, der eine Aufgabe nicht abschließen kann, hat drei Möglichkeiten, und zwei davon sind schädlich. Er kann still verschwinden, er kann etwas Plausibles behaupten, oder er kann sagen, was er erreicht hat und was nicht.

Stilles Verschwinden: Der Lauf endet an einer Grenze ohne Aussage. Der Auftrag ist halb ausgeführt, und niemand weiß, welche Hälfte.
Plausible Behauptung: Die teuerste Variante: Der Lauf meldet Erfolg, den es nicht gab. Im Protokoll ist er von einem echten Erfolg nicht zu unterscheiden.
Ausdrücklicher Fehlschlag: Der Lauf gibt zurück, welche Schritte erledigt sind, woran er gescheitert ist und was ein Mensch als Nächstes tun kann.

Die dritte Form ist keine Frage der Prompt-Formulierung, sondern der Konstruktion. Sie setzt voraus, dass es überhaupt einen Rückgabeweg für Teilerfolg gibt — ein Ergebnisobjekt mit Feldern für erledigte Schritte, offene Schritte und Grund des Abbruchs. Wo dieses Objekt nur „Erfolg“ und „Fehler“ kennt, kann kein Modell ehrlich scheitern, weil es dafür kein Feld hat.

Kurzcheck

Ein Agent soll drei Systeme aktualisieren. Nach dem zweiten fällt das dritte aus. Was ist die richtige Rückgabe?

Ein Ergebnis mit den zwei erledigten Schritten, dem offenen Schritt und dem Grund des Abbruchs
Ein Fehler ohne weitere Angaben, damit der Lauf klar als gescheitert gilt
Ein Erfolg mit dem Hinweis, dass ein System zurzeit nicht erreichbar war
Die ersten zwei Schritte zurücknehmen und den Lauf als vollständig gescheitert melden

Treffer. Der Zustand bleibt bearbeitbar: Ein Mensch oder ein späterer Lauf weiß genau, wo fortzusetzen ist, ohne die ersten zwei Schritte zu wiederholen.

Degradierte Modi

Zwischen „läuft“ und „gescheitert“ liegt ein Bereich, den verlässliche Systeme ausdrücklich gestalten: eingeschränkter Betrieb. Ein Agent, dessen Suchwerkzeug ausfällt, muss nicht ausfallen — er kann auf das antworten, was ohne Suche beantwortbar ist, und den Rest kennzeichnen.

Der Modus ist benannt — der Lauf weiß und meldet, dass er eingeschränkt gearbeitet hat.
Die Einschränkung steht im Ergebnis — nicht nur im Protokoll, sondern in der Ausgabe, die ein Mensch liest.
Die Grenze ist enger, nicht weiter — im eingeschränkten Betrieb darf ein Agent weniger, nicht dasselbe mit weniger Information.
Der Modus endet — es gibt eine Bedingung, unter der der Normalbetrieb wieder greift, statt eines Dauerzustands, den niemand mehr bemerkt.

Preis der richtigen WahlEin eingeschränkter Betrieb, der wie der Normalbetrieb aussieht, ist schlechter als ein Ausfall. Der Ausfall erzeugt einen Vorgang; die unmarkierte Einschränkung erzeugt Antworten, denen niemand ansieht, dass die halbe Grundlage fehlte.

Was im Protokoll stehen muss

Bei klassischer Software genügt oft Eingabe und Ausgabe. Bei einem Agenten ist das zu wenig: Wer nur beides hat, kann einen gemeldeten Fehlschlag weder nachstellen noch einordnen, weil der Pfad dazwischen die eigentliche Information ist.

Jeden Schritt mit Zeitstempel, gewähltem Werkzeug und den übergebenen Argumenten.
Jede Rückgabe, gekürzt aber mit Statusklasse und Umfang, damit ein leeres Ergebnis von einem Fehler unterscheidbar bleibt.
Jede Grenze, die griff — Rundendeckel, Zeitgrenze, Mengenprüfung — mit unterscheidbarem Grund.
Das Ergebnis der Verifikation, nicht nur die Rückmeldung der Aktion.
Den Abschlussgrund des Laufs: Ziel erreicht, Grenze erreicht, Fehlschlag, eingeschränkt abgeschlossen.

Sensible Inhalte gehören dabei redigiert und der Zugriff enger als bei gewöhnlicher Telemetrie — die Trajektorie ist eine vollständige Kopie dessen, was der Agent gesehen hat. Diese Spannung zwischen Nachvollziehbarkeit und Datensparsamkeit ist nicht auflösbar, sondern zu entscheiden.

Eine Kennung, die durch alles läuft

Die Trajektorie allein reicht nicht, weil die Wirkung außerhalb des Agenten entsteht. Gebraucht wird eine Korrelationskennung, die vom Auftrag über jeden Werkzeugaufruf bis in die Protokolle der Zielsysteme durchgereicht wird.

Der Nutzen zeigt sich erst im Vorfall, dann aber unmittelbar: Mit einer solchen Kennung ist die Frage „was hat dieser Lauf angefasst“ eine Abfrage. Ohne sie ist sie eine Rekonstruktion über Zeitfenster — und die ist ungenau in beide Richtungen, weil parallele Läufe sich überlappen und ein Zeitfenster fremde Änderungen mit einschließt.

Praktisch heißt das, die Kennung als Feld in jedem Werkzeugaufruf zu führen und von den Zielsystemen zu verlangen, sie in ihre Protokolle zu übernehmen. Das ist eine Anforderung an fremde Systeme und damit organisatorische Arbeit — aber sie ist die Voraussetzung dafür, dass ein Wirkungsradius später bestimmbar ist statt geschätzt.

Wann ein Lauf fertig ist

Die letzte und am seltensten gestellte Frage: Woran erkennt das System, dass ein Auftrag erledigt ist? In den meisten Implementierungen lautet die Antwort: daran, dass das Modell aufhört, Werkzeuge anzufordern. Das ist eine Aussage über das Modell, nicht über die Aufgabe.

Selbstberichtet: Der Agent hört auf und erklärt sich für fertig. Billig, und im Fehlerfall nicht von einem Aufgeben zu unterscheiden.
Zustandsbasiert: Der Code prüft eine überprüfbare Bedingung: Ticket geschlossen, Datensatz vorhanden, Betrag stimmt. Kostet eine Abfrage und ist eine Zusicherung.
Beides: Der Regelfall: Der Agent erklärt sich für fertig, und der Code prüft nach. Weicht beides ab, gilt die Prüfung.

Die dritte Zeile klingt nach Doppelarbeit und ist der Kern dieses Moduls in einem Satz. Der Agent liefert die Behauptung, der Code liefert das Ergebnis — und der Unterschied zwischen beiden ist die interessanteste Kennzahl, die ein agentisches System hat.

Diese Kennzahl verdient einen eigenen Namen und ein eigenes Dashboard: der Anteil der Läufe, in denen sich der Agent für fertig erklärt hat und die Zustandsprüfung widersprochen hat. Sie ist aus zwei Gründen wertvoll. Erstens misst sie genau das, was sonst unsichtbar bleibt — der stille Fall aus der ersten Tabelle. Zweitens reagiert sie empfindlich auf Änderungen: Ein Prompt-Wechsel, ein Modellwechsel oder eine geänderte Statusregel im Zielsystem schlagen hier auf, bevor sich eine Beschwerde ergibt.

Was der Check prüft

Aktionen danach einordnen, ob ihre Wiederholung gefahrlos ist.
Eine gemeldete Wirkung gegen den tatsächlichen Zustand prüfen.
Für jede Fehlerklasse die passende Reaktion wählen — insbesondere für die zweideutige.
Eine Wiederholungskonfiguration lesen und die Stelle finden, die den Schutz aufhebt.
Einen Lauf so gestalten, dass er ehrlich scheitern kann, weil es ein Feld dafür gibt.
Eine Teilwirkung wiederaufnehmbar machen statt sie zu wiederholen oder zu verwerfen.
Entscheiden, was eine Trajektorie enthalten muss, damit ein Fehlschlag einordenbar ist.
Einen eingeschränkten Betrieb so bauen, dass er als eingeschränkt erkennbar bleibt.
Ein Abschlusskriterium formulieren, das nicht am Verhalten des Modells hängt.

Der gemeinsame Nenner: Verlässlichkeit entsteht nicht daran, dass ein Agent seltener falsch handelt, sondern daran, dass jede Wirkung überprüft, jede Wiederholung erlaubt und jeder Fehlschlag benennbar ist.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-04