Warum KI-Agenten Belege brauchen, bevor sie es erneut versuchen

So verhindern Sie, dass eine ausbleibende Antwort zu einer doppelten Aktion führt

Ein Support-Agent, der dazu berechtigt ist, eine Rückerstattung auszulösen, sendet die Anfrage, verliert jedoch die Verbindung. Der Agent erhält keine Bestätigung über den Erfolg und versucht, die Rückerstattung erneut zu veranlassen. War die ursprüngliche Anfrage erfolgreich, kann der erneute Versuch des Agenten zu einer zweiten Rückerstattung führen.

Das ist rein hypothetisch. Das Beispiel veranschaulicht ein Problem, das sich nicht allein durch die Genauigkeit des Modells lösen lässt. Wie sollte ein Agent vorgehen, wenn er nicht feststellen kann, ob seine vorherige Aktion den Zustand der Umgebung verändert hat?

Unite.AI hat die Zuverlässigkeit von Agenten über die Modelle hinaus untersucht. Fragen der Fehlerbehebung verdienen in diesen Diskussionen eigene Regeln. Bevor ein Agent eine folgenreiche Aktion ein zweites Mal ausführt, sollte er bestätigen, was geschehen ist, oder über eine gültige Garantie verfügen, dass keine doppelten Auswirkungen eintreten.

Eine ausbleibende Antwort belegt keinen Fehlschlag

Eine ausbleibende Antwort belegt nicht, dass eine Aktion fehlgeschlagen ist. Sie lässt nicht erkennen, ob vor der Ausführung ein Fehler aufgetreten ist, ob die Aktion ohne Bestätigung abgeschlossen wurde oder ob der Vorgang noch läuft.

Dies ist ein häufiges Problem in verteilten Systemen, wie von Amazon beschrieben. Amazon erklärt, warum Wiederholungsmechanismen besondere Schutzvorkehrungen gegen wiederholte Nebenwirkungen benötigen. Agenten fügen dem Wiederherstellungspfad Ihres Systems eine neue Entscheidungsinstanz hinzu. Sie können zusätzliche Entscheidungen darüber treffen, wie Fehler behoben werden sollen.

Diese Entscheidungen können die Art und Weise verändern, wie ein Unternehmen arbeitet. Wird beispielsweise eine Rückerstattung mit einem anderen Betrag in Dollar erneut angefordert, ist das nicht bloß ein weiterer Versuch derselben Anfrage. Ebenso ist die Wahl eines zweiten Zahlungsdienstes, wenn der erste nicht mehr reagiert, nicht einfach ein weiterer Versuch derselben Anfrage.

Teams müssen zwischen der Erlaubnis zur Ausführung einer Aktion und der Erlaubnis zur Behebung eines unklaren Ergebnisses unterscheiden. Die ursprüngliche Genehmigung bedeutet nicht, dass es sicher ist, die Aktion erneut auszuführen.

Aktuelle Forschung misst das Risiko

Ein Preprint vom September 2026 mit dem Titel „Where Does Exactly-Once Live?“ stellte den LIMBO-Benchmark vor und untersuchte 25.930 Episoden mit neun Modellen. Die simulierten Dienste wurden mit verlorenen Empfangsbestätigungen, verzögerter Verarbeitung und doppelten Zustellungen getestet.

In 90 % der 1.279 Episoden, in denen im Haupttest der Autoren eine doppelte Wirkung eintrat, meldeten die Agenten den erfolgreichen Abschluss. Ein Agent kann also Erfolg melden, obwohl die Verarbeitung fehlerhaft war.

Diese Ergebnisse beruhen auf kontrollierten Benchmarks und schätzen keine Ausfallraten im Produktivbetrieb. Die Dienste wurden simuliert, und mehrere Analysen dienten der explorativen Untersuchung. Teams sollten die Ergebnisse der Aktionen von Agenten getrennt von deren Meldungen über eine erfolgreiche Ausführung bewerten.

Der Beitrag erläutert außerdem, warum die Überprüfung des aktuellen Zustands unzureichend sein kann. Eine Anfrage, die noch verarbeitet wird, kann nach einer Überprüfung wirksam werden. Auch eine leere Statusantwort bedeutet nicht, dass die Anfrage nicht doch noch wirksam wird.

