Wenn ein Tool ausfällt: So verhindern Sie, dass ein Agent eine Aktion wiederholt

Das Problem: Eine Aktion kann ausgeführt werden, ohne dass ihre Bestätigung ankommt

Ein Agent, der Tools verwendet, kann in einem anderen System einen Vorgang starten und die Verbindung verlieren, bevor eine eindeutige Antwort eintrifft. Dadurch entsteht eine unklare Situation: Der Agent weiß nicht, ob das Zielsystem die Änderung übernommen hat. Dass eine Bestätigung fehlt, beweist jedoch ebenso wenig, dass die Änderung nicht erfolgt ist. Wird dieselbe Aktion ohne vorherige Statusprüfung erneut ausgeführt, kann ein Duplikat entstehen oder die Auswirkung größer werden.

Dieses Problem unterscheidet sich davon, eine Antwort erneut generieren zu lassen. In einem Gespräch kann eine Wiederholung einen anderen Text hervorbringen. Wenn ein Tool dagegen einen Datensatz ändert, einen Termin bucht oder eine Datei bearbeitet, kann die Wiederholung eine zweite externe Wirkung auslösen. Der Wiederherstellungsprozess sollte deshalb zuerst klären, was geschehen ist, statt die ursprüngliche Anweisung automatisch zu wiederholen.

Dieser Leitfaden schlägt eine operative Vorgehensweise vor, garantiert aber nicht, dass jedes System eine Wiederherstellung ermöglicht. Ob sich ein Status überprüfen, ein Vorgang anhalten oder eine Änderung kompensieren lässt, hängt von den konkret verwendeten Tools und den dokumentierten Funktionen ab. Wenn sich der Zustand des Zielsystems nicht beobachten lässt, sollte der Agent die Unsicherheit als Grund zum Pausieren oder Eskalieren behandeln – nicht als Erlaubnis, etwas anzunehmen.

Den Ablauf abgrenzen, bevor Sie die Wiederherstellung entwerfen

Beschreiben Sie die Aufgabe als Folge konkreter Schritte und halten Sie fest, welche Tools beteiligt sind. Notieren Sie für jeden Schritt, ob er lediglich Informationen liest, einen Zustand schreibt oder ändert oder eine externe Wirkung haben kann, die sich nur schwer rückgängig machen lässt. Durch diese Einteilung können Sie Kontrollen gezielt auf jene Schritte konzentrieren, bei denen eine Wiederholung Folgen haben könnte.

Es genügt nicht, ein Tool anhand seines Namens zu klassifizieren. Dieselbe Integration kann sowohl eine Abfrage als auch einen Schreibvorgang bereitstellen. Ebenso wenig reicht es aus, nur die allgemeine Absicht des Agenten zu beschreiben: „einen Termin verwalten“ kann die Suche nach freien Zeiten, das Erstellen einer Buchung und das Versenden einer Benachrichtigung umfassen. Jeder dieser Vorgänge kann einen anderen Status haben und eine eigene Wiederherstellungsentscheidung erfordern.

Legen Sie außerdem fest, anhand welcher Beobachtung ein Schritt als abgeschlossen gilt. Bei der Änderung eines Datensatzes kann es beispielsweise nötig sein, den Datensatz erneut auszulesen und die relevanten Felder zu prüfen. Bei einer Buchung muss möglicherweise festgestellt werden, ob ein Termin mit den erwarteten Angaben existiert. Bei einer Codeänderung können Sie den Dateiinhalt oder den Status der Änderung prüfen. Das sind Gestaltungsmuster, die an die tatsächlichen Funktionen des jeweiligen Systems angepasst werden müssen.

Legen Sie vor einem Schreibvorgang den Handlungsrahmen fest: Welche Entität darf der Agent ändern, welche Daten darf er bearbeiten und welche Aktionen liegen außerhalb seiner Berechtigungen? Berechtigungen begrenzen den möglichen Schaden. Sie belegen aber nicht, dass eine frühere Aktion erfolgreich war, und machen eine Wiederholung nicht automatisch sicher. Bei der Tool-Auswahl müssen Autorisierung und Wissen über den aktuellen Status getrennt bleiben.

