By Scott Sumner | AI at Work | Published October 14, 2026

A business owner receives two matching purple envelopes from a mechanical delivery arm. Text: Sent perfectly. Twice.

An AI automation can send the right message twice without inventing a single word. Before you let an assistant create records or contact customers, decide what happens when the service responds too slowly and the workflow tries again.

Answer: Prevent duplicate AI actions by giving each intended operation a stable identifier, using the destination’s supported duplicate-prevention controls, and checking uncertain results before retrying. A timeout means confirmation is missing, not necessarily that the action failed.

This is an old software problem that becomes a business problem when an AI assistant can press Send. The useful requirement is simple: one approved action should not become two customer-facing actions just because a connection was interrupted.

Jump ahead

Why a timeout is not a failed action

Imagine an agency assistant creating a project in its delivery system. The system creates the project, but the reply never reaches the assistant. The assistant sees a timeout and tries the same create request again.

Now there are two projects. Both look legitimate. Each might trigger its own welcome email or task list.

That is a hypothetical example, not a client incident. It illustrates the distinction between an operation failing and its confirmation getting lost.

In Making retries safe with idempotent APIs, Amazon explains the same problem using infrastructure creation. Retrying a call can resolve a temporary fault, but repeating an operation with side effects can also create an unwanted second resource.

For a business owner, the resource might be an appointment, an invoice draft, a CRM deal or a customer message. The important question is not whether the AI can describe the error. It is whether the system can establish what actually happened.

I would want an automation to say “confirmation missing” rather than quietly turn uncertainty into another send.

How safe retries work

The technical term is idempotency. In this context, it means a repeated request for the same intended operation does not create an additional effect.

Stripe’s documentation gives a concrete example. Supported requests can carry an idempotency key so a connection error can be followed by a retry without creating a second object or performing the update twice.

Think of the key as a claim ticket for one job. If the reply goes missing, you present the same ticket again. You do not create a new ticket and ask the service to guess that you meant the old job.

The implementation belongs in the workflow or integration, not in the model’s memory. Store the identifier before the action. Keep it stable across retries of that action. Use a different identifier for a genuinely new action.

For example, resending the same approved project-creation request after a connection problem is a retry. Creating a second project for the same customer next month is new work. Deduplicating on the customer’s name alone would confuse the two.

Provider rules matter. Stripe’s current API v1 documentation says stored results include error responses after endpoint execution begins, and that keys may be removed once they are at least 24 hours old. Reusing a key after it has been pruned can generate a new request. Its API v2 behavior differs. A developer must check the actual API version and endpoint, not copy a generic “retry safely” instruction.

Nor does Stripe’s support prove that your email, booking or CRM tool offers the same protection. Ask what the destination actually accepts and how long its duplicate protection lasts.

Keep a record of each completed step

A business workflow usually crosses several systems. Creating the project, adding a task and sending a welcome email are separate effects. Protecting one does not automatically protect the others.

Keep a durable record for each intended action: its operation identifier, destination, status and returned external record ID. A confirmed completion should survive the assistant restarting or losing its conversation context.

Here is a small recovery example:

  • The project was created, and its external ID was saved.
  • The task was created, and its external ID was saved.
  • The email request timed out, so its delivery state is uncertain.
  • The recovery process checks that email action rather than recreating the project and task.

These are suggested design requirements, not claims that every automation platform already behaves this way. A workflow log that merely says “run failed” may not contain enough information to resume safely.

If the destination has no native duplicate-prevention mechanism, checking for an existing record can help with reconciliation. But a search followed by a create is not a complete guarantee: two workers might both search before either creates the record. Your implementer needs to account for concurrent runs, delayed visibility and destination-specific behavior.

When the outcome cannot be established, hold the uncertain step for review. Do not ask an AI model to infer that a customer probably did not receive the message because it cannot find a confirmation.

Test the awkward recovery path

A successful demonstration proves the normal route works once. It does not show what happens when the reply arrives late or the process restarts halfway through.

Ask the implementer to test recovery in a sandbox or with clearly marked test records. Do not deliberately interrupt a live payment or real customer communication as an experiment.

Start with these cases:

  1. The destination completes the action, but the caller loses the reply. The retry should not create a second effect.
  2. The same work is delivered twice. Two workers should not each carry out the same approved action.
  3. The process restarts after a completed step. It should recover the saved external ID rather than start the whole workflow over.
  4. A genuinely new request resembles the previous one. Duplicate protection should not suppress legitimate repeat business.

Inspect the destination records, not just the automation’s success message. Count the actual test projects, tasks or messages and connect each to its intended operation. Keep the results as a repeatable test when the workflow changes.

This complements AI regression testing, but it checks a different failure: repeated external effects rather than a worse answer. Better prompting alone does not solve it.

What to ask your automation provider

The most useful question is: “Show me what happens if the action succeeds but your system never gets the confirmation.”

A good answer should identify the destination’s protections, the saved operation record, how uncertain outcomes are reconciled and when a person must intervene. “It retries automatically” is only the beginning of that answer.

This applies whether an AI assistant chooses the action or a conventional rule triggers it. AI makes more kinds of work possible, but the integration still needs to handle ordinary network uncertainty.

If a website inquiry starts the workflow, check both sides. Following a form submission to the team tells you whether the inquiry arrived. Recovery testing tells you whether one inquiry can accidentally become two sets of follow-up actions.

Start with one customer-facing automation and its first irreversible step. Ask your implementer to demonstrate recovery using test data. If you need help framing the website-to-business workflow, contact Sumner Digital through Sumner.ai with the systems involved and the action you want to automate.

Sources

Primary documentation checked October 14, 2026. This is evergreen implementation analysis, not a new product announcement.