Der Kunde tippt zweimal auf Senden. Das Netz bricht nach der Buchung ab. Die Automation erhält keine Bestätigung und versucht es nochmals. Drei völlig normale Situationen, aus denen ohne Schutz zwei Termine entstehen.
Eine Absicht bekommt eine feste Kennung
Für jeden Geschäftsvorgang erzeugt das System eine eindeutige ID. Kommt derselbe Auftrag nochmals, prüft die Zielseite: wurde diese ID schon verarbeitet? Falls ja, liefert sie das bestehende Ergebnis statt eine zweite Aktion auszuführen.
| Aktion | Schlechter Schlüssel | Besserer Schlüssel |
|---|---|---|
| Termin | Name des Kunden | Anfrage-ID plus gewünschter Slot |
| Rechnung | Betrag | Auftrags-ID plus Rechnungsart |
| Empfänger | Vorgang plus Nachrichtentyp |
Der AI-Agent entscheidet das nicht allein
Ob zwei Nachrichten dieselbe Absicht meinen, ist eine Geschäftsregel. Der Agent darf Daten extrahieren; der technische Ablauf vergibt die ID und das Zielsystem setzt sie durch. So hängt finanzielle Korrektheit nicht von probabilistischem Textverständnis ab.
- ID vor dem ersten externen Schreibvorgang erzeugen.
- Ergebnis unter derselben ID speichern.
- Wiederholungen sichtbar protokollieren.
- Bei unklarem Status erst abfragen, dann erneut senden.
Ein reduzierter Modus bei API-Ausfall braucht diese Absicherung besonders. Danach zeigt Reconciliation, ob Quelle und Ziel wirklich übereinstimmen.
Quellen
FAQ
Was ist Idempotenz?
Dieselbe Anfrage kann wiederholt werden, ohne dieselbe Wirkung ein zweites Mal auszulösen.
Verhindert das jeden Doppeltermin?
Nur wenn alle Schreibwege dieselbe Regel und einen stabilen Schlüssel verwenden.
Kann die E-Mail-Adresse der Schlüssel sein?
Meist nicht. Dieselbe Person kann mehrere legitime Vorgänge starten.
Wo wird der Schlüssel geprüft?
Möglichst im System, das die endgültige Aktion speichert oder ausführt.