Status einordnen, bevor Sie entscheiden

Halten Sie nach einem Fehler die letzte verlässliche Beobachtung fest und ordnen Sie den unterbrochenen Schritt ein. Eine praktikable Einteilung unterscheidet vier Zustände: Die Aktion wurde nicht begonnen; das Ergebnis ist bestätigt; das Ergebnis ist ungewiss; oder die Aufgabe wurde nur teilweise abgeschlossen. Die Einordnung muss auf verfügbaren Belegen beruhen, nicht auf der Erklärung, die der Agent bevorzugt.

„Nicht begonnen“ bedeutet, dass ausreichend belegt ist, dass der Schritt nicht übermittelt wurde oder nicht begonnen hat. „Bestätigt“ bedeutet, dass eine Antwort oder eine spätere Abfrage das erwartete Ergebnis nachweist. „Ungewiss“ bedeutet, dass die Belege nicht ausreichen, um zwischen Ausführung und Nichtausführung zu unterscheiden. „Teilweise abgeschlossen“ bedeutet, dass einige Schritte oder Auswirkungen abgeschlossen sind, während andere noch ausstehen. Wenn zwei Kategorien infrage kommen, wählen Sie die vorsichtigere und machen Sie aus Unsicherheit keine Bestätigung.

Die Unterscheidung ist wichtig, weil sich die angemessene Reaktion ändert. Wenn der Schritt nicht begonnen hat, kann es möglich sein, ihn zu starten – vorausgesetzt, Berechtigungen und Ablaufregeln erlauben es. Ist er bestätigt, sollte er nicht allein deshalb wiederholt werden, um eine eindeutigere Antwort zu erhalten. Bei einem ungewissen Ergebnis wird zuerst das Zielsystem abgefragt. Gibt es keine verlässliche Abfrage, wird der Vorgang angehalten oder eskaliert. Bei einer teilweise erledigten Aufgabe wird nur von einem geprüften Zustand aus fortgesetzt; bereits eingetretene Auswirkungen sind dabei zu berücksichtigen.

Der Status des Agenten darf nicht mit dem Zustand des externen Systems verwechselt werden. Ein Checkpoint kann festhalten, welche Schritte der Ablauf versucht hat oder welche Antwort eingegangen ist. Diese Angaben können jedoch veraltet sein, wenn ein anderer Prozess das Zielsystem verändert oder eine Bestätigung verloren ging. Ein Checkpoint hilft dabei, den Kontext wiederherzustellen. Für sich allein belegt er nicht den aktuellen Zustand.

Prüfen Sie vor einer Wiederholung das Zielsystem und achten Sie auf Duplikate

Die erste operative Frage lautet nicht: „Kann ich das Tool noch einmal aufrufen?“, sondern: „Was kann ich jetzt im betroffenen System beobachten?“ Wenn eine autorisierte Abfrage verfügbar ist, suchen Sie anhand der Angaben, die den Vorgang identifizieren, nach dem zugehörigen Objekt oder der Änderung. Prüfen Sie, ob die relevanten Merkmale übereinstimmen und ob bereits ein gleichwertiges Ergebnis vorliegt. Verlassen Sie sich nicht auf ein einzelnes Merkmal, wenn es den aktuellen Vorgang nicht von ähnlichen Vorgängen unterscheiden kann.

Eine Anfrage kann eine Vorgangskennung oder eine aufgabenspezifische Referenz haben. Wenn das System dokumentiert, wie sich ein Vorgang abfragen oder eine doppelte Anfrage erkennen lässt, verwenden Sie diesen Mechanismus genau wie beschrieben. Nehmen Sie nicht an, dass jedes Tool einen Idempotenzschlüssel akzeptiert, dass eine Kennung wiederholte Auswirkungen verhindert oder dass ein Ergebnis mit demselben Text zwangsläufig zur selben Aktion gehört.

