Prevent Duplicate Actions in AI Automation: A NZ Checklist
To prevent duplicate actions in AI automation, give each intended action a durable identity, preserve it across retries, check the receiving system's retry rules, and reconcile uncertain outcomes before replaying work. Human approval controls whether an action is authorised; duplicate-execution controls help stop that approved action happening again.
For a New Zealand business, the practical question is not whether an agent can create a record. It is what happens when the record was created but the confirmation never came back. Use this checklist when reviewing a supplier's implementation plan.
Why can one instruction produce two actions?
A worker sends a request, the receiving system acts, and the connection drops before confirmation returns. The worker sees a timeout. If it treats that as proof of failure and starts again, it may repeat the action.
Repeated webhook deliveries, overlapping workers, manual restarts, and replayed queues create similar risks. This is different from CRM data cleanup: clean customer records cannot prevent one approved task being executed twice.
XZ BYTECORE's NZ automation page identifies retries and partial failures as duplicate-action risks. That is relevant service-provider context, not proof that a particular implementation prevents them.
Keep one action separate from its attempts
An operation ID identifies the business intention. An attempt ID identifies one try. A provider reference identifies the receiving system's result. Keep all three rather than treating every restarted run as new work.
Idempotency means repeating an operation does not repeat its intended effect under the system's defined rules. It is not a universal promise of exactly-once execution across connected tools.
Two intentionally identical orders still need separate operation identities. Conversely, retrying one order must not invent a new identity. Use opaque references, not names or email addresses, in keys that may appear in logs.
Five controls to ask your implementer to demonstrate
1. Save the intended action before execution
Persist its operation ID, action type, approved details, and current state before calling another system. A restart must reload that record. A prompt telling the model to remember is not durable storage.
Ask how two workers are prevented from claiming the same action independently. A database uniqueness rule and controlled execution claim can help; simply checking whether a record exists can race when workers check simultaneously.
2. Bind approval to the actual details
Record what was approved: recipient, amount and currency where relevant, message version, or target record. If material details change, stop for a fresh decision rather than borrowing the earlier approval.
Keep emails, DMs, booking handoffs, public publishing, and sensitive CRM or financial changes behind human review. Approval is not duplicate protection: one valid approval could otherwise be consumed by several restarted workers.
3. Check the receiving system's retry contract
Where supported, reuse the same provider idempotency key for retries of the same action. Verify supported endpoints, parameter-matching rules, key scope, retention, and response behaviour. Do not add the attempt number to that key.
Stripe's idempotent-request documentation is a provider-specific example. For API v1, it describes saving the first result after execution begins, including error responses, and possible key removal after at least 24 hours. API v2 has different retry behaviour. Neither is a rule for every CRM, email service, or accounting tool.
4. Treat a missing response as unresolved
A timeout does not establish whether the action happened. Preserve the original identity, then use documented lookup or safe-retry mechanisms to reconcile the result. If evidence remains inconclusive, hold the action for investigation.
Do not generate a fresh key to get past an error, or assume an empty search immediately proves absence. Check lookup delays and provider limits. Where no reliable recovery mechanism exists, manual reconciliation may be the safest boundary.
5. Control restarts and downstream replay
A repeated completion event must not trigger a second customer message. Track event identities where available and give each downstream action its own durable identity, linked to its cause.
PADISO's technical idempotency guide covers operation identity, approval binding, and recovery tests. Ask your supplier to explain these controls in your workflow, including who can release held work and what happens beyond the provider's key-retention window.
Use a control sheet for each consequential action
Do not accept a single tick saying “retries handled”. Record the decision at each boundary.
| Situation | Evidence to check | Safe next decision |
|---|---|---|
| Confirmation received | Matching operation and provider reference | Save the confirmed result; suppress repeat execution |
| Request timed out | Original identity and provider-side status | Reconcile or hold; do not assume failure |
| Same identity, changed details | Approved version versus requested version | Reject the mismatch and obtain fresh approval |
| Completion event delivered again | Event record and downstream action state | Resume incomplete work without repeating effects |
| Recovery window expired | Provider retention rules and authoritative records | Escalate before any replay |
Keep this alongside your workflow exception rules and AI agent audit trail. The sheet records control requirements; it is not evidence those controls already work.
Test an uncertain outcome, not just a clean demo
Consider this synthetic example, not a client incident: an approved enquiry creates a follow-up task, but the worker stops before saving the task ID. On restart, it must inspect the original operation and reconcile the task—not create another automatically.
Ask the implementer to test, in an authorised sandbox:
- A lost response after the receiving system accepted an action.
- Two workers attempting the same operation together.
- Changed details submitted under an existing identity.
- A repeated completion event and a delayed restart.
Check resulting records and state transitions, not only a green test message. Confirm who investigates unresolved outcomes. Do not inject faults into live payments, bookings, or customer communications without separately agreed scope and approval.
Prove delivery and prevent repetition separately
The website enquiry-delivery checklist checks whether work reaches your business. This guide checks whether an intended action repeats. A missing confirmation sits between those problems: locate the existing result before deciding to replay it.
AI can summarise unresolved operations for review. Durable IDs, uniqueness checks, and provider rules should sit in the execution system, not depend on the model's judgement. Sometimes fixed automation is enough.
Frequently asked questions
Why does AI automation create duplicate actions?
Retries, repeated events, overlapping workers, and restarts can repeat an action when the workflow loses track of the original intention. A timeout is particularly risky because the receiving system may already have completed the request.
What is an idempotency key?
It is a reference a supporting provider uses to recognise repeated requests for the same operation. Its protection depends on that provider's endpoint, parameters, retention, and retry rules. Not every tool supports one.
Does human approval prevent duplicate execution?
No. Approval establishes permission for specified details. Execution controls must also preserve operation identity, coordinate workers, and detect repeats. Changed material details require a new decision rather than reuse of an old approval.
Should an agent retry after a timeout?
Not blindly. Reconcile the original operation using documented provider mechanisms. A retry may be appropriate within supported rules; an uncertain consequential outcome should remain held when reliable evidence is unavailable.
Map the controls before connecting more tools
Use the NZ$1,000 AI Agent Assessment to map actions, approvals, exceptions, and success criteria before implementation. Bring one workflow and ask where repeated execution would matter.
The Assessment includes two 45-minute Zoom sessions and a report before the second call, with no obligation to buy implementation or management. It does not include implementation, financial assurance, or production fault-injection testing.