Long-Running Agent State Recovery Decision

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.