AI Agents Must Not Turn Retries into Duplicate Business Actions

The agent did not misunderstand the request. It booked the same job twice because the first reply went missing.

A missing response is not a failed job

Your AI assistant books an engineer, but the booking service takes too long to reply. The assistant tries again. Two appointments now exist for one customer, and the dashboard reports a successful recovery. Nothing in that sequence requires a hallucination. The model can understand the request perfectly while the surrounding software repeats the business action.

This is why reliability should be discussed in terms of outcomes, not just successful tool calls. A timeout means the caller did not receive a response within its waiting period. It does not establish whether the receiving system rejected the request, is still processing it, or completed it before the connection broke. Those possibilities require different responses.

Consider an illustrative plumbing business taking bookings from voicemail. The intended outcome is one visit for the customer's reported problem. Transcribing the voicemail twice is inconvenient. Creating two chargeable visits is materially different. Your workflow must distinguish harmless repeated processing from repeated commitments involving money, customers or staff time.

The October 2026 iTechGuides retry-safety guide describes precisely this ambiguity and explains why repeated attempts need a stable operation identity. This is an engineering explanation, not evidence of a particular failure rate across businesses. There is no useful universal percentage to quote for your own booking process.

What this means in practice is simple: ask your supplier what happens when the external system finishes the job but its reply disappears. Do not accept a demonstration that merely disconnects the network before anything starts. You need to see the awkward middle ground, with the first action already committed and the assistant still uncertain about the result.

A timeout tells you that the answer is missing, not that the action never happened.

Give the business action a durable identity

The useful technical term is idempotency. In everyday language, repeating the same intended operation should not create an additional business effect. That does not mean banning legitimate repeat purchases, repeat visits or follow-up messages. It means recognising the difference between continuing one request and authorising another.

Start with a durable business reference created before execution. For our illustrative booking, that could identify the accepted service request, the booking action and the relevant business account. Keep that identity when a worker restarts, a network retry occurs or a person presses a recovery button. A new identifier for every attempt tells the receiving system that every attempt is new work.

The identifier should be generated and stored by the application, not reconstructed from whatever wording the model happens to produce later. Nor should it rely only on the customer's name or message text. One customer can legitimately request two identical services. Treating matching sentences as proof of duplication can suppress valid work as easily as it prevents mistakes.

Persist the consequential details alongside the identity: target account, selected service, intended appointment and relevant approval. If those details change, raise a conflict or create a deliberately authorised new operation after establishing the original outcome. Do not quietly change the appointment and reuse the old identity as though nothing material had changed.

Codesprint Consulting's 15 October explanation of agent idempotency makes the important distinction between a request attempt and a business operation. Its implementation suggestions are guidance rather than independently verified client results. The management takeaway is to demand continuity across recovery paths, not merely an idempotency field visible in one successful API call.

Your acceptance evidence should show the same operation reference surviving a retry and a restart. Someone unfamiliar with the model's conversation should still be able to establish what was requested, which attempts occurred and which external record represents the result.

One customer request can have several execution attempts without becoming several authorised jobs.

Check the receiving system's actual promise

A local duplicate register is useful, but it does not automatically control an external provider. Your application can record that it intends to create a booking, call the booking service, and crash before saving the returned appointment number. On restart, the local record alone cannot prove whether the remote appointment exists.

Where the provider supports idempotency, pass the same operation key through to the supported endpoint. Then check the scope and lifetime of that protection. Is it tied to a particular account, API version or operation? What happens when two requests arrive together? What happens after the provider forgets the original key? Those are contract questions, not details to leave until an incident.

Stripe provides a concrete example. Its API v1 documentation says keys may be removed after they are at least 24 hours old. Reusing a key after it has been pruned can generate a new request. It also compares incoming parameters with the original request and rejects mismatches. The same documentation distinguishes API v2 behaviour, so a blanket statement about all Stripe retries would be misleading.

That 24-hour figure is not a recommended recovery window for every business system. It demonstrates why a supplier's promise of permanent duplicate prevention needs scrutiny. A workflow that resumes several days later may need a fresh status lookup and operator reconciliation rather than another write, even when it still holds the old identifier.

DigitalOcean's Action Gateway documentation, verified on 13 October 2026 describes bounded retries and provider idempotency according to each tool's supported policy. That qualification matters. A gateway can organise enforcement, but its presence does not establish that every connected booking, email or payment tool offers identical guarantees.

Before commissioning custom machinery, inspect what your existing platform and provider SDK already support. Use maintained facilities where they fit, then document any remaining gap. Buying another orchestration layer without examining the downstream contract can simply move the uncertainty.

Stripe API v1 keys may be removed after at least 24 hours: duplicate protection has a defined boundary.

Approval and duplicate prevention solve different problems