Wiederholte Versuche beziehen sich auf dieselbe Absicht

Ein empfangender Dienst kann wiederholte Versuche für einen einzelnen Vorgang mithilfe eines Idempotenzschlüssels erkennen. Bei ordnungsgemäßer Unterstützung stellt dieses Verfahren sicher, dass wiederholte Versuche keine zusätzlichen Auswirkungen haben. Der Idempotenzschlüssel muss bei allen Wiederholungsversuchen unverändert bleiben.

Die API-Dokumentation von Stripe veranschaulicht sowohl die Funktionsweise als auch die Einschränkungen von Idempotenzschlüsseln. Bei API v1 können Schlüssel nach mindestens 24 Stunden gelöscht werden. Wird ein gelöschter Schlüssel erneut verwendet, löst dies eine neue Anfrage aus. Stripe überprüft außerdem, ob die vom Anfragenden übermittelten Parameter mit denen der ursprünglichen Anfrage übereinstimmen.

Die praktische Konsequenz der Idempotenz ist, dass sie in Ihrer Integrationsschicht umgesetzt wird und nicht nur in einer Eingabeaufforderung. Bevor Sie einen Vorgang auslösen, halten Sie den genehmigten Vorgang fest. Speichern Sie dessen Kennung, die exakten Parameter, sofern zutreffend die Referenz des Anbieters sowie den Status des Vorgangs.

Bei einer Rückerstattung sollten Sie die Zuordnung der Genehmigung zur ursprünglichen Transaktion sowie alle vom Anbieter zurückgegebenen Rückerstattungskennungen speichern. Die Suche nach einer beliebigen Rückerstattung in gleicher Höhe ist ein weniger überzeugender Nachweis, da zwei berechtigte Anfragen denselben Betrag haben können. Außerdem kann es dauern, bis eine Rückerstattungsanfrage in einem Suchergebnis erscheint. Die ursprüngliche Anfrage könnte noch laufen.

Wenn ein Agent oder Worker neu gestartet wird, sollte die Ausführungsschicht dessen Identität beibehalten. Sie sollte eine geänderte Anfrage zurückweisen, die als derselbe Vorgang übermittelt wird. Eine solche Änderung stellt eine neue Aktion dar, für die nach den Workflow-Regeln eine neue Genehmigungsentscheidung erforderlich ist.

Toolbeschreibungen reichen nicht aus

Prüfen Sie zusätzlich zu den Toolbeschreibungen die Vereinbarung des empfangenden Dienstes zur Idempotenzunterstützung. Testen Sie dessen Implementierung, um festzustellen, welche Garantien tatsächlich erfüllt werden.

Unsicherheit als Betriebszustand behandeln

Abbildung 1. Ein vorgeschlagener Wiederherstellungspfad für folgenreiche Aktionen. Für jeden erneuten Versuch ist außerdem eine aktuelle Autorisierung erforderlich.

Ein bestätigter Abschluss bedeutet, dass der Workflow das Ergebnis dokumentiert und fortgesetzt wird, ohne die Aktion zu wiederholen. Eine bestätigte Nichtausführung erlaubt einen weiteren Versuch nur dann, wenn keine ursprüngliche Anfrage mehr aussteht und die Autorisierung weiterhin gilt.

Bei einem ungeklärten Ergebnis gibt es noch vieles zu beachten. Wenn eine gültige, vom Anbieter unterstützte Garantie gegen doppelte Auswirkungen besteht, können Sie zulassen, dass die ursprüngliche Anfrage mit demselben Schlüssel erneut versucht wird. Andernfalls müssen Schreibvorgänge ausgesetzt und der Sachverhalt durch eine Statusabfrage, den Support des Anbieters oder eine autorisierte Person geklärt werden. Eine nicht eindeutige Prüfung reicht nicht aus, um einen weiteren Versuch zu genehmigen.

Eine Unterbrechung kann auch dann gerechtfertigt sein, wenn der Anbieter Grenzen für Verarbeitung und Sichtbarkeit dokumentiert. Ohne solche Grenzen bestätigt die verstrichene Zeit allein nicht, dass die Aktion nicht ausgeführt wurde. Sie müssen festlegen, wer für ungelöste Fälle zuständig ist und wann diese Zuständigen sie überprüfen müssen.

Die Behebung eines Fehlers kann einen anderen Geschäftsprozess erfordern

Wenn eine Rückerstattung erfolgreich ist, aber die anschließende Benachrichtigung des Kunden fehlschlägt, könnte eine Wiederholung des gesamten Workflows auch die Rückerstattung erneut auslösen. Bei der Fehlerbehebung sollte es darum gehen, den noch ausstehenden Schritt abzuschließen und zugleich Belege für bereits erledigte Arbeiten zu sichern.

Wenn Korrekturmaßnahmen für bereits abgeschlossene Aktionen erforderlich sind, stellt Microsoft Informationen zu Ausgleichstransaktionen bereit. Jede Anwendung legt selbst fest, wie Fehler korrekt ausgeglichen werden. Durch einen Ausgleich lässt sich der ursprüngliche Zustand nicht unbedingt wiederherstellen, und auch der Ausgleich selbst kann fehlschlagen.

Außerdem kann die Stornierung einer Transaktion eine Gebühr nach sich ziehen. Durch die Korrektur einer Nachricht lässt sich nicht sicherstellen, dass niemand eine frühere Version gesehen hat. Daher muss bei jeder Fehlerbehebung ausdrücklich festgelegt werden, was der Agent rückgängig machen, ändern oder verbindlich zusagen darf. Entscheidungen außerhalb dieser Grenzen müssen an eine Person mit der erforderlichen Befugnis weitergeleitet werden.

Den zweiten Versuch vor der Bereitstellung testen

Wählen Sie ein Tool für folgenreiche Aktionen aus und testen Sie die Fehlerbehebung gezielt in einer Testumgebung. Lassen Sie nach erfolgreicher Ausführung die Antwort auf die ursprüngliche Anfrage aus. Verzögern Sie die Ausführung der ersten Anfrage, bis eine Statusprüfung erfolgt ist. Starten Sie während der Fehlerbehebung den Worker neu. Warten Sie, bis die Aufbewahrungsfrist des Schlüssels abgelaufen ist, bevor Sie es erneut versuchen. Ändern Sie bei wiederholten Versuchen einen Parameter.

Bewerten Sie die daraus entstandenen Geschäftsdaten, statt sich lediglich auf Tool-Antworten zu verlassen. Erfassen Sie doppelte Auswirkungen, ungelöste Vorgänge, versäumte Arbeiten, die für die Fehlerbehebung benötigte Zeit und zusätzliche manuelle Eingriffe. Berechnen Sie die Kosten pro korrekt erledigter Aufgabe anhand der Gesamtkosten des Workflows, einschließlich Transaktionsrückabwicklungen und Entschädigungen für Kunden.

Testen Sie außerdem eine echte zweite Anfrage, die der ursprünglichen ähnelt. Stellen Sie sicher, dass Ihr System Duplikate verhindert, ohne neue Arbeit zu blockieren. Bewerten Sie die Vermeidung von Duplikaten und den letztendlichen Abschluss der Aufgabe getrennt voneinander. Andernfalls könnte ein Agent, der jede Aufgabe abbricht, sicher wirken, während er kaum oder gar keinen Mehrwert liefert.

Ihre Evaluierungsfrage sollte klar formuliert sein. Konnte das System erklären:

• Welcher Vorgang war autorisiert?
• Welche Belege lagen vor, um das Ergebnis nachzuweisen?
• Warum war ein weiterer Versuch zulässig?

Ein Agent, der aufgrund ungelöster Unsicherheit pausiert, kann bei Vorführungen weniger effektiv wirken. In Produktivumgebungen kann eine Pause jedoch die ursprüngliche Absicht des Kunden wahren. Sinnvolle Beharrlichkeit bedeutet, dass das System autorisierte Aufgaben erledigt, ohne sie unbemerkt doppelt auszuführen.