KURZ ERKLÄRT
Robuste Wiederholungen beginnen mit der Frage, ob die erste Aktion bereits stattgefunden hat. Ein Timeout beweist keinen Fehlschlag. Verwendet stabile Arbeitskennungen, prüft unklare Zielzustände und unterscheidet lesende Wiederholungen von erneut ausgelösten Änderungen. Idempotenz muss die tatsächliche Nebenwirkung berücksichtigen; eine freundlich formulierte Anweisung, nichts doppelt zu tun, ersetzt diese technische Eigenschaft nicht.
Wie ihr einzelne KI-Anwendungen in verlässliche Marketingabläufe einordnet, zeigt der übergeordnete Guide KI-Transformation im B2B-Marketing: Von einzelnen Prompts zu verlässlichen Abläufen.
Unterscheidet Ablehnung, Fehlschlag und Unklarheit
Eine eindeutig abgelehnte Anfrage braucht eine Korrektur ihrer Voraussetzung. Ein vor der Ausführung gescheiterter Aufruf kann unter passenden Bedingungen wiederholt werden. Bei einem Timeout nach der Übermittlung bleibt dagegen offen, ob die Aktion durchgeführt wurde. Dokumentiert diese Unterschiede im Werkzeugvertrag und im Agentenstatus. Ein pauschaler Fehlercode verführt zu falschen Wiederholungen. Prüft auch asynchrone Aufträge: Angenommen bedeutet nicht abgeschlossen. Der nächste Schritt kann eine Statusabfrage statt einer erneuten Ausführung sein. Wenn die Integration keine sichere Unterscheidung erlaubt, braucht ihr einen ausdrücklich vorgesehenen manuellen Prüfweg. Mehr dazu im Leitfaden Agentenstatus dokumentieren: Was ist wirklich erledigt?.
Gebt einer fachlichen Aktion eine stabile Kennung
Verknüpft Wiederholungen derselben beabsichtigten Aktion mit einer eindeutigen Arbeitskennung. Definiert, welcher Inhalt dazu gehört und wie lange das Zielsystem die Kennung berücksichtigt. Eine neue zufällige Kennung bei jedem Versuch schützt nicht vor Duplikaten. Umgekehrt darf dieselbe Kennung nicht versehentlich für einen geänderten Auftrag verwendet werden. Der AWS-Leitfaden erläutert Idempotenz als Gestaltung sicherer Wiederholungen. Prüft für eure konkrete Schnittstelle, welche Zusagen tatsächlich gelten: Welche Nebenwirkungen werden erfasst, wie werden abweichende Inhalte behandelt und wann endet die Aufbewahrung früherer Ergebnisse?
Prüft den Zielzustand vor einer weiteren Änderung
Wenn ein Ausführungsbeleg fehlt, sucht anhand einer stabilen Kennung oder anderer zuverlässiger Merkmale nach dem erwarteten Ergebnis. Ein bloß ähnlicher Name kann bei mehreren Datensätzen unzureichend sein. Prüft Inhalt und Bezug, bevor ihr einen vorhandenen Eintrag als Beleg akzeptiert. Falls die erste Aktion stattgefunden hat, setzt den Ablauf mit diesem Ergebnis fort. Falls sie nachweislich nicht stattgefunden hat, kann eine Wiederholung erlaubt sein. Wenn beides unklar bleibt, gebt die Aufgabe mit den bisherigen Versuchen und offenen Fragen an einen zuständigen Menschen.
Begrenzt Wiederholungen und behandelt Folgewirkungen
Legt Anzahl, Warteverhalten und ein Ende für wiederholbare Aufrufe fest. Bei temporären Problemen können Abstände zwischen Versuchen sinnvoll sein; eine fehlende Berechtigung wird durch häufigeres Wiederholen nicht behoben. Achtet auf indirekte Nebenwirkungen wie Benachrichtigungen, Exporte oder Folgeaufträge. Ein unverändert gespeichertes Feld bedeutet nicht automatisch, dass der gesamte Vorgang nebenwirkungsfrei wiederholbar ist. Wenn ihr bereits ausgeführte Schritte zurücknehmen müsst, plant eine fachlich zulässige Gegenaktion. Ein Rückgängigmachen kann selbst Folgen haben und ist nicht mit einem einfachen technischen Zurücksetzen gleichzusetzen. Mehr dazu im Leitfaden Agenten begrenzen: Laufzeit, Werkzeugaufrufe und Abbruch.
Prüft ein fiktives doppelt angelegtes Ticket
Ein fiktiver Agent legt nach einem freigegebenen Rechercheauftrag ein internes Ticket an. Die Antwort geht verloren. Statt erneut ein Ticket zu erzeugen, fragt der Ablauf nach der Arbeitskennung des ursprünglichen Auftrags. Das bereits vorhandene Ticket wird gefunden und als Ergebnis übernommen. Dieses hypothetische Beispiel zeigt den gewünschten Wiederanlauf. Wenn das Ticketsystem keine solche Kennung unterstützt, braucht das Team eine andere verlässliche Abgleichmethode oder einen manuellen Ausnahmeweg. Die Annahme, dass ein Timeout sicher kein Ticket erzeugt hat, wäre keine belastbare Ersatzlösung.
Testet die kritischen Zeitpunkte gezielt
Simuliert einen Verbindungsabbruch vor der Ausführung, nach der Ausführung und vor dem Empfang ihrer Antwort. Ergänzt verzögerte Antworten, zwei gleichzeitige Versuche und dieselbe Kennung mit verändertem Inhalt. Das Prüfkriterium lautet nicht nur erfolgreicher zweiter Versuch. Prüft, ob die beabsichtigte fachliche Wirkung genau im vereinbarten Umfang vorliegt und keine unerwünschten Zusatzfolgen entstanden sind. Kontrolliert außerdem den gespeicherten Status und die Nachvollziehbarkeit für den Betrieb. Änderungen an Werkzeugen oder Zielsystemen können bisherige Annahmen über Wiederholbarkeit verändern und sollten diese Tests erneut auslösen.
INTERAKTIV / VOM LESEN ZUR ANWENDUNG
Drei Prüfpunkte für eure Umsetzung
Wähle einen Punkt und halte deinen persönlichen Lesefortschritt fest. Die Häkchen werden weder gespeichert noch übertragen und sind keine Bewertung eures Unternehmens.
PRÜFPUNKT 01
Prüft den Zielzustand vor einer weiteren Änderung
Wenn ein Ausführungsbeleg fehlt, sucht anhand einer stabilen Kennung oder anderer zuverlässiger Merkmale nach dem erwarteten Ergebnis.
Im Artikel vertiefen ↗PRÜFPUNKT 02
Begrenzt Wiederholungen und behandelt Folgewirkungen
Legt Anzahl, Warteverhalten und ein Ende für wiederholbare Aufrufe fest.
Im Artikel vertiefen ↗PRÜFPUNKT 03
Prüft ein fiktives doppelt angelegtes Ticket
Ein fiktiver Agent legt nach einem freigegebenen Rechercheauftrag ein internes Ticket an.
Im Artikel vertiefen ↗Häufige Fragen
Darf jeder fehlgeschlagene Aufruf wiederholt werden?
Nein. Ein unklarer Ausführungszustand verlangt zunächst Abgleich; eine fachliche Ablehnung verlangt eine korrigierte Voraussetzung.
Verhindert eine Kennung allein Duplikate?
Nur wenn die ausführende Schnittstelle sie mit definiertem Verhalten berücksichtigt.
Ist ein unverändertes Feld schon Idempotenz?
Nicht unbedingt. Benachrichtigungen oder andere Nebenwirkungen können bei jedem Aufruf erneut entstehen.
Wie lässt sich „Unterscheidet Ablehnung, Fehlschlag und Unklarheit“ praktisch umsetzen?
Eine eindeutig abgelehnte Anfrage braucht eine Korrektur ihrer Voraussetzung. Ein vor der Ausführung gescheiterter Aufruf kann unter passenden Bedingungen wiederholt werden. Bei einem Timeout nach der Übermittlung bleibt dagegen offen, ob die Aktion durchgeführt wurde.
Was ist bei „Gebt einer fachlichen Aktion eine stabile Kennung“ besonders wichtig?
Verknüpft Wiederholungen derselben beabsichtigten Aktion mit einer eindeutigen Arbeitskennung. Definiert, welcher Inhalt dazu gehört und wie lange das Zielsystem die Kennung berücksichtigt. Eine neue zufällige Kennung bei jedem Versuch schützt nicht vor Duplikaten.
