AI Agent Recovery: Resume the Work Without Repeating the Action

AI agent recovery needs more than saved memory. Design action records, reconciliation and safe resumption so an interrupted workflow does not repeat a change.

By Ahmad Nizami

Featured illustration for AI Agent Recovery: Resume the Work Without Repeating the Action

An AI agent submits a refund. The payment service accepts it, but the connection fails before the agent receives confirmation. A replacement worker opens the saved conversation and sees an unfinished task.

Should it try again?

That is an AI agent recovery problem, not a question about how well the model remembers the conversation. The business needs to distinguish an action that failed from an action whose result is unknown. Otherwise, a successful restart can create a second refund.

In brief: preserve the workflow's progress independently of the agent process, record consequential actions before attempting them, reconcile uncertain results with the receiving system and recheck authority before resuming. Saved memory is useful context. It is not proof of what happened.

The example here is illustrative. The design recommendations below are not claims about measured results from my businesses or guarantees supplied by a particular platform.

This week's infrastructure news makes recovery a buying question

On 21 October, VAST described a foundation stack with NVIDIA for governed agent sandboxes. Its architecture separates persistent storage and operational records from the environment executing the agent. The announcement describes persistent volumes, snapshots and clones that support suspension and resumption.

Chris Mellor's reporting in Blocks & Files highlights the same separation between ephemeral execution and durable agent state. This is reporting on a supplier architecture, not an independent benchmark showing that every resumed business transaction is safe.

The next day, the Agentic AI Foundation announced four additional projects, including OpenSandbox. The announcement describes common sandbox lifecycle and execution interfaces. The New Stack's reporting on the expansion also explains Open Responses, a shared model interface specification, and notes that provider support is not universal.

These developments reduce the need for every team to invent every infrastructure component. They do not remove the need to design recovery semantics for the actual business workflow.

A sandbox can preserve a file without knowing whether a downstream payment completed. A common model API can simplify integration without preserving identical behaviour after a model change. Treat portability, persistence and safe resumption as three separate acceptance questions.

Keep business state outside the conversation

Consider a service workflow with five stages: establish eligibility, calculate a proposed remedy, obtain any required approval, submit the action and confirm the outcome.

A transcript may describe all five. It should not be the only place the system records which stages are complete.

Maintain a durable workflow record with an explicit current state, a case identifier, the responsible owner and the evidence supporting the next transition. Record the version of the policy, tool contract and workflow definition used for consequential decisions.

Store only the information needed for the purpose. Durable does not mean permanent, and recovery is not a reason to retain unrestricted customer conversations indefinitely.

The replacement worker should read this record rather than ask a model to infer progress from narrative. The model can help interpret a new exception. Deterministic state transitions should decide whether a completed action can be attempted again.

This is a narrower engineering concern than the overall lifecycle of trusted autonomy. A workflow may have a named owner and sensible permission limits yet still resume incorrectly after a network failure.

Record intent before crossing the action boundary

For each consequential operation, create an action record before calling the external service. Give the logical action a stable identifier that survives retries and replacement workers.

Useful fields include the workflow identifier, operation type, target, approved parameters or a protected reference to them, authorisation evidence, attempt history and downstream reference.

Keep the logical action separate from its attempts. A retry is another attempt at the same intended refund, not automatically a new refund.

Where a receiving API supports idempotency, use its documented mechanism and preserve the same key for the same logical operation. Confirm the scope and lifetime of that protection. Do not assume an expired key or a different endpoint will preserve the original guarantee.

If parameters change materially, stop and determine whether this is still the authorised action. Reusing an identifier for a different instruction can be as misleading as generating a new identifier for every retry.

An internal action ledger cannot by itself make an external service idempotent. When the receiver offers no suitable protection or lookup, the safe design may require a reconciliation queue and human review rather than automatic replay.

Treat an unknown result as a real state

Avoid a model that offers only “completed” or “failed”. A timeout may leave the caller without enough evidence to choose either.

