THE SHORT ANSWER
Resilient retries start by asking whether the first action already happened. A timeout does not prove failure. Use stable work identifiers, inspect ambiguous destination states and distinguish repeated reads from repeated changes. Idempotency must account for actual side effects; a polite instruction to avoid duplicates cannot establish that technical property or prove what the destination system did.
To connect individual AI applications with reliable marketing operations, read the pillar guide AI transformation in B2B marketing: from individual prompts to reliable operations.
Separate rejection, failure and uncertainty
A clearly rejected request requires its prerequisite to be corrected. A call that failed before execution may be retryable under appropriate conditions. A timeout after transmission can leave execution uncertain. Represent these distinctions in the tool contract and agent state. One generic error code encourages incorrect retries. Check asynchronous jobs too: accepted does not mean complete. The next step may be a status request rather than another execution. If the integration cannot reliably distinguish these conditions, provide an explicit manual inspection path rather than pretending every unsuccessful response represents the same situation. Explore this further in the guide Recording agent state: what has actually been completed?.
Give each intended operation a stable identifier
Link repeated attempts at the same intended action to a unique work identifier. Define the associated content and how long the destination recognises that identifier. Generating a new random identifier on every attempt does not prevent duplication. Conversely, the same identifier must not accidentally represent a changed request. AWS explains idempotency as a way to make retries safe. For your particular interface, inspect the actual contract: which side effects are covered, how differing content is handled and when earlier results expire. Do not infer those properties simply because the interface accepts an identifier field.
Inspect the destination before another change
When execution evidence is missing, look for the expected result using a stable identifier or other reliable attributes. A similar name alone may be insufficient when multiple records exist. Check content and relationships before accepting an existing item as proof. If the first action happened, continue from that result. If it demonstrably did not, a retry may be permitted. If neither conclusion is reliable, hand the task to an accountable person with previous attempts and unresolved questions. This preserves useful evidence and avoids forcing a false success-or-failure decision.
Bound retries and account for downstream effects
Define attempt limits, waiting behaviour and a stopping point for retryable requests. Delays between attempts may help with temporary issues; missing authorisation will not be repaired by more frequent calls. Consider indirect effects including notifications, exports and follow-up jobs. An unchanged stored field does not establish that the whole operation can be repeated without extra effects. If completed steps must be undone, plan a professionally valid compensating action. Undoing something can itself have consequences and should not be treated as a simple technical reset that necessarily restores the original business situation. Explore this further in the guide Bounding agents: runtime, tool calls and stopping.
Inspect a fictional duplicate ticket case
A fictional agent creates an internal ticket for an approved research request, but the response is lost. Instead of creating another ticket, the process queries the original work identifier. It finds the existing ticket and adopts that result. This hypothetical example shows the intended recovery path. If the ticket system does not support such an identifier, the team needs another reliable reconciliation method or a manual exception path. Assuming a timeout means no ticket was created is not an adequate substitute, even if previous demonstrations happened to behave that way.
Test the critical timing boundaries
Simulate connection loss before execution, after execution and before the response reaches the caller. Add delayed responses, two concurrent attempts and the same identifier submitted with changed content. The acceptance criterion is more than a successful second attempt. Check that the intended business effect exists within the agreed scope and no unwanted additional consequences occurred. Inspect stored state and whether an operator can reconstruct the outcome. Changes to tools or destinations can alter earlier assumptions about repeatability and should trigger these tests again rather than inheriting an old resilience claim.
INTERACTIVE / FROM READING TO ACTION
Three checkpoints for your implementation
Choose a checkpoint and track your reading progress. Checks are neither saved nor sent and do not score your business.
CHECKPOINT 01
Inspect the destination before another change
When execution evidence is missing, look for the expected result using a stable identifier or other reliable attributes.
Explore in the article ↗CHECKPOINT 02
Bound retries and account for downstream effects
Define attempt limits, waiting behaviour and a stopping point for retryable requests.
Explore in the article ↗CHECKPOINT 03
Inspect a fictional duplicate ticket case
A fictional agent creates an internal ticket for an approved research request, but the response is lost.
Explore in the article ↗Frequently asked questions
Can every failed request be retried?
No. Ambiguous execution requires reconciliation first; a business rejection requires a corrected prerequisite.
Does an identifier alone prevent duplicates?
Only when the executing interface recognises it under a defined contract.
Does an unchanged field prove idempotency?
Not necessarily. Notifications or other side effects may occur again on every call.
How can I put “Separate rejection, failure and uncertainty” into practice?
A clearly rejected request requires its prerequisite to be corrected. A call that failed before execution may be retryable under appropriate conditions. A timeout after transmission can leave execution uncertain.
What matters when working on “Give each intended operation a stable identifier”?
Link repeated attempts at the same intended action to a unique work identifier. Define the associated content and how long the destination recognises that identifier. Generating a new random identifier on every attempt does not prevent duplication.
