A customer taps submit twice. The network fails after a booking. The automation never receives confirmation and retries. These are ordinary events that create two appointments when the workflow lacks duplicate protection.
Give one intention a stable key
Create a unique ID for the business transaction. When the same command arrives again, the receiving system checks whether that ID was processed. If so, it returns the existing result instead of repeating the action.
| Action | Weak key | Better key |
|---|---|---|
| Appointment | Customer name | Request ID plus requested slot |
| Invoice | Amount | Order ID plus invoice type |
| Recipient | Case plus message type |
Do not ask the model to guarantee it
Whether two messages represent one transaction is a business rule. The agent may extract fields; deterministic code assigns the key and the destination enforces it. Financial correctness should not depend on probabilistic language judgement.
- Create the key before the first external write.
- Store the result under that same key.
- Log repeated attempts visibly.
- When status is unclear, query before resending.
An API outage and degraded mode makes this protection essential. Reconciliation then checks whether source and destination agree.
Sources
FAQ
What is idempotency?
The same request can be repeated without creating the same effect twice.
Does it prevent every duplicate booking?
Only when every write path uses the rule and a stable key.
Can an email address be the key?
Usually not. One person can legitimately start several transactions.
Where should the key be checked?
As close as possible to the system that stores or performs the final action.