The strongest counterargument is usually that a person approves every important action. That is valuable, but approval answers whether an operation is allowed. It does not by itself establish whether the approved operation already happened. One approved refund can still be submitted twice if separate execution attempts are treated as separate refunds.

Keep approval attached to the reviewed operation and its consequential details. The amount, recipient, account and purpose should not drift during recovery. A new model response must not silently reinterpret yesterday's approval as permission for a replacement action while the first action remains unresolved. Equally, a duplicate-prevention mechanism must not authorise an operation that never had permission.

This is distinct from giving agents task-scoped permissions. Permissions limit what a tool may do. Operation identity limits repeated effects from one intended request. Both are needed when software can create obligations outside the conversation.

What this means in practice is that the operator screen should separate confirmed success, confirmed rejection, work still in progress and outcome unknown. An ambiguous timeout should not be painted as a definite failure with a bright retry button. Show the business reference and any provider identifier, and make the recovery route explicit.

For a business processing personal data, duplicate records can also become an accuracy issue if they misleadingly represent what a customer ordered, owes or agreed to. The ICO accuracy guidance says organisations should take reasonable steps to avoid incorrect or misleading personal data and correct inaccuracies. Its page is under review following the Data (Use and Access) Act, so check current guidance for your circumstances.

That does not mean UK GDPR prescribes a particular idempotency implementation. It means your records and correction process still matter when automation creates a misleading duplicate. Avoid putting customer email addresses or other personal details directly into operation keys; keep correlation useful without unnecessarily spreading personal data through logs.

Human approval permits the action; it does not prove that the action has not already happened.

Test recovery where a polished demonstration stops

A useful acceptance exercise is short enough for an owner to watch and specific enough that an engineer cannot substitute a happy-path demonstration. Use a sandbox or controlled test environment. Define the expected business record before testing, and count actual external outcomes afterwards rather than trusting the assistant's summary.

First, let the external system create the appointment, then deliberately lose its response. Resume the workflow. The expected outcome is one appointment, with its identifier recovered or the uncertainty clearly escalated. A second appointment followed by a reassuring message is a failure, even if both API requests technically succeeded.

Second, start two workers against the same operation at the same time. A simple check that searches for an existing record and then creates one can allow both workers through before either sees the other's write. Ask for an atomic claim or equivalent supported control, and verify the external effect rather than assuming the local lock covers every system.

Third, restart the application after the provider commits but before local success is stored. Fourth, change a consequential parameter while keeping the original operation identity. The former should recover or reconcile the existing outcome; the latter should surface a conflict instead of silently rewriting the meaning of an approved request.

Finally, test a delayed recovery beyond the documented provider protection window, then submit two genuinely separate but identical customer requests. The first must not blindly repeat an uncertain write. The second must create two legitimate outcomes. A system that prevents duplication by dropping real orders is not reliable either.

Record these as your own acceptance scenarios, not as an industry certification. Keep screenshots or test logs showing operation references, provider records and final counts. Set a stop condition for unresolved outcomes and name the person who owns reconciliation. The value lies in making the difficult recovery behaviour observable before customers encounter it.

Count external appointments, payments or messages, not the assistant's claims of successful recovery.

Start with the action that would hurt to repeat

You do not need to rebuild every workflow before using AI. Begin by listing tools that change something outside the assistant: create an order, send a message, book an appointment, issue a refund or update a customer account. Separate them from read-only searches and draft preparation. Then identify which repeated effects would be costly, confusing or difficult to reverse.

For each higher-consequence action, write a small recovery contract. Name the business operation, its stable identifier, the downstream provider's duplicate-prevention support, the protection window and the route for checking status. Add the person responsible when the result remains unknown. If the supplier cannot explain those fields, keep that action supervised or outside the autonomous workflow until it can.

Measure the outcome you actually care about. Track duplicate external effects, unresolved operations, time spent reconciling them and legitimate requests incorrectly blocked as duplicates. Keep ordinary retries as a diagnostic measure rather than treating every retry as a business failure. Some retries are exactly how a resilient service completes the original work.

An illustrative commercial check helps: if one duplicate engineer booking consumes a morning and requires a customer apology, preventing it may matter more than shaving seconds off a model response. That is not a claim about typical losses or guaranteed savings. Estimate the consequences using your own appointment values, cancellation rules and staff costs before assigning a budget.

Also resist claims of universal exactly-once execution. One database can enforce a transaction within its own boundary; several independent providers do not automatically share that transaction. Good engineering states the boundary honestly, combines provider protections with durable records, and makes unresolved cases visible rather than pretending uncertainty has disappeared.

The best first improvement may be entirely conventional software work around an existing AI tool. That is fine. Your customers do not benefit from a more impressive model if it books the same visit twice. Before expanding autonomy, make sure one intended action remains one intended action when the network, the worker or the surrounding service fails.

The right recovery contract is usually more valuable than another instruction telling the model to be careful.