cs.AISep 12, 2026
SaveRecoverability as a System Primitive for Long-Horizon AI Agents
Organizations: Independent researcher · Beijing Information Science and Technology University
Abstract
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 ( ) | Checkpoint-only | 12/12 | 12/12 | 12/12 | 10/12 |
| Original scenarios ( ) | Recoverability | 12/12 | 12/12 | 12/12 | 12/12 |
| Eligibility challenges ( ) | Checkpoint-only | 0/4 | 4/4 | 4/4 | 4/4 |
| Eligibility challenges ( ) | 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.
More in this topic
AI Agent Reliability
AI agent reliability studies whether tool-using systems act correctly, consistently, safely, and recoverably across changing tasks and environments.
See all 338 papers