Zur Duplikaterkennung brauchen Sie klare Kriterien. Vergleichen Sie bei einer Datensatzänderung die Datensatzkennung und die Felder, die geändert werden sollten. Prüfen Sie bei einem Termin die Angaben, anhand derer sich die Buchung unterscheiden lässt, sowie ihren aktuellen Status. Bei einer Codeänderung untersuchen Sie die Datei oder den Änderungsstatus, bevor Sie eine weitere Änderung vornehmen. Das sind Beispiele für Prüfungen, keine Zusicherung, dass ein bestimmter Anbieter solche Funktionen bereitstellt.

Wenn keine Statusabfrage verfügbar ist, sie unvollständige Angaben zurückgibt oder einen früheren Vorgang nicht von einem anderen unterscheiden kann, bleibt die Lage ungewiss. Legen Sie für diesen Fall eine Abbruchbedingung fest. Eine nicht verifizierbare Antwort darf nicht in eine günstige Annahme umgedeutet werden – insbesondere dann nicht, wenn eine zweite Ausführung zusätzliche Auswirkungen haben könnte.

Entscheiden, ob Sie fortfahren, kompensieren, anhalten oder eskalieren

Fahren Sie fort, wenn der vorherige Zustand hinreichend klar ist, der ausstehende Schritt innerhalb des autorisierten Rahmens liegt und sich sein Ergebnis überprüfen lässt. Fortsetzen bedeutet, vom letzten geprüften Zustand aus weiterzugehen – nicht, die ganze Abfolge von Anfang an zu wiederholen. Besteht der Ablauf aus mehreren Schritten, halten Sie fest, welche bestätigt sind und welche noch nicht begonnen haben. So wird bereits wirksame Arbeit nicht erneut ausgeführt.

Eine Kompensation versucht, eine bestätigte Auswirkung mit einer anderen Aktion zu korrigieren. Das ist nicht immer möglich und stellt nicht zwingend den ursprünglichen Zustand exakt wieder her. Bevor Sie eine Kompensation entwerfen, prüfen Sie, ob der Vorgang für das System dokumentiert ist, ob das Konto zur Ausführung berechtigt ist und ob die Änderung einen inzwischen entstandenen Folgezustand beeinflussen würde. Können Sie diese Voraussetzungen nicht bestätigen, stellen Sie die Kompensation nicht als garantierte Rücknahme dar.

Ein Anhalten ist eine zulässige Entscheidung, wenn die nächste Aktion eine unklare Situation verschlimmern könnte, den autorisierten Rahmen überschreitet oder sich nicht ausreichend überprüfen lässt. Menschliche Unterstützung ist angemessen, wenn mehrdeutige Belege interpretiert, folgenreichere Aktionen freigegeben, Kompensationen bewertet oder Änderungen behandelt werden müssen, die sich nicht sicher rückgängig machen lassen. Beim Pausieren sollte der minimale Kontext erhalten bleiben, den eine Überprüfung erfordert.

Legen Sie im Voraus fest, welche Bedingungen eine menschliche Intervention erfordern. Beispiele sind ein ungewisses Schreibergebnis ohne Statusabfrage des Zielsystems, ein Vorgang mit erheblichen Folgen, bei dem eine Wiederholung einen Effekt duplizieren könnte, eine nicht dokumentierte Kompensation, fehlende Berechtigungen zur Prüfung oder eine Abweichung zwischen dem im Ablauf gespeicherten Zustand und dem Zielsystem. Passen Sie diese Schwellen an die Auswirkungen und Verpflichtungen der jeweiligen Umgebung an, statt für jede Aktion dieselbe Regel anzuwenden.

Anwendungsbeispiele: Terminbuchung und Codeänderung

