Ein Kunde sagt am Telefon: „Ja, Dienstag um 14 Uhr passt.“ Der Agent sendet die Buchung ans Kalendersystem. Die API antwortet nicht rechtzeitig. Nach fünf Sekunden kommt ein Timeout.
Hat die Buchung stattgefunden oder nicht?
Der Agent weiss es nicht und versucht es noch einmal. Diesmal antwortet die API: Erfolg. Später stehen im Kalender zwei Termine um 14 Uhr und 14:15 Uhr, weil der erste Request ebenfalls durchging.
Das Modell hat den Kunden korrekt verstanden. Der Termin war korrekt. Selbst der Wiederholungsversuch war technisch nachvollziehbar. Trotzdem ist das Geschäftsergebnis falsch.
Idempotenz löst genau diese Klasse von Fehlern: Dieselbe beabsichtigte Operation kann erneut angefragt werden, ohne dass sie dadurch mehrfach ausgeführt wird.
Idempotenz bei AI-Agenten beginnt mit dem Geschäftsvorgang
Der Fehler vieler Workflows ist, dass jeder API-Call als neues Ereignis behandelt wird. Für den Betrieb sind aber zwei HTTP-Requests nicht zwingend zwei Geschäftsvorgänge.
„Buche Kunde 4711 am 17. August um 14 Uhr für Reifenwechsel“ ist eine Operation. Wenn dieser Vorgang wegen Timeout drei Mal gesendet wird, sollte das Zielsystem oder eine vorgelagerte Schicht erkennen: gleiche Operation, kein zweites Ergebnis.
Stripe dokumentiert Idempotenz Keys genau für dieses Muster bei API-Requests: Ein Client versieht eine Operation mit einem eindeutigen Schlüssel, sodass ein Wiederholungsversuch nicht dieselbe Aktion mehrfach erzeugt. AWS weist bei Saga-Workflows ebenfalls darauf hin, dass Teilnehmer idempotent sein sollten, weil Schritte nach Fehlern erneut ausgeführt werden können.
Bestätigter Fakt: Idempotenz Keys und idempotente Operationen sind etablierte Muster, um sichere Wiederholungen zu ermöglichen.
Empfehlung: Identifizieren Sie nicht den Request, sondern die beabsichtigte Geschäftsaktion.
Wo doppelte Aktionen in Agenten wirklich herkommen
Timeouts sind nur eine Quelle.
Ein Nutzer klickt zweimal auf „Bestätigen“. Ein Voice-Agent und ein WhatsApp-Agent bearbeiten dieselbe Anfrage parallel. Ein Webhook wird erneut geliefert. Ein Warteschlange-Worker crasht nach erfolgreichem Write, aber bevor er den Job als abgeschlossen markiert. Ein Mitarbeiter erledigt den Fall manuell und der Agent spielt ihn später erneut ab.
Bei AI-Agenten kommt noch ein semantischer Punkt hinzu: Zwei unterschiedlich formulierte Sätze können dieselbe Geschäftsabsicht ausdrücken. „Nimm Dienstag um zwei“ und „Ja, der Dienstag-Termin passt“ dürfen nicht automatisch als zwei Buchungen interpretiert werden.
Deshalb ist eine zufällige neue UUID bei jedem Agentenschritt nicht genug. Wenn jeder Wiederholungsversuch einen neuen Key bekommt, sieht das System jede Wiederholung als neue Operation.
Der Key muss möglichst stabil an etwas Geschäftliches gebunden sein: Vorgangs-ID plus Aktion, Buchungsanfrage plus Slot und Kunde, Rechnung plus Zahlungsschritt oder Ticket plus Statuswechsel.
Ein einfacher Idempotenz-Flow
Für einen kleinen Workflow kann die Logik überschaubar bleiben.
- Geschäftsoperation definieren. Was genau darf nur einmal passieren?
- Stabilen Operation-Key bilden. Er muss über Retries hinweg gleich bleiben und darf nicht bei jeder Modellantwort neu erzeugt werden.
- Vor Ausführung prüfen. Existiert für diesen Key bereits
processing,successoder ein bestätigtes Zielobjekt? - Ergebnis speichern. Bei Erfolg Result-ID und relevanten Zielzustand mit dem Key verbinden.
- Wiederholungsversuche bewusst behandeln. Bei Timeout zuerst Status prüfen; nicht automatisch „noch einmal neu“ ausführen.
- Unklare Fälle in Ausnahmefall Warteschlange geben. Wenn nicht feststeht, ob der erste Call durchging, braucht es Verifikation statt blindem Duplikat.
Das Zielsystem selbst ist der beste Ort für Idempotenz, wenn es entsprechende Keys unterstützt. Falls nicht, kann eine Orchestrierungsschicht den Schutz übernehmen. Aber sie muss bei Abstürzen und Parallelität zuverlässig sein.
Cross-Channel macht die Sache schwieriger
Der Kunde ruft an, bekommt keine sofortige Bestätigung und schreibt zwei Minuten später auf WhatsApp. Der Voice-Agent und der Chatbot erzeugen jeweils eine „neue“ Anfrage.
Technisch sind es zwei Sessions. Geschäftlich kann es derselbe Terminwunsch sein.
Hier reicht ein API-Idempotenz-Key allein nicht. Sie brauchen zusätzlich Deduplication-Regeln und bei Unsicherheit menschliche Prüfung. Kunde, Zeitfenster, Leistung, Standort und kurzer Zeitraum können Hinweise liefern. Eine aggressive automatische Zusammenführung kann aber ebenfalls Fehler erzeugen, wenn tatsächlich zwei Fahrzeuge oder zwei Termine gemeint sind.
Beispiel, keine universelle Regel: Zwei identische Terminwünsche derselben Kundennummer innerhalb von drei Minuten können als potenzielles Duplikat markiert werden. Der zweite Vorgang wird nicht automatisch gelöscht, sondern geprüft oder mit dem vorhandenen Status verknüpft.
Die menschliche Übergabe ist besser als ein System, das aus Angst vor Duplikaten echte zweite Aufträge verschluckt.
Minimaler Pilot: provozieren Sie Retries
Testen Sie den Happy Path erst nach den unangenehmen Fällen. Lassen Sie die API beim ersten Request bewusst nach dem Write einen Timeout liefern. Senden Sie denselben Webhook zweimal. Starten Sie zwei Worker parallel mit demselben Job. Bearbeiten Sie einen Warteschlange-Fall manuell und lassen Sie danach den Agenten wieder anlaufen.
Messen Sie Duplikate pro 1'000 Operationen, Anteil der Retries mit demselben Operation-Key, Fälle mit unbekanntem Commit-Status, Zeit zur Auflösung von Duplicate-Ausnahmefalls, False-Deduplication-Rate und Anteil externer Aktionen, deren Result-ID am ursprünglichen Vorgang gespeichert ist.
Eine Null bei echten Duplikaten ist ein gutes Betriebsziel, aber kein Versprechen, dass jede denkbare Race Condition verschwunden ist. Tests müssen mit neuen Integrationen und Workflow-Änderungen wiederholt werden.
AI-Agenten brauchen Idempotenz nicht, weil Modelle unzuverlässig wären, sondern weil Netzwerke, Nutzer und verteilte Systeme Wiederholungen erzeugen. Wenn dieselbe Absicht nur einmal echte Wirkung haben darf, muss die technische Architektur das auch verstehen.
Ein reduzierter Modus bei API-Ausfall braucht diese Absicherung besonders. Danach zeigt Reconciliation, ob Quelle und Ziel wirklich übereinstimmen.
Quellen
FAQ
Ist Idempotenz nur für Zahlungen wichtig?
Nein. Termine, Bestellungen, E-Mails, CRM-Updates und Tickets können ebenfalls durch Retries doppelt entstehen.
Reicht eine zufällige UUID pro API-Request?
Nein, wenn bei jedem Wiederholungsversuch eine neue UUID entsteht. Wiederholungen derselben Geschäftsvorgang brauchen denselben stabilen Schlüssel.
Was tun, wenn die Ziel-API keine Idempotenz Keys unterstützt?
Eine Orchestrierungs- oder Datenbankschicht kann den Schutz übernehmen, muss aber Parallelität, Status und Fehler sauber behandeln.
Kann man Cross-Channel-Duplikate komplett automatisch erkennen?
Nicht immer. Ähnliche Anfragen können echte zweite Vorgänge sein. Unsichere Fälle gehören in eine Ausnahmefall Warteschlange.
Ist ein Wiederholungsversuch bei Timeout falsch?
Nein. Ein Wiederholungsversuch ist normal. Problematisch ist ein Wiederholungsversuch ohne Wissen darüber, ob die ursprüngliche Aktion bereits wirksam wurde.