AI agents can be interrupted while editing files, calling tools, or carrying out multi-step tasks. Restarting repeats completed work, but continuing from unverified or outdated progress can carry earlier errors forward. A saved state is not necessarily a suitable place to resume. We introduce recoverability as a system primitive that makes reuse an explicit decision: select a supported starting point and a permitted recovery action, or withhold automatic continuation. Its behavioral contract binds that choice to supporting evidence, execution, and independent checks. A reference architecture connects persistence, validation, and control, with complementary runtime instances testing distinct responsibilities. Four deterministic and 20 paired file challenges demonstrate that accurate restoration and successful completion can conceal disallowed starting points. Progress controls attribute retained work to shared restoration. Event-time tests show that permission must also constrain the action, and that independently held policy evidence can expose violations even after an effect occurs. These findings establish why recovery decisions need their own evaluation, beyond restored bytes and final task success. Within supplied policies and a declared trust model, the contribution is a common, testable interface for retaining justified progress and making the conditions for its reuse explicit and enforceable.
Figures & tables
Figure 1: Choosing where to resume. A passed the required check and remains eligible at failure; newer B is excluded. Either snapshot can be restored exactly and later repaired to a valid document. Those outcomes do not reveal whether the chosen starting point met the continuation conditions.
Final invariant satisfied?
Decision policy-correct?
Interpretation
Yes
Yes
A valid endpoint follows a policy-correct decision
Yes
No
Endpoint success masks an incorrect recovery decision
No
Yes
A valid halt or escalation, or an unsuccessful granted continuation
No
No
Neither the decision nor the endpoint meets its requirement
Table 1: Task outcomes and recovery decisions answer different questions.
Figure 2: RPR reference control architecture. Three layers connect candidate registration and eligibility assessment to a recovery decision, its execution or withholding, and subsequent verification. Audit preserves separate evidence about restoration fidelity, adherence to the decision, and the final task outcome.
Object
Architectural role
OperationalState
Current goal, cursor, plan, and unresolved work needed to interpret execution.
Artifact
Versioned task product, such as a document, patch, or table, whose content can be inspected and validated.
Checkpoint
Stored state reference and continuation context forming a candidate recovery point.
MemoryClaim
Retained fact, reflection, or skill whose applicability must be reconciled with current evidence.
Trace
Record of actions, observations, and effects supporting provenance and diagnosis.
VerifierOutput
Result of a scoped test, schema check, policy check, or approval tied to the version it assessed.
Table 2: Objects and their roles in the recoverability design.
Instance
State and control mechanism
Scope of the evaluated behavior
RPR-Grant
Single-executor task state, deep checkpoints, recorded eligibility, fixed recovery routes, and an external action ledger
Creation-time contract eligibility and scoped restoration; all recovering paths have an eligible source.
RPR-File
Document snapshots, a deterministic source rule, actual file restoration, and file-tool records
The same source contract with sampled content and repairs; no general task-state restoration or event-time authority assessment.
RPR-Authority
Supplied event-time evidence and policy, a task-side controller, an isolated effect authority, and retained verification evidence
Both grants and withholds, enactment, and bounds within a declared profile and trust model.
Table 3: Implemented responsibilities and scope of the runtime instances.
Mode
Response and continuation source
Fail-fast
Terminate without continuation.
Blind retry
Restart at step 1 and clear the remaining scripted injection.
Checkpoint-only
Restore the latest stored checkpoint with a generic transition.
Recoverability
Restore the latest recorded contract-eligible checkpoint with a fixed failure-specific transition.
Table 4: Execution modes and post-failure source policies.
Study
Research question
Runtime and controlled scope
A
When the newest checkpoint is ineligible, does recovery choose the allowed one, and would checking the final result reveal a wrong choice?
RPR-Grant; 16 scenarios, 64 runs
B
When both restoring modes choose the same checkpoint, how much validated work is retained and how many actions are repeated?
RPR-Grant; 18 scenarios, 72 runs
C
Does the same source-choice distinction hold for shared model-generated candidates and actual file restoration?
RPR-File; 20 retained candidate pairs, 40 runs
D
When current conditions require continuation or withholding, does execution follow that decision, and can its record be checked independently?
RPR-Authority; 18 matched cases, qualification and a 36-run main matrix
Table 5: Research questions and controlled study scope.
Figure 3: Choosing a recovery point and preserving its progress. (a) The modes choose differently when the newest saved checkpoint is ineligible. (b) When both choose the same checkpoint, both preserve its validated prefix. Tables 6 and 7 separate source-choice results from action accounting.
Scenario group
System
Contract-gold source selected
Exact restoration
Run completed flag
Final invariants
Original scenarios ( n=12 )
Checkpoint-only
12/12
12/12
12/12
10/12
Original scenarios ( n=12 )
Recoverability
12/12
12/12
12/12
12/12
Eligibility challenges ( n=4 )
Checkpoint-only
0/4
4/4
4/4
4/4
Eligibility challenges ( n=4 )
Recoverability
4/4
4/4
4/4
4/4
Table 6: Source selection, restoration, and endpoints in Study A. The table reports the two restoring modes; fail-fast and blind retry are included in the 64-run matrix but do not select and restore checkpoints.
Benchmark position label
System
Total attempts
Useful final actions
Re-execution overhead
Validated actions retained at recovery
Shallow
Blind retry
4.0
2.0
2.0
0.0
Shallow
Checkpoint-only
3.0
2.0
1.0
1.0
Shallow
Recoverability
3.0
2.0
1.0
1.0
Medium
Blind retry
8.0
4.0
4.0
0.0
Medium
Checkpoint-only
5.0
4.0
1.0
3.0
Medium
Recoverability
5.0
4.0
1.0
3.0
Table 7: Action accounting in Study B. Each row averages the two task families and three failure families. The frozen shallow/medium/deep labels denote configured step counts. Fail-fast does not continue and is omitted from this table.
Figure 4: Paired file-restoration protocol. Each mode receives the same retained candidate B and the same write-then-timeout pattern. Their source policies select different snapshots, which are restored and checked before independent repair. Successful final files do not retrospectively establish that both sources were allowed.
System
Runs
Contract-gold source selected
Exact restoration
Run completed flag
Final invariants
Checkpoint-only
20
0/20
20/20
20/20
20/20
Recoverability
20
20/20
20/20
20/20
20/20
Table 8: Paired source selection and file outcomes in Study C. Each of the 20 retained challenge candidates is shared across modes.
Stage
Retained result
Evidentiary role
Seal
Pass; protected files recomputed with zero drift
Integrity check before expected values are released
Semantic controls ( sc-30 )
30/30 expected rejects
Scoring discrimination against controlled mutations, with independent-process oracle output
Enforcement probes ( ep-84 )
84/84 blocked
Synthetic apparatus-channel bypass probes, each with an isolated authority session
Recovery-bound probes ( rb-18 )
18/18 terminated
Case-bound primary, adversarial, protocol-violation, and bound+1 sessions
Qualification ( qual-18 )
18/18 ok
One execution per matched case
Main matrix ( main-36 )
Decisions 36/36; grants 12/12; withholds 24/24
Two executions per case, including physical enactment and enforced dispositions
Table 9: Declared-profile decisions and supporting validation in Study D.
Figure 5: Independent policy evidence changes acceptance. Both rounds produce the physical effect. The caller’s pre-client reference exposes the altered policy and rejects conformance in round 13; it does not prevent or roll back the effect.
Requirement
Evidence provided
Boundary of the evidence
Distinguish saved state from eligible state
A/C separate stored from recorded-eligible candidates; D varies event-time evidence support.
Eligibility rules and facts are supplied; A/C do not independently reassess support at failure.
Decide whether and how to continue
A/C expose selected sources, A/B record fixed routes, and D tests required grants and withholds.
Source and route policies co-vary in A/B; D tests only a declared deterministic profile.
Execute according to the decision
A/C check exact restoration; D checks enacted effects, withholding, and unauthorized requests.
Restoration is scoped to task snapshots or one file; D relies on its caller/spawn trust base.
Retain evidence and limit recovery
B checks common action accounting; D verifies retained authority evidence and termination under bounds.
B measures action counts, not operational cost; offline checks establish the retained record within its declared scope.
Table 10: Evidence for the four recoverability requirements and its limits.
A durable agent can resume a consequential action while its authority changes and the action's external outcome remains uncertain. We study execution-time reliability of tool-using AI agents, isolating recovery decisions from language-model behavior. Checkpoint state, permission to dispatch, evidence of an external effect and permission to reconcile are distinct obligations. We present a finite conformance study that checks these obligations through histories scored against a provider effect ledger hidden from the recovering application. A prospectively frozen campaign executes 336 histories on native LangGraph and Temporal hosts, crossing 14 schedules, three provider contracts and four matched application policies. All 168 paired host cells have identical checked outcomes. Per host, retained-ledger reconciliation passes all 42 histories: 21 checked completions, 15 denials and six unknown outcomes with reservations retained. Cached retry, revalidation before retry and stable-key retry pass 30, 36 and 31 histories respectively. A separate 16-case component study of InfinityOS, an enterprise AI platform developed by Arya.ai, exercises exported authority, worker, recovery and settlement code over repository fakes. The results isolate the roles of current authority, provider contracts and retained observations in recovery, with safety, completion and unresolved obligations reported separately for the declared application profile.
Many real-world tasks require LLM agents to interact with their environments over long execution horizons. Errors that occur early in execution may propagate through both the agent context and environment state, and their effects may be difficult to reverse through subsequent actions. Existing methods mainly seek to reduce such errors through plan refinement and safety checks but provide little support after errors occur. To enable recovery during long-horizon execution, we present AgentRewind, a runtime recovery framework that records aligned checkpoints of the agent context and controlled environment, allowing agents to return to an earlier state and resume execution with information from previous attempts. We also construct MettleBench, a benchmark for evaluating task completion and partial progress on long-horizon engineering assignments containing a series of related requirements. Experiments across tasks, multiple models, execution strategies, and agent harnesses show that AgentRewind improves task success rate and average checklist progress over the compared baselines.
Yu Zhuang, Kefei Chen, Yitong Duan +3
University of Chinese Academy of Sciences · Zhongguancun Academy, Beijing, China · Institute of Automation, Chinese Academy of Sciences +1
Recent advances in large (vision) language models have enabled computer-use agents that automate digital workflows via fine-grained keyboard and mouse operations. However, such agents remain fragile in long-horizon settings, where errors accumulate and executed actions leave unintended side effects, making the ability to recover from failures critical. Yet, existing remedies remain inadequate: environment resets are infeasible in proprietary settings, action replay is prohibitively expensive over long horizons, and API-based rollback is limited to web environments, leaving model-based recovery largely unexplored. To address this gap, we present ReTrace, a scalable evaluation framework for systematically studying recovery behavior in computer-use agents. We formalize Transition-Consistent Recovery: identical downstream actions from the recovered and target states must yield identical outcomes. We operationalize this criterion through goal-oriented action replay following controlled error injection. Using ReTrace, we present the first systematic study of autonomous, model-based recovery, revealing that (i) ideal recovery can unlock model's latent task completion capabilities, (ii) current computer-use agents fail to exploit their latent recovery capabilities, and (iii) accurate model-based recovery yields measurable end-to-end gains. Together, these findings establish recovery as a fundamental capability for building reliable computer-use agents. Our code and dataset is available at https://github.com/BangProx/ReTRACE.