A failed automation: can you retry without duplicating the work?

A retry is another technical attempt to carry out an intended business action. It need not mean another customer message. The distinction matters because a timeout only tells you that the caller stopped waiting. The destination may have completed its work. A better AI prompt cannot resolve that uncertainty or prevent an external system from creating a duplicate.

Start with evidence of what already happened

Consider a fictional example that has not been executed: a campaign request should create one CRM follow-up task, then send an approved email. The CRM saves the task, but its response is lost. Restarting the entire workflow could create another task and eventually another email.

The recovery decision should begin with a reliable lookup or reference to the existing task. If its creation is confirmed, store the destination's task ID and inspect the email stage separately. An accepted send request is not proof that the email was delivered. Continue only the pending stage. Without confirmation or a documented protected retry, hold the operation for its owner.

One concrete timing example comes from Shopify Flow custom action endpoints: they wait up to ten seconds for a response, close the connection and resend later. The payload's action_run_id can help a receiver recognise the same run. This does not make the receiver's work automatically duplicate-safe, and the ten-second limit does not describe other CRM, webhook or AI systems.

Give the business operation a stable identity

A webhook is an automatic notification of an event. Receiving one twice does not necessarily mean the business requested two actions. Shopify documents repeated webhook deliveries; separate subscriptions can also report the same merchant action with different webhook IDs. Delivery identity is therefore useful evidence, but it is not always the identity of the intended operation. Equally, distinct legitimate actions must remain distinct.

Agree a stable operation ID that contains no customer personal information. Every retry of that operation keeps this ID and receives a separate attempt ID. A deliberately new action needs its own identity and approval. Resolve any earlier uncertain operation before replacing it.

Keep a durable record of the operation ID, originating event and source, intended action, approved data and content with their version, current state, attempt count, destination reference, timestamps, owner and next decision. This example record needs no sensitive customer details. It should let an operator explain what is known and what must happen next.

Ask how the destination prevents a second effect

Idempotency means that repeating the same intended operation does not add another effect, within a system's documented conditions. Check supported actions, retention and errors. A documented protected retry uses the same key and approved parameters within the valid window.

Stripe illustrates why those details matter, without making this a payment workflow. For supported POST requests, the same idempotency key returns the first saved status and response body, including errors. Changed parameters cause an error. Keys may be removed after at least 24 hours; reuse after removal becomes a new request. Results are saved once endpoint execution starts, while validation failures and concurrent conflicts follow different rules. These conditions belong to Stripe, not every integration.

A local check for an existing success record is insufficient: two workers can both pass it, or the external action can finish before local success is saved. Ask for an atomic claim or unique constraint locally, plus destination protection or reconciliation. Atomic means one indivisible reservation. Neither recording an ID nor logging success afterwards guarantees safe recovery. Where the destination cannot confirm or deduplicate, stop automatic resending and assign review.

Preserve the approved action when work resumes

Approval is a decision about content and action, not proof that execution can safely repeat. LangGraph, for example, restarts the relevant node, or workflow step, from the beginning when execution resumes after an interrupt() pause; external changes made before that pause may repeat. Its documentation recommends idempotent operations or separating or moving those changes. Separating approval and execution helps, but cannot cover every later failure by itself.

For a task-then-email workflow, retain evidence for both stages and replay only what remains unresolved under the recovery rules. Keep the approved data and content: regenerating model output may change the message. Changed content requires another review. AI can draft content or classify an error; fixed workflow rules, independent of model judgment, and a human owner should govern consequential actions.

Make the acceptance criteria visible

Before enabling automatic recovery, agree the following illustrative cases with your implementer. These are proposed acceptance criteria, not results of tests performed or a promise of exactly-once execution.

1. Ordinary success: confirm the intended external action and store its reference.
2. Duplicate event: reuse evidence and allow one intended external action where duplicate protection applies.
3. Timeout after destination success: recover the existing result using evidence or documented protection; otherwise hold for review.
4. Two concurrent attempts: verify that local reservation and destination protection prevent a second intended effect in the protected case.
5. Resume after approval: preserve the approved content and parameters, and skip completed stages.
6. Replay after the destination's retention window: reconcile again or hold; do not assume expired protection still applies.

Count events, technical attempts, confirmed external effects and unresolved operations separately. Measure operator recovery time. Set retry limits and increasing delays according to each destination's documented policy; avoid unlimited retries or a universal attempt count.

Scope one workflow before expanding

MindVerve's automation service maps triggers, inputs, outputs, owners, missing-data and failure rules, test cases and operating instructions. AI Workflow Launch configures one agreed workflow, including tool selection, representative and failure tests, reusable briefs or prompts, documentation, training and handover. Licences, API usage and extra integrations are excluded; ongoing maintenance is separate.