How to recover AI agent workflows after a process failure

Why can a retry repeat completed work?

A worker can finish a task, save its result and stop before acknowledging completion to the coordinator. The coordinator sees unfinished work even though the result exists. Starting a fresh execution after a timeout can repeat the task or create competing workers.

The important question is not simply whether the worker is alive. It is whether the application can connect a retained result to the same operation and determine who owns its next transition. That requires durable coordination state as well as durable outputs.

What state should survive the worker?

• Operation identity: a stable identifier reused across attempts.
• Committed results: retained runs and artifacts associated with that work.
• Ownership: a recorded lease and expiry policy for coordination.
• Recovery evidence: enough history to explain why a successor reused a result or resumed a step.

The AgentPlat recovery guide recommends documented persistence adapters, stable work identities and configured lease ownership. A successor should reconcile retained state before executing again.

What does the AgentPlat recovery example test?

The example targets a specific crash boundary. It creates an isolated temporary PostgreSQL schema and starts a child worker. The launcher stops the child after its Room result commits but before the coordination acknowledgement. A successor starts after the coordination lease expires.

The scenario then checks retained operation and run identities. Its assertions expect two completed runs and two artifacts, reusing completed research and drafting work. The temporary schema is removed during cleanup. The launcher source and its worker make the injection point and checks inspectable.

This example uses no real model or external tool service. A successful execution demonstrates those assertions in that environment. This article describes the documented scenario; it does not report a new execution or a production benchmark.

Why does recovery not imply exactly-once external effects?

A database can retain a Room result while another system independently processes an action. If the provider loses its connection after submitting that action, the local worker may not know whether the remote system completed it.

A retry can be safe only when the application has an effect-specific way to resolve that ambiguity. Depending on the external service, this may mean reusing an idempotency key, retrieving the existing operation or pausing for reconciliation. Repeating the same prompt does not resolve the state of the remote action.

The recovery guide explicitly does not establish arbitrary in-flight provider recovery, exactly-once external effects, availability under every failure or throughput guarantees.

How should you test your own recovery path?

1. Identify the commit and acknowledgement boundaries in one workflow.
2. Inject a stop before and after each boundary, using a development environment.
3. Verify that a successor uses the same work identity and respects lease ownership.
4. Inspect retained runs and artifacts for unexpected duplication.
5. Test external operations separately, including an unknown remote outcome.
6. Retain failures and environment details so the result can be reproduced.

When your system needs coordination across independent peers, evaluate Agent Mesh and the distributed coordination guide. Local workflow recovery and peer coordination address different failure boundaries; choose the additional machinery only when your deployment needs it.