Source-linked AI summary
Permission to Retry: A Study of Authorization and Recovery in AI Agent Workflows
Deekshith Marla, Kushagra Bhatnagar
TL;DR
When an agent resumes after authority changes, it must distinguish permission for a new dispatch from evidence of a prior effect. The paper checks recovery histories against a provider effect ledger hidden from the application. Per host, ledger reconciliation passes all 42 histories, reporting checked completions, denials, and unresolved reservations separately.
Problem
A resumed workflow must decide what actions remain permitted and what can be concluded from earlier observations when authority changes and tool outcomes are uncertain.
Source: §1 · p. 1Method
Results
Per host, ledger reconciliation passes all 42 histories: 21 checked completions, 15 denials, and six unknown reservations.
Source: §5.1 · p. 3Takeaways & Limitations
For the declared profile, recovery must consider current dispatch authority, whether a prior delivery can still commit, and durable participant-visible evidence for settlement.
Source: §8 · p. 6The study uses one canonical action with scripted proposals and does not establish generalization to arbitrary tools, model behavior, concurrent agents, delegation graphs, or real authority stores.
Source: §7 · p. 6
Abstract
from arXiv · showhide
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.
1 Introduction
Resuming an agent workflow requires separating authority for a new dispatch from evidence about an earlier external effect. This study examines recovery obligations under changing authority and uncertain outcomes, using a bounded conformance artifact and measured application.
1 Introduction
- The study distinguishes recovering evidence of an existing effect from obtaining authority for a new dispatch after a refund acknowledgement disappears and write permission is revoked.Treating the missing acknowledgement as failure can release an obligation prematurely, while repeating the request can create a duplicate.Source: §1 · p. 1
- The paper evaluates how established workflow and agent-recovery foundations compose at agent recovery boundaries [1] [2] [3] [6].It frames the practical question as which obligations an application preserves at each boundary under an explicit provider contract.Source: §1 · p. 1
- The evaluation asks which recovery policies preserve safety while completing legitimate work, whether paired execution hosts differ, and how observation placement affects recoverability.The third question focuses on where a confirmed observation occurs relative to settlement.Source: §1 · p. 1
- The contribution combines a history specification separating admission, effects, and settlement with a prospective native-host campaign and a separately qualified InfinityOS component case study.The record includes raw observations, exact versions, data digests, a reconstruction checker, and explicit exclusions; policies are authored ablations rather than framework defaults or published security protocols.Source: §1 · p. 1
2 Related work and contribution boundary
The paper situates recovery at the intersection of authorization, provider commitment, and uncertain effects. Its controls are matched application policies, not security-protocol baselines.
2 Related work and contribution boundary
- AID-Guard connects authorization to provider commitment and ambiguity handling [1], while CapLease conserves authorization instances and qualifies effect guarantees by sink contract [2].LIMBO evaluates recovery under controlled tool faults and independent effects [3].Source: §2 · p. 2
- ACRFence studies semantic rollback and authority resurrection [6], while ZeroGate, Matoi, and ResidualAuth address freshness, reusable evidence, and authorization history [4] [5] [7].ACRFence distinguishes validated attacks from a mitigation not implemented in that evaluation.Source: §2 · p. 2
- The study evaluates matched application controls on native persistence/retry hosts at declared authority and observation boundaries; LangGraph persistence and Temporal retry semantics are execution mechanisms, not security baselines.The inspected papers’ closest protocols lacked qualified licensed executable implementations, and their absence is not scored as failure.Source: §2 · p. 2
3 Model and conformance contract
The conformance model separates workflow state, provider effects, and settlement evidence. It checks those obligations against declared authority and provider contracts without treating hidden provider truth as application evidence.
3 Model and conformance contract
- An authorization instance binds organisation/principal scope, canonical action, policy epoch, expiry, and allowed effect count; the campaign uses one synthetic refund and one effect per history.Proposals and approvals are scripted facts, not real human attestations or model outputs.Source: §3 · p. 2
- The scheduler owns provider truth, while the checker reconstructs history obligations including scope and freshness, approval consumption, worker ownership, effect multiplicity, retained uncertainty, and settlement evidence.The checker imports neither application controls nor InfinityOS admission or recovery predicates.Source: §3 · p. 2
- Repeated dispatch requires current write authority and either live stable-key deduplication or certified predecessor closure under this benchmark's explicit repeat-freshness rule.Prepared-redelivery protocols must be judged against their own contract rather than treated as broken for differing from this rule.Source: §3 · p. 2
- An admitted first delivery may commit after local revocation, while a separate read-only reconciliation capability can settle an observed historical effect without authorizing another write.The model assumes no instant remote-cancellation guarantee.Source: §3 · p. 2
- Provider profiles cover stable-key deduplication, queryable outcomes without deduplication or cancellation, and opaque outcomes; unresolved outcomes retain their reservation.An empty lookup cannot certify absence if an earlier request may still commit, and passing finite histories do not prove all possible effects were captured.Source: §3 · p. 2
4 Implementation and prospective study
The prospective study runs four matched recovery policies across two native execution hosts, using scripted interruptions and provider schedules. Its capture records the distinction between persisted observations, settlement, and host acknowledgement.
4.1 Matched applications
- All four policies share initial authority and action binding, reservation state, and receipt-bound idempotent settlement, but differ in retry and reconciliation behavior.Cached retry sends with a fresh key; revalidation checks current write authority before retry; stable-key retry preserves the transport key; ledger reconciliation looks up the prior delivery and does not redispatch.Source: §4.1 · p. 2
- LangGraph resumes a pending graph from its persisted checkpoint and application row, whereas Temporal retries an activity on a different process after a worker is killed before acknowledgement.The logical interruption positions match, but the host mechanisms differ; neither host is killed inside an active database transaction.Source: §4.1 · pp. 2–3
4.2 Corpus and capture
- The manifest crosses two hosts, 14 schedules, three provider contracts, and four policies for 336 histories, including revocation, lost acknowledgements, delayed commitment, settlement interruptions, and expired deduplication.There are 42 histories per host-policy combination.Source: §4.2 · p. 3
- After dispatch completion, the host persists the confirmed observation before settlement; settlement stores receipt identity so repeated settlement can verify the same evidence without charging twice.A pending request can commit at the final observation boundary after the replacement has acted; logical times specify ordering, not service latency.Source: §4.2 · p. 3
- The frozen campaign preserves histories, per-process state, versions, and results, and verification independently regrades histories and reconstructs coverage and aggregates.Earlier development work is separate from this prospective campaign, which does not claim unseen scenarios or statistical independence.Source: §4.2 · p. 3
5 Native results
The native campaign reports finite recovery outcomes by policy and finds matching checked results across paired LangGraph and Temporal hosts. Ledger reconciliation passes every supplied history, while observation timing and fixture protocol qualify the recovery and timing comparisons.
5.1 Safety and progress
- Cached retry reports success in 27 histories but only 15 checked completions; revalidation passes 36 histories with the same 15 completions and six unknown reservations.Cached retry's 12 repeated-delivery histories exceed the effect allowance; revalidation removes post-revocation fresh sends, but six still-authorized retries duplicate effects.Source: §5.1 · p. 3
- Stable-key retry has 16 checked completions, but nine histories exceed the effect allowance where deduplication is unavailable or expired, and six authority findings overlap effect violations.Stable transport identity addresses a different obligation from current authority.Source: §5.1 · p. 3
5.2 Why the observation boundary matters
- Retained confirmed observations permit settlement without another provider write even for P3, whereas empty P1/P2 lookups cannot certify absence before pending requests may commit.A post-revocation effect from a first admitted delivery remains distinct from admitting a new write after revocation.Source: §5.2 · pp. 3–4
5.1 Safety and progress
- All 42 ledger-reconciliation histories per host pass—21 checked completions, 15 denials and six unknown reservations; passing is not synonymous with task completion.The paired-host results agree across all 168 cells.Source: §5.1 · p. 3, Table I · p. 4, Figure 2 · p. 5
5.3 Observed fixture execution cost
- Whole replacement-worker times include startup, IPC, scheduling and timeout; their finite p95 is neither an apples-to-apples latency ranking nor a population estimate.Temporal's timeout/retry wait is part of the tested protocol, unlike the graph exception, which is closed before replacement starts.Source: §5.3 · p. 4
6 InfinityOS component case study
The InfinityOS component study exercised exported authority and recovery code on synthetic cases and repository fakes. Its cases preserved one effect per recovery history, while the study did not qualify deployed behavior or physical Mongo durability.
6 InfinityOS component case study
- All ten synthetic authority cases returned the specified grant or denial, testing dependency composition rather than real identity-provider ordering or cryptographic human confirmation.The cases included current grants, revocation, policy changes, dependency refusal, lease expiry, cancellation, wrong-run scope, and approval expiry.Source: §6 · p. 5
- Six recovery cases crossed response loss and rolled-back settlement with three provider profiles; a separate synthetic provider recorded one effect in every case, with no redispatch.Old worker heartbeats were refused after lease replacement without increasing the effect count.Source: §6 · p. 5
- The opaque lost-acknowledgement case retained its uncertain reservation, while the settlement-rollback case recovered from a retained confirmed observation without provider lookup.These outcomes support the observation-boundary distinction reported for the native corpus.Source: §6 · p. 5
- The 16 new component cases used repository fakes and a scripted engine, so they do not qualify physical Mongo durability, the full human-approval lifecycle, or deployed InfinityOS behavior.Existing real-Weave regression tests were not independent-provider experiments and were not pooled with the component study.Source: §6 · p. 6
7 Threats to validity
The evaluation is bounded by shared-project controls, a finite synthetic corpus, and unmeasured deployment and concurrency conditions. Its findings apply to the declared application profile rather than arbitrary tools or production systems.
7 Threats to validity
- The policies, provider, and checker share a project origin, leaving independent human review and a separately implemented oracle outstanding despite other checks against circularity.The common application logic also makes matched host outcomes unsurprising.Source: §7 · p. 6
- One canonical action with scripted proposals does not establish generalization to arbitrary tools, model behavior, concurrent agents, delegation graphs, or real authority stores.The benchmark's repeat-freshness contract is stricter than some prepared-redelivery contracts, so results should not be used to attribute violations of guarantees those systems did not offer.Source: §7 · p. 6
- The finite deterministic corpus was prospectively fixed after development, not sampled from deployments or held out from all adapter testing, and supports no frequency estimates or statistical replications.Safety can pass through correct refusal; progress metrics are reported separately to expose conservative abstention.Source: §7 · p. 6
- Native worker races, transaction-internal failures, database loss, settlement-log gaps, and real IAM check/commit contention remain unmeasured.No actual provider, billing account, model server, customer dataset, or production environment was used, limiting the contribution to conformance and replication evidence for the declared application profile.Source: §7 · p. 6
8 Implications and conclusion
The conclusion frames recovery around three distinct resume-time questions: current dispatch authority, the possibility of a prior effect, and durable evidence for settlement. The finite results separate safety, progress, and conserved uncertainty within the measured profile.
8 Implications and conclusion
- At resume, applications must distinguish whether a new dispatch is authorized, a previous delivery can still commit, and durable participant-visible evidence permits settlement.A checkpoint, current grant, or stable key alone does not answer all three questions.Source: §8 · p. 6
- The finite results distinguish safety, legitimate progress, and conserved uncertainty without ranking framework defaults.The conclusion scopes these implications to the measured profile.Source: §8 · p. 6
- The artifact provides concrete histories and counterexamples for evaluating other implementations under declared contracts.Source: §8 · p. 6
9 Availability, ethics and AI assistance
The publication package includes manuscript materials and outcome tables, while reproduction materials remain in the authors’ research record. The component study uses excluded proprietary source and repository fakes; experiments used synthetic identities, approvals, and actions.
9 Availability, ethics and AI assistance
- The publication package contains the manuscript source, figures, machine-readable outcome tables, and timing observations, but no public execution repository.Original captures, manifests, implementation, and detailed reproduction instructions are retained in the authors’ research record; the tables do not independently reproduce the experiments.Source: §9 · pp. 6–7
- The InfinityOS component case study depends on proprietary product source and repository fakes, which are excluded from the publication package.Source: §9 · pp. 6–7
- All identities, approvals, and business actions were synthetic, and no customer data, live provider, or model service was used.AI tools assisted with research-code development, capture analysis, and manuscript preparation.Source: §9 · p. 7
A Reproducibility
The authors preserve experiment records and independently regrade the histories, while documenting the materials and access required for reproduction. Full public reproduction is not claimed for this version.
A Reproducibility
- The checker independently regrades all 336 histories, and a verifier checks coverage, versions, persistence continuity, and aggregate counts.The component cases and existing regressions have separate records.Source: A Reproducibility · p. 7
- Reproductions may differ in checkpoint UUIDs and wall times while preserving scenario definitions and checked outcomes.Exact source and dependency versions must remain visible.Source: A Reproducibility · p. 7
- The publication package includes derived per-history outcomes, replacement-worker timings, aggregate counts, figures, and exact software versions.The reproduction guide provides commands for setup, testing, collection, verification, analysis, and offline PDF generation.Source: A Reproducibility · p. 7
- Full reruns require archived implementation and dependencies, while the InfinityOS component cases additionally require proprietary source; full public reproduction is not claimed.Native storage is temporary and deleted after each experiment.Source: A Reproducibility · p. 7