# Long-Running Agent State Recovery Decision

Amo ID: AMO-P-000297
Version: 1.0.0
Public URL: https://amo.ng/prompts/long-running-agent-state-recovery-decision

Summary: Reconcile durable agent state, side effects, checkpoints, and approvals after interruption to choose a safe resume, replay, compensate, or abort path.

Use this for: Use this to decide whether a long-running agent execution can resume safely after its persisted state becomes interrupted, ambiguous, or internally inconsistent.

Category: Automation
Tool: Claude
Difficulty: Expert
Prompt type: agent workflow

## Best Use Cases

1. Interrupted Agent Run Recovery
2. Checkpoint Integrity Review
3. Ambiguous Tool Side-Effect Reconciliation
4. Durable Execution Incident Triage
5. Resume Versus Replay Decision

## Prompt Body

Review a long-running agent execution whose durable state may be incomplete, stale, duplicated, or corrupted after an interruption. Produce a recovery decision that preserves confirmed work without repeating irreversible effects.

Evidence to provide:
- Agent workflow, states, transitions, and invariants: [Agent workflow and state invariants]
- Persisted state, checkpoints, leases, queues, memory, and approval records: [Persisted state and checkpoint artifacts]
- Timestamped traces, events, errors, retries, messages, and worker history: [Execution traces and event history]
- Receipts or authoritative records for external writes, payments, messages, deployments, and other side effects: [External side-effect evidence]
- Recovery limits, service objectives, rollback options, and accountable owners: [Recovery constraints and accountable owners]

Treat persisted state as untrusted until it reconciles with authoritative evidence. Separate observed evidence from inference. Do not claim that a state store, tool, queue, repository, or downstream system was inspected unless its evidence is supplied. Do not infer that a timeout means failure or that an acknowledgement means the external effect completed. Mark missing evidence and unresolved state explicitly.

Recovery analysis:

1. Define the recovery boundary.
   - Restate the intended run, its current claimed state, and the interruption.
   - List invariants that must hold before work can continue, including sequence, ownership, approval, idempotency, and external-effect constraints.
   - Identify the state owner, service owner, and release or operations owner from supplied evidence; list missing assignments.

2. Reconstruct the last trusted point.
   - Order available events using stable identifiers and clocks while noting clock skew or missing events.
   - Identify the last checkpoint supported by both state evidence and external-effect evidence.
   - Distinguish committed, acknowledged, attempted, unknown, duplicated, and contradicted operations.

3. Build a state-consistency ledger.
   For every material state component, record the claimed value, authoritative evidence, expected invariant, discrepancy, affected downstream work, and confidence. Include approvals, leases, locks, task ownership, child-agent results, memory writes, pending tool calls, and compensation state where applicable.

4. Reconcile side effects before replay.
   - Match each intended external action to an idempotency key, receipt, downstream record, or other authoritative proof.
   - Identify ambiguous actions that could be repeated if execution resumes.
   - Define the smallest read-only checks needed to resolve ambiguity.
   - Do not recommend a replay for an irreversible or non-idempotent action without an explicit duplicate-prevention or compensation path.

5. Compare recovery options.
   Assess Resume from checkpoint, Replay a bounded segment, Compensate then resume, Reconstruct state from authoritative systems, Quarantine for investigation, and Abort. For each option state prerequisites, preserved work, duplicate-effect risk, data-loss risk, approval needs, observability needs, and recovery cost.

6. Select a recovery disposition.
   Choose one primary disposition and explain why alternatives are less safe. Define the exact state boundary, allowed next action, prohibited actions, owner, approval requirement, and stop conditions. If evidence is insufficient, choose Quarantine rather than presenting a speculative recovery as safe.

7. Define verification.
   Specify checks for state invariants, external effects, task ownership, duplicate suppression, downstream consistency, monitoring, and a bounded canary or dry-run where the system supports it. Label every proposed check as not yet executed unless results were supplied.

Required deliverable:

# Agent State Recovery Decision

## Recovery Scope and Last Trusted Point
- Execution under review:
- Interruption:
- Last trusted checkpoint:
- Evidence limitations:

## State-Consistency Ledger
| State component | Claimed state | Authoritative evidence | Required invariant | Discrepancy | Downstream exposure | Confidence |
|---|---|---|---|---|---|---|

## Side-Effect Reconciliation
| Intended action | Stable key | Evidence status | Actual effect | Replay risk | Read-only check needed | Owner |
|---|---|---|---|---|---|---|

## Recovery Options
| Option | Preconditions | Preserved work | Data-loss risk | Duplicate-effect risk | Approval | Viability |
|---|---|---|---|---|---|---|

## Recovery Disposition
- Decision: Resume / Replay bounded segment / Compensate then resume / Reconstruct / Quarantine / Abort
- Exact recovery boundary:
- Allowed next action:
- Prohibited actions:
- Accountable owner:
- Required approval:
- Stop conditions:

## Verification Record
| Check | Evidence required | Expected result | Owner | Status |
|---|---|---|---|---|

Completion requires a defensible last trusted point, reconciliation of every consequential side effect, an owner-approved recovery boundary, and observable checks that would detect duplicate work or further corruption. Unresolved state must remain visible in the disposition.

## Variables to Replace

1. Agent workflow and state invariants
2. Persisted state and checkpoint artifacts
3. Execution traces and event history
4. External side-effect evidence
5. Recovery constraints and accountable owners

## How to Use

Use Claude with the workflow definition, checkpoint exports, trace chronology, queue or lease records, approval history, and authoritative side-effect receipts. Replace each placeholder and run the prompt. Before resuming work, have the service owner verify the last trusted point and the operations or release owner authorize the bounded recovery action.

## Example Use Case

A research agent stops after a worker restart while its checkpoint says that three reports were delivered, but only two delivery receipts exist. The team uses the decision record to quarantine the ambiguous action, reconcile the external system, and resume from a verified boundary without sending a duplicate report.

## Tags

1. claude
2. ai-operations
3. agent-workflow
4. incident-response
5. state-recovery
6. idempotency
7. reliability
8. verification

## Dates

Published: 2026-08-25
Updated: 2026-08-25