Imagine this fictional scene: an operations manager is closing a customer’s onboarding task before lunch. The welcome email is approved. The agent calls the email service. A spinner turns, then the screen reports a timeout.
The manager’s cursor hovers over Retry. If nothing went out, the customer is waiting. If the message went out but the reply never reached the agent, Retry could send a second welcome. The dashboard offers an error message where the manager needs an answer.
A timeout tells you that an answer did not arrive within the waiting period. It does not, by itself, tell you whether the action happened. The email service might never have received the request. It might have accepted it just before the connection broke. Those possibilities look identical from the agent’s chair.
Nor does acceptance settle everything. A service accepting an email for processing is not proof of delivery, and delivery is not proof that the customer read it. Before recovering this workflow, the team needs to decide which of those outcomes it actually promises to track.
This uncertainty predates AI. In the Amazon Builders’ Library article “Making retries safe with idempotent APIs,” Malcolm Featonby describes a caller that requests a new EC2 instance but gets no response. Repeating the request could create another instance. The email problem has the same awkward shape: the caller has lost the answer, not necessarily the action.
A more capable model cannot reason its way into knowing what happened inside an email service. It needs evidence from that service, or a retry contract that makes repeating the request safe.
Start before the spinner. In our fictional workflow, give this approved welcome email a stable operation identifier and save its intended recipient, approved content version and current state in a durable record. Duplicate triggers for that same onboarding action should find the existing operation, rather than invent a new one. Coordinate workers so two restarts cannot independently decide to send it.
That record should survive the process that created it. It can distinguish a prepared action, an attempted submission, confirmed acceptance and an unresolved outcome. Recording an attempt before making the call helps preserve intent, but it does not prove the call reached the provider. After a crash, the record may still leave a question to investigate.
Here, “idempotency” becomes useful rather than decorative. For an API with the appropriate contract, repeating a request with the same identifier means asking for the same intended action again, not requesting another copy of it. The provider recognises the identifier and handles the repeat according to that contract.
Featonby’s article makes intent important. Two requests with identical parameters are not necessarily duplicates: someone might genuinely want two identical resources. For our welcome email, retries of the original approved send keep its identifier. A separately authorised follow-up is a different action. Changing the recipient or message while reusing the old identifier is not a safe shortcut; the API may reject the mismatch.
But an identifier in your own database is not a promise from the email provider. AWS explains that recording the token and performing the mutation must be atomic for its described contract. A local checkpoint and a remote email submission do not automatically share that atomic boundary. There is still room for the provider to accept the email just before the agent crashes without saving the response.
So recovery begins by checking the actual integration. Does this sending API support idempotent submission? For how long does it remember an identifier? Does a retry return evidence of the original request? A retry outside the provider’s retention window may no longer have the protection the workflow expects.
Where the provider supports it, look up the submission using a reliable correlation identifier and reconcile the local record with the result. A delayed or incomplete search result is not proof that nothing happened. Where the documented retry contract safely covers this request, reuse the original identifier. Do not generate a fresh one simply because the agent restarted.
If neither lookup nor safe replay can establish what happened, keep the outcome unknown and route it to a named person. Show that person the intended recipient, the approved message, when submission was attempted and what evidence is missing. They may need to make a business decision about the risk of a duplicate. The system should not disguise that decision as automatic recovery.
Restarting the agent is a separate problem. In “Scaling Managed Agents: Decoupling the brain from the hands,” published April 8, 2026, Anthropic describes separating the session log from the components doing the work so a replacement harness can recover the log and resume. That is Anthropic’s account of its architecture, not a guarantee about every agent product. Recovering a conversation still does not establish whether our email was accepted.
The distinction should shape the acceptance test. Anthropic’s “Demystifying evals for AI agents,” published January 9, 2026, distinguishes an agent’s transcript from the outcome in its environment: saying a flight is booked is different from an actual reservation. For this workflow, a confident “email sent” summary is not the success criterion. The provider’s recorded state matters.
In an isolated test environment, let the service accept the message and then withhold the response. When the agent resumes, does it reconcile or safely replay the original operation, rather than submit a fresh send? Kill the worker after acceptance but before its checkpoint is updated. Does recovery still respect that uncertainty?
Then test the less convenient cases. What happens when two workers resume together, when the idempotency window has expired, or when lookup is unavailable? Does the interface preserve “unknown,” give someone responsibility for resolving it and avoid claiming delivery? Repeat the trials; one successful demonstration leaves too much untested.
Back at the fictional manager’s desk, the recovered workflow finds a provider record tied to the original operation. It records acceptance, leaves delivery pending and does not send another welcome. Had that evidence been unavailable, the responsible ending would have been a held task with an owner—not a guessed success or an unexamined retry.
Bring one workflow and its awkward failure cases to Afiniti. Start with the moment someone is tempted to press Retry, and ask what evidence would make that safe.
Source: Malcolm Featonby, “Making retries safe with idempotent APIs,” Amazon Builders’ Library. https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/
Source: Anthropic Engineering, “Scaling Managed Agents: Decoupling the brain from the hands,” April 8, 2026. https://www.anthropic.com/engineering/managed-agents
Source: Anthropic Engineering, “Demystifying evals for AI agents,” January 9, 2026. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents