Retry only when the system can determine whether the business effect already happened. A missing confirmation does not necessarily mean the original action failed.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Separate request from result
An external service may perform an action before the connection loses its response. Describe that uncertainty in the workflow. For an illustrative task assignment, the question is whether a task already exists, not merely whether the sending screen displayed success.
Define an action identity
Ask the delivery team how repeated attempts are associated with the same intended action. The mechanism depends on the systems involved and their supported interfaces. Keep the identity and outcome available for investigation. Do not create a brand-new business request every time a user presses retry.
Choose the uncertain path
Where the outcome cannot be verified automatically, route the case to review with the relevant references. Explain what staff should check before repeating the action. A controlled pause may be more appropriate than an automatic retry for an action whose duplicate would create a significant operational problem.
Demonstrate a lost response
Test an interruption after the receiving system acts but before the sender receives confirmation. Then retry through the intended interface. Verify that the final business outcome is correct and understandable. Testing only a connection failure before any action occurs misses the more difficult ambiguity that the design needs to handle.
Primary references
The guidance above is AgenticShip's proposed approach. These references provide technical background for the relevant recommendations.