Before You Retry, Ask What Already Happened

The screen says the request failed. The business action may already have happened.

That distinction matters when an AI workflow can create orders, send messages or change records. A missing acknowledgement is not the same thing as evidence that nothing changed. I want the next decision to depend on the action's state, not on how impatient the retry button makes us feel.

AWS's Builders' Library explains this boundary directly: remote calls can have side effects even when the caller sees a timeout or failure. Retrying can also add load to a service that is already struggling.¹

One order, two different uncertainties

Here is a synthetic example. An AI-assisted purchasing workflow sends an approved order to a supplier. The connection times out before confirmation reaches the business. The supplier might have created the order, rejected it, or still be processing it.

The assistant cannot resolve those possibilities merely by generating a confident explanation. If it submits a new order, the business could receive two shipments. If it waits indefinitely, the business may miss a real purchasing need. Neither outcome follows from the timeout alone.

I would first preserve the original request reference, the attempted action, and the evidence currently available. Then I would ask the system owner which supported status check or reconciliation path can establish what happened. An absent item in one screen may not settle the question if records are still updating.

Use the Retry Decision Card

1. Could the first attempt have changed the business? If it only reads information, check the documented behavior and retry policy. If it can send, create, charge or modify, treat completion as a question to verify.
2. Can we inspect the original action? Use its reference and the approved status source. If completion is confirmed, reconcile the local record rather than repeating the action.
3. Does the service explicitly protect this retry? Confirm the same logical request, compatible parameters, supported request identity and valid retention window. A field called “request ID” is not sufficient evidence.
4. Is another attempt still authorized and useful? Respect the original scope, time limit and attempt budget. Do not keep repeating a permanent validation error or add a new retry loop around one already managed elsewhere.
5. Who owns an unresolved state? If the contract or outcome is unknown, pause further side effects and route the evidence to the responsible operator.

The three outcomes are deliberately plain: inspect first when the effect is uncertain; retry within the documented contract when that protection and authority are established; pause for the owner when they are not. Pausing should create a visible, owned case, not silent abandonment.

The technical term often involved is idempotency: repeated attempts are handled so they do not create an additional business effect under a defined contract. AWS describes client request identifiers, parameter checks and service-specific retention. Those details are properties to verify, not capabilities every connector automatically inherits.²

Stripe supplies a useful concrete boundary. Its API v1 documentation says the same key can return the first stored execution response, including a 500 error. It also describes parameter checks and key pruning. Its API v2 behavior differs. A key is therefore not permanent protection, and repeatedly receiving an error does not justify inventing a new key to force another action.³

Rehearse a lost acknowledgement

With the implementer's authorization, use a test environment and fictional records. Simulate an acknowledgement failure after a test action succeeds. Observe whether the workflow inspects the existing result, uses the documented retry protection, or creates a duplicate. Also test the path where status remains unknown.

Ask the operator to show the original reference, attempt count, current evidence and receiving owner. If those cannot be found, that is the next repair. Do not begin by increasing the retry limit.

The boundary

This guide is not an implementation recipe, a payment instruction or an exactly-once guarantee for a multi-step workflow. Each service may have different error handling, expiry and consistency behavior. A new business action requires its own authorization; a technical retry must not quietly become one.

Try the card on one approved workflow. After an ambiguous failure, can your team explain what already happened before deciding what should happen next?