croissant
Home / Blog / Operations

Preventing duplicate emails and tasks in AI automations

Croissant editorial team · · 2 min read

Understand why retries cause duplicates and how to build workflows that recover without repeating external actions.

A repeated action is often a recovery problem rather than an AI reasoning problem. A network timeout can leave a workflow unsure whether an email was accepted or a task was created. Repeating the action blindly may produce a duplicate while the system appears to be fixing itself.

Give the work a stable identity

Use an identifier tied to the business event, such as a message or submission identifier. Store it with the resulting action. A new random identifier on every retry does not establish that two attempts represent the same work.

Record intent and outcome separately

Track that an action is pending before sending it, then record the result when the receiving system confirms it. Some failures remain ambiguous. Keep those cases visible for reconciliation instead of automatically treating them as either completed or safe to repeat.

Example: an email send times out

The mail server may accept a message just before the connection drops. Your workflow receives a timeout and cannot safely conclude that nothing was sent. Record the attempt as uncertain, retain the message identifier, and reconcile against available evidence before considering another send. If the destination supports an idempotency mechanism, use it according to that system’s documented behaviour. Do not assume that generating a fresh request identifier makes a second attempt harmless.

Test the uncomfortable middle

Test an interruption after the destination accepts an action but before the workflow records success. Check that a resumed run looks for existing evidence before sending again. Also test repeated input delivery, because the same event can arrive more than once even when your own workflow never retries.

A reality check before you hit run

Stripe documents idempotency keys for supported API requests. They are an implementation feature, not something a prompt can promise. [1]

HubSpot documents deduplication rules and API-specific exceptions. Test the write path your agent actually uses. [2]

Implementation checklist

  • Use an event identifier across retries.
  • Record pending and confirmed outcomes.
  • Do not blindly retry an ambiguous external send.
  • Test crashes and repeated event delivery.

The sources behind the sauce.

Primary research and official documentation behind the cited points. The workflow examples and checklists are Croissant’s own guidance.

  1. Stripe API documentation — Idempotent requests
  2. HubSpot documentation — Deduplicate records