Use an explicit uncertain state. Block another execution attempt until the workflow has checked the receiving system through an authoritative reference, transaction query or suitable reconciliation process.

For the illustrative refund, the recovery worker should look for the original transaction. If it finds an accepted refund with matching details, record that result and continue to customer confirmation. If the receiver proves rejection, apply the documented retry policy.

If neither outcome can be established, preserve the uncertainty and escalate. Do not convert missing evidence into permission to repeat the action.

Make that status visible to service colleagues. An adviser should not issue a replacement refund because one interface says “failed” while the payment system is still processing the first request.

The practical target is not an unsupported promise of exactly-once execution across every system. It is a controlled response to duplicates, delays and ambiguous outcomes, with a clear owner for unresolved cases.

Recheck authority and freshness when work resumes

A saved approval describes a decision made under particular conditions. It does not necessarily authorise execution indefinitely.

Before resumption, check whether the case is still open, the requested action is still wanted, the approval remains valid and the relevant permissions still apply. A customer may have withdrawn the request while the agent was paused. Another adviser may already have resolved it.

Version important preconditions. If a remedy depended on an account balance, product price or eligibility rule, determine whether that evidence must be refreshed before acting.

Do not restore expired credentials from a snapshot simply because they were present before interruption. Re-establish access through the current identity controls.

The AI agent access-review guide addresses changes in purpose and permission. Recovery must respect those changes rather than treating an old checkpoint as a way around them.

Prevent two workers from owning the same next step

Recovery can create concurrency. A slow worker may still be running when the system decides to replace it.

Use a durable ownership mechanism appropriate to the platform, such as a lease with fencing enforced at the write boundary. A worker whose lease has expired must not be able to complete a stale write merely because it still has a network connection.

Tie state changes to an expected version so that a late response cannot silently overwrite newer progress. Correlate downstream callbacks with the original logical action, not only with whichever worker happens to be listening.

Parallel agents need an equally explicit division of responsibility. Two agents can investigate different evidence sources. They should not independently commit the same remedy without a common decision and action boundary.

These controls belong in the application and integration design. A prompt asking agents to avoid duplicate work is not a substitute for concurrency protection.

Recover the service, not just the process

Some effects can be cancelled. Others can be compensated but not undone. A customer message cannot be made unread, and a completed financial action may require a separate corrective transaction.

Document the recovery route for each action type. Identify who can approve remediation, which records they need and how the customer will be informed. Avoid describing compensation as a perfect reversal.

Preserve a clear distinction between restarting an agent, retrying a request, reconciling a result and correcting completed work. They have different risks and should not share one ambiguous “retry” button.

For a customer-facing platform, the operating interface matters too. The Omningage case study provides context on joined-up service workflows, not evidence that the specific recovery design proposed here is already implemented there.

Test the interruption points deliberately

Extend the production agent evaluation approach with fault-injection cases. Stop execution immediately before submission, after the receiver accepts the action but before confirmation, during an approval wait and while a replacement worker is starting.

Also test duplicate callbacks, out-of-order responses, expired approvals and a human resolving the case during the pause.

Judge the business result: no unjustified duplicate action, no lost accepted action, understandable status and an accountable route for uncertainty. A process restarting successfully is only one part of the test.

Record reconciliation time and unresolved cases alongside recovery time. Faster restart is not an improvement if it increases duplicate remedies or leaves advisers repairing inconsistent records.

Start with one workflow and one consequential integration. Produce a short recovery contract covering durable state, logical action identifiers, receiving-system guarantees, freshness checks, concurrent ownership and remediation. Exercise it before extending autonomy.

The wider Agentic AI reading path covers the surrounding architecture. For implementation, my technology delivery approach starts with the workflow and the evidence needed to operate it. Discuss a bounded delivery engagement if recovery is the missing production requirement.

Sources and evidence notes

Sources checked on 26 October 2026. The recovery contract and service example are original analysis, not a platform certification or a report of personal implementation results.