Bei einer Terminbuchung lässt eine verlorene Antwort nach dem Absenden der Anfrage offen, ob der Termin bereits angelegt wurde. Der Agent muss den Buchungsstatus mit den tatsächlich verfügbaren Funktionen abfragen und prüfen, ob der erwartete Termin angezeigt wird. Findet er ein passendes Ergebnis, darf er nicht noch eine Buchung erstellen, nur weil die Bestätigung fehlt. Kann er einen bereits ausgeführten Vorgang nicht von einem noch ausstehenden unterscheiden, muss er den automatischen Versuch anhalten und gemäß den Regeln des Dienstes eine Überprüfung anfordern.

Bei der Prüfung muss auch berücksichtigt werden, dass sich der Status zwischen Abfrage und nächster Aktion ändern kann. Deshalb darf der Ablauf eine ältere Beobachtung nicht als unbegrenzt gültige Garantie behandeln. Bietet das Tool eine Vorgangsreferenz oder eine dokumentierte Statusabfrage, verwenden Sie diese. Wenn nicht, beschränken Sie Ihre Schlussfolgerungen auf das, was tatsächlich beobachtet werden konnte. Behaupten Sie nicht, der Termin sei bestätigt, wenn die Belege lediglich zeigen, dass der Agent versucht hat, ihn anzufragen.

Bei einer Codeänderung besteht das Risiko nicht nur darin, denselben Schreibvorgang für dieselbe Datei zu wiederholen. Der Inhalt kann sich seit dem Checkpoint geändert haben, oder ein Teil der Aufgabe wurde bereits umgesetzt, während ein anderer noch aussteht. Prüfen Sie vor einer erneuten Änderung den aktuellen Zustand und vergleichen Sie die erwartete Änderung mit dem beobachtbaren Ergebnis. Ist die Änderung bereits vorhanden, wenden Sie sie nicht blind noch einmal an. Weicht der Zustand ab oder lässt er sich nicht rekonstruieren, halten Sie den Ablauf an und prüfen Sie, was erhalten bleiben und was korrigiert werden muss.

In allen drei Beispielen sollte der Agent das Ergebnis präzise mitteilen: Versuch unternommen, Auswirkung verifiziert, Ergebnis ungewiss oder Intervention erforderlich. Die Beschreibung des Ablaufs darf einen versendeten Aufruf nicht mit einer abgeschlossenen Aufgabe gleichsetzen.

Nützlichen Kontext speichern, ohne ihn mit dem aktuellen Zustand gleichzusetzen

Für die Wiederaufnahme einer Aufgabe muss nicht wahllos das gesamte Gespräch gespeichert werden. Bewahren Sie den operativen Status auf, der die Aufgabe erkennen und ihre Entscheidungen rekonstruieren lässt: eine Aufgabenkennung oder Referenz, sofern vorhanden; den aktuellen Schritt; das aufgerufene Tool und den Vorgang; die letzte beobachtete Antwort; die Statusklassifizierung; die durchgeführten Prüfungen und deren Zeitpunkt; bestätigte Auswirkungen sowie den Grund für eine Pause oder Eskalation. Halten Sie außerdem fest, was noch aussteht und welche Autorisierungsgrenzen gelten.

Speichern Sie keine sensiblen Daten, die für die Wiederherstellung nicht erforderlich sind. Legen Sie fest, wer auf das Protokoll zugreifen darf, wie lange es aufbewahrt wird und wie es gemäß den Regeln der jeweiligen Umgebung geschützt oder gelöscht wird. Die Aufbewahrungsdauer lässt sich nicht als allgemeingültiger Wert festlegen: Sie hängt von den einschlägigen Datenschutz-, Prüfungs- und Betriebsanforderungen ab. Enthält das Protokoll personenbezogene Daten oder Systemdetails, begrenzen Sie seinen Umfang und den Zugriff darauf.

Gesprächsgedächtnis und Aufgaben-Checkpoint haben unterschiedliche Aufgaben. Das Gesprächsgedächtnis kann helfen, die Bitte des Nutzers einzuordnen. Ein Aufgaben-Checkpoint sollte dagegen den vom Ablauf beobachteten operativen Zustand abbilden. Keines von beiden ersetzt eine Abfrage des Zielsystems, wenn die Aufgabe von einer externen Auswirkung abhängt, die sich verändert haben könnte. Behandeln Sie gespeicherte Erinnerungen als Hinweis für die Wiederherstellung, nicht als ausreichenden Beleg dafür, dass die Außenwelt unverändert ist.

Fügen Sie Zeitstempel oder die Reihenfolge der Beobachtungen hinzu, wenn sie zum Verständnis des Protokolls erforderlich sind. Können andere Personen oder Prozesse das System verändern, kann eine frühere Abfrage bereits veraltet sein. Prüfen Sie bei der Wiederaufnahme eines sensiblen Vorgangs die relevanten Daten erneut, statt anzunehmen, dass der Checkpoint noch aktuell ist.

Berechtigungen und Autonomie: Den Handlungsspielraum des Wiederherstellungsschritts begrenzen

Gestalten Sie Berechtigungen so, dass jeder Vorgang nur den notwendigen Mindestumfang hat. Benötigt der Agent lediglich die Möglichkeit, ein Ergebnis zu überprüfen, sollte daraus nicht automatisch folgen, dass er weitere Datensätze ändern oder Vorgänge stornieren darf. Erfordert eine Kompensation eine andere Berechtigung, trennen Sie sie von der Abfrage und legen Sie fest, unter welchen Bedingungen sie verwendet werden darf. So bleibt der Unterschied zwischen Beobachten, Handeln und Korrigieren sichtbar.

Ein Fehler darf nicht dazu führen, dass der Agent autonomer wird. Ein Agent, der eine ursprüngliche Änderung vornehmen durfte, erhält dadurch nicht automatisch die Erlaubnis, zusätzliche Aktionen auszuführen, die Änderung zurückzunehmen oder damit verbundene Objekte zu bearbeiten. Legen Sie fest, welche Entscheidungen automatisch getroffen werden dürfen, welche eine Freigabe erfordern und welche Informationen eine Person für ihre Entscheidung erhalten muss.

Eine menschliche Freigabe sollte sich auf eine konkrete Aktion und deren Belege beziehen. Bitten Sie nicht pauschal um die Genehmigung, „das Problem zu lösen“. Erläutern Sie stattdessen, welcher Zustand beobachtet wurde, was nicht bestätigt werden konnte, welche Aktion vorgeschlagen wird und welche Folgen sie haben könnte. Fehlen wesentliche Informationen, sollten diese zuerst eingeholt oder der Vorgang angehalten werden. Eine Freigabeanfrage darf die Unsicherheit nicht verschleiern.

Berechtigungen verkleinern die Menge möglicher Aktionen, lösen aber für sich genommen keine Teilausfälle. Trennen Sie die Begrenzung des Handlungsspielraums, die Statusabfrage und die Wiederherstellungsregeln voneinander. Wo eine Aufgabe externe Änderungen bewirken kann, braucht ein verlässliches Design alle drei Elemente.

Reproduzierbare Fehler vor dem Einsatz testen

Tests sollten nicht nur Tool-Fehler simulieren, sondern auch die Trennung zwischen Ausführung und Bestätigung. Ein wichtiger Fall ist, dass das Zielsystem eine Änderung übernimmt, der Agent die Antwort jedoch nicht erhält. Der Test prüft, ob der Ablauf das Zielsystem abfragt oder stoppt, statt den Vorgang automatisch zu wiederholen. Kann die Testumgebung dieses Verhalten nicht nachstellen, dokumentieren Sie die Einschränkung und prüfen Sie zumindest die Richtlinie für unklare Fälle anhand kontrolliert mehrdeutiger Antworten.

Beziehen Sie auch verspätete Bestätigungen ein. Der Agent kann beispielsweise pausieren und eine Statusprüfung beginnen, während die Antwort auf den ursprünglichen Vorgang später eintrifft. Prüfen Sie, ob diese verspätete Antwort den Status konsistent aktualisiert und keine zweite Ausführung auslöst. Testen Sie auch den umgekehrten Fall: Der erste Vorgang wurde nicht ausgeführt, und der Ablauf erhält ausreichende Belege, um den ausstehenden Schritt gemäß den Regeln zu starten.

Ergänzen Sie Szenarien mit Duplikaten, Teilzuständen, nicht verfügbarer Statusabfrage, unzureichenden Berechtigungen und nicht dokumentierten Kompensationen. Legen Sie für jedes Szenario vor dem Test das erwartete Ergebnis fest: Welche Aktionen darf der Agent ausführen, welche muss er vermeiden, was muss er protokollieren und wann muss er eskalieren? Ein Test, der lediglich prüft, ob der Agent antwortet, belegt nicht, dass die Wiederherstellung sicher ist.

Verwenden Sie überprüfbare Ergebnisse. Zählen Sie die ausgeführten Schreibvorgänge, prüfen Sie den Endzustand im Zielsystem, suchen Sie nach Duplikaten und kontrollieren Sie, ob Auswirkungen außerhalb des autorisierten Rahmens entstanden sind. Bewerten Sie die ursprüngliche Aufgabe und die Wiederherstellung getrennt voneinander: Dass der Nutzer letztlich ein Ergebnis erhält, beweist nicht, dass der Ablauf eine Wiederholung vermieden oder seine Grenzen eingehalten hat.

Wiederholen Sie die Tests, wenn sich Tools, Berechtigungen, Wiederaufnahmeregeln oder das Format der Checkpoints ändern. Halten Sie die relevanten Versionen und Bedingungen fest, damit die Ergebnisse reproduzierbar bleiben. Ein bestandener Test ist keine Garantie für alle künftigen Fehler. Er belegt das beobachtete Verhalten in den definierten Szenarien.

Ablauf bewerten und den Einsatz vorbereiten

Bewerten Sie die Wiederherstellung anhand mehrerer Messgrößen und nicht mit einer einzigen Erfolgskategorie. Prüfen Sie, wie oft ein Schreibvorgang wiederholt wurde, wie viele Endergebnisse verifiziert wurden, wie viele Fälle korrekt angehalten wurden und wie viele Aktionen die Berechtigungen überschritten. Prüfen Sie außerdem die Eskalationen: Enthielten sie genügend Kontext, und wurden sie bei den vorgesehenen Bedingungen ausgelöst?

Interpretieren Sie Kennzahlen gemeinsam mit den Testfällen und den möglichen Auswirkungen. Eine niedrige Wiederholungsrate beweist nicht, dass das System sicher ist, wenn es zugleich unklare Aufgaben unerkannt lässt. Auch ein korrekter Endzustand reicht nicht aus, wenn er durch eine doppelte Aktion oder eine nicht autorisierte Kompensation erreicht wurde. Legen Sie im Voraus fest, welche Ergebnisse akzeptabel sind und welche Fehler den Einsatz verhindern.

Bevor Sie Aktionen mit größeren Auswirkungen freischalten, erproben Sie das Verfahren mit risikoarmen Vorgängen oder in einer geeigneten Testumgebung. Vergewissern Sie sich, dass Statusabfragen funktionieren, dass die Berechtigungen für Prüfungen ausreichen, aber nicht unnötig viele Handlungsmöglichkeiten eröffnen, dass sich Ereignisse anhand der Protokolle rekonstruieren lassen und dass Pausen eine Person erreichen, die entscheiden kann. Ist eine notwendige Voraussetzung nicht verfügbar, begrenzen Sie den Umfang der Automatisierung, statt anzunehmen, der Agent könne das Problem lösen.

Die verfügbaren Quellen umfassen Dokumentation zur Fehlerbehebung bei der Tool-Nutzung sowie allgemeine Hinweise zum Vorfallmanagement und zur Notfallwiederherstellung. Sie legen für sich genommen nicht fest, wie sich eine konkrete Integration bei einer verlorenen Antwort verhält, ob sie Duplikate erkennen kann oder ob sich ein Vorgang rückgängig machen lässt. Diese Punkte müssen für jedes System überprüft werden, bevor eine Gestaltungsempfehlung zur operativen Anweisung wird.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.