How do you resume a failed agent workflow?

Resuming a failed agent workflow means restarting execution from a valid saved state instead of repeating the entire task. It requires a durable checkpoint, a clear understanding of the failure, and safe handling of any actions that may already have happened outside the workflow.

Example: An API test-generation agent

Imagine an agent with these steps:

1. Read API requirements for an endpoint.
2. Generate test cases.
3. Validate tests against the specification.
4. Save the approved test suite.

After test generation, the workflow saves a checkpoint. The validation step then fails because the test runner temporarily loses its connection.

Once the dependency is available, the orchestration system can load the saved state, recover the generated tests, and run the remaining work without extracting the requirements again.

Checkpoint → Failure → Diagnose → Restore saved state → Continue or retry safely

How does recovery work?

• Identify the affected run: Use a stable workflow/thread identifier, not just the latest job in a shared queue.
• Inspect the failure: Check the failed node, error category, retry attempts, and whether recovery is safe.
• Load a durable checkpoint: Retrieve the last consistent saved state and execution metadata.
• Reconcile external effects: Determine whether any timed-out API call, file write, or database update already succeeded.
• Apply an appropriate fix: Restore service availability, correct the invalid input, or obtain required approval.
• Resume execution: Continue from the checkpoint according to the workflow framework's replay and scheduling semantics.
• Verify completion: Confirm expected outputs and record whether recovery succeeded or needs escalation.

LangGraph example

In LangGraph, a graph compiled with a durable checkpointer can associate saved execution state with a thread_id. A subsequent invocation using that thread can recover persisted progress.

A key distinction: resuming does not guarantee that the failed line of code continues exactly where it stopped. Depending on the execution boundary, a node or task may be replayed. Place side-effecting operations behind idempotency or reconciliation checks.

For intentional human-interrupt flows, resumption uses the framework's interrupt/resume mechanisms rather than simply treating an interruption as an ordinary exception.

What changes when using Celery?

A Celery worker retry starts another task attempt; it does not automatically restore a LangGraph checkpoint. When combining Celery and LangGraph, the task should carry a stable workflow identifier, and the graph runtime should load its own saved state from durable storage.

Also prevent two workers from resuming the same run simultaneously without coordination, for example by using a run-level lock or lease.

When should you avoid automatic resumption?

• Required permissions or human approval are missing.
• The previous operation's external outcome is unknown and repeating it could be harmful.
• The checkpoint is missing, incompatible, or corrupted.
• The failure is permanent, or retry and resource budgets are exhausted.

In short

Reliable workflow resumption combines durable checkpoint retrieval, failure-aware recovery, and safe replay. It saves repeated work while protecting against duplicate actions and inconsistent outputs.