PaperlayerView exact revision on arXiv

Source-linked AI summary

UndoBench: Separating Task Competence from Recovery Capability in Tool-Using AI Agents

Dolly Sah, Tanmay Sah, Harshul Jain, Tanya Sah

arXiv:2610.05622v1cs.SEcs.AI

TL;DR

Widely used agent benchmarks primarily measure nominal task completion, rather than separating it from recovery under operational faults. UndoBench pairs counterfactual executions and monitors state and external effects; evaluations across mutation boundaries find that recovery is phase-dependent.

  • Problem

    Widely used agent benchmarks primarily evaluate nominal completion, while operational faults can leave agents uncertain whether a remote mutation committed.

    Source: §1 · p. 1

  • Method

    UndoBench pairs identical-seed nominal and faulted trials across enterprise workflows and uses state and wire-effect oracles to assess competence and recovery.

    Source: §1 · p. 2

  • Results

    Recovery is boundary-specific: redispatch is safe before mutation, while verification and server-side deduplication address commit uncertainty after mutation.

    Source: §7 · p. 8

  • Takeaways & Limitations

    Evaluations of autonomous agents should assess operational recovery alongside nominal task completion.

    Source: §8 · p. 8

    Primary confirmatory evaluations focus on two open-weight instruction models, and hosted commercial APIs do not guarantee bitwise generation reproducibility across runs.

    Source: Limitations · p. 9

Abstract

from arXiv · show

Tool-using AI agents are increasingly deployed across enterprise software systems, yet widely used benchmarks primarily evaluate nominal task completion, conflating baseline planning competence with operational fault recovery. We introduce UndoBench, a benchmark spanning 36 base workflows and 36 fault scenarios across 8 enterprise domains, decoupling task competence from recovery capability via counterfactual paired trials under identical seeds alongside wire-level effect-history and environment-state oracles. On 12 held-out TEST workflows across two open-weight models, two frameworks, and three recovery paradigms (5,760 executions / 2,880 paired trials) in the frozen lost-acknowledgment study, nominal competence reached 83.54% while conditional recovery success rate (CRSR) fell to 46.72%, with naive retry producing duplicate external effects in 53.33% of trials. Extensions to commercial API models reproduced this competence-recovery separation. Evaluations across complementary execution boundaries show that recovery is phase-dependent: before mutation, methods perform similarly without duplicate effects among capable trials; during partial mutation, naive retry, per-call idempotency, and zero-privilege journaling collapse on the evaluated composite workflows; after commit but before acknowledgment, verification and server-side idempotency substantially improve safety. These findings demonstrate that evaluating nominal completion alone masks critical, phase-dependent recovery vulnerabilities in autonomous agents.

1 Introduction

Existing agent benchmarks largely measure nominal task completion, leaving recovery from operational faults difficult to assess separately. UndoBench pairs nominal and faulted executions to distinguish task competence from recovery capability and examine failures across the external-mutation lifecycle.

1 Introduction

  • Existing benchmarks largely evaluate unperturbed task completion and do not distinguish nominal planning failures from recovery failures caused by operational faults.They therefore cannot answer whether an agent that solves a workflow nominally can recover safely when an external fault strikes mid-execution.Source: §1 · pp. 1–2
  • A lost acknowledgment can follow a committed remote mutation, so a naive retry may repeat an external effect such as a payment charge.Traditional benchmarks neither inject acknowledgment loss nor inspect wire-level side effects, so they can miss this duplicate-billing failure.Source: §1 · pp. 1–2
  • Reporting only end-to-end task success conflates nominal tool-use competence with the ability to diagnose, reconcile, and safely repair state after a fault.The paper frames recovery behavior as a question of how faults move across the external-mutation lifecycle.Source: §1 · p. 2
  • UndoBench evaluates 36 workflows and 36 fault scenarios across eight enterprise domains, using paired identical-seed trials to separate nominal competence from fault recovery.Its design also includes dual state and wire-effect oracles and a frozen lost-acknowledgment study with 5,760 executions across 2,880 paired trials.Source: §1 · p. 2, Figure 1 · p. 2

2 UndoBench Design

UndoBench separates nominal competence from recovery by pairing faulted executions with identical-seed controls and conditioning recovery measurement on nominal success. It models mutation timing and monitors both external effects and task invariants.

2.1 Problem Formulation and Decoupling

  • Unconditional recovery success can conflate nominal task failure with recovery inability, so UndoBench conditions recovery on paired nominal competence.Paired counterfactual executions use identical seeds; CRSR measures recovery success conditional on a fault and nominal competence.Source: §2.1 · pp. 2–3

2.2 Fault and External-Effect Model

  • A tool call produces an agent-visible return and a remote state transition, which may commit even when the acknowledgment is dropped.The failure taxonomy spans five boundaries, from pre-mutation transport failure through faults during compensation; the primary confirmatory evaluation focuses on post-mutation, pre-acknowledgment faults.Source: §2.2 · p. 3

2.3 Physical Invocations, Committed Mutations, and Semantic Effects

  • UndoBench distinguishes wire-level physical invocations, durable committed mutations, and task-level semantic effects to reveal side effects hidden by terminal-answer evaluation.Wire monitors and programmatic state oracles assess whether recovery preserves required effects without duplicates or corrupted external state.Source: §2.3 · p. 3

2.4 Paired Evaluation and Metrics

  • The paired metrics track nominal control success, unconditional fault success, and recovery among competent trials, while safety metrics track exactly-once, duplicate, unsafe-retry, and missing effects.In the frozen TEST regime, the state oracle requires goal completion with zero duplicate and zero missing effects, making EORcond and CRSR numerically coincide.Source: §2.4 · pp. 3–4

3 Experimental Setup

The confirmatory evaluation uses held-out workflows to compare models, frameworks, and recovery baselines under a frozen lost-acknowledgment setting. Secondary extensions examine commercial models and other mutation boundaries.

3 Experimental Setup

  • The frozen confirmatory study covers 12 held-out TEST workflows, two open-weight models, two frameworks, three recovery baselines, and 20 seeds.This design yields 2,880 paired trials and 5,760 executions; post-freeze extensions examine commercial API models, complementary boundaries, and benchmark-wide idempotency.Source: §3 · p. 4
  • The three recovery baselines are naive retry, idempotency-key deduplication where supported, and EvoUndo-RB1 with a client-side mutation journal.EvoUndo-RB1 uses a crash reconciler after failures.Source: §3 · p. 4
  • EvoUndo-RB1 is constrained to zero privilege, without remote probes or inverse handlers, and defaults to bounded retry on nine compensatable TEST workflows.The authors caution that this benchmark-constrained implementation should not be interpreted as unrestricted EvoUndo.Source: §3 · p. 4
  • Confidence intervals use task-clustered bootstrap resampling and Wilson score intervals, with Holm-Bonferroni adjustment for multiple comparisons.Framework equivalence is tested using TOST with a ±10.0 percentage-point margin.Source: §3 · p. 4

4 Results

Results show a sharp gap between nominal task competence and fault recovery, with recovery outcomes varying by method, execution boundary, model, and framework. Commercial API models reproduce the competence–recovery gap seen in the primary study.

4.1 Competence vs. Recovery

  • 83.54% nominal task success contrasted with 46.72% CRSR and 39.03% RSR across 2,880 paired trials.The paper reports that nominal task success alone overstates reliability under injected faults.Source: §4.1 · pp. 4–5, Figure 2 · p. 5, Table 1 · p. 5

4.2 Recovery-Method Comparison

  • B2 had a descriptive +10.72 pp TEST CRSR advantage over B0, while naive retry produced a 53.33% Duplicate Effect Rate.Deduplication depended on endpoint support; zero-privilege B5 was near parity with B0 (+1.12 pp) and had DER = 51.67%.Source: §4.2 · p. 5, Table 2 · p. 5

4.3 Lost-ACK / UNKNOWN_OUTCOME Analysis

  • Under lost ACK, naive retry duplicated effects in 100.0% of trials across five workflows lacking idempotency or database constraints, while SQLite blocked repeats on RB-DB-004.B2 gains were concentrated on endpoints with idempotency or constraint protection; its overall +10.72 pp TEST CRSR advantage did not establish benchmark-wide statistical superiority.Source: §4.3 · pp. 5–6

4.4 Model and Framework Analysis

  • On common support, M1 reached 44.50% CRSR and M2 54.17%, but the model difference was statistically unresolved; F1 and F2 were equivalent within ±10 pp.The model comparison’s task-clustered 95% CI spanned zero, while TOST supported framework equivalence under the standardized contract.Source: §4.4 · p. 6

4.5 Commercial API Model Extension

  • Commercial APIs reproduced the gap: under naive retry, CRSR was 21.08% for Gemini and 21.89% for GLM, with duplicate mutations in 65.62% and 51.25% of trials.B2’s pooled +11.73 pp improvement was not significant after Holm-Bonferroni correction (padj = 0.0528); B5’s pooled gain was +0.41 pp (Holm padj = 0.9180). F1 and F2 were equivalent within ±10 pp in the extension.Source: §4.5 · pp. 6–7, Table 3 · p. 6

5 Multi-Boundary Recovery Dynamics

Recovery varied sharply with fault timing in evaluations of commercial API models: methods were similar before mutation, several collapsed during partial mutation, and verification or server-side deduplication was more effective after commit.

Main Three-Boundary Interpretation

  • Across the three boundaries, pre-mutation methods were descriptively similar, B0, B2, and B5 reached 0% CRSR during mutation, and verification or server-side deduplication was more effective after commit.The findings frame recovery as a phase-dependent systems property rather than a single scalar capability.Source: §5 · p. 7

Pre-Mutation Execution (PRE_MUTATION)

  • Under PRE_MUTATION, B0 achieved 78.44% CRSR versus 21.48% under POST_MUTATION_PRE_ACK, while capable trials had 0.00% duplicate incidence.The boundary contrast was +56.96 pp, and the paper reports a near-identical contrast on common capable support.Source: §5 · p. 7

Interrupted Mutation (DURING_MUTATION)

  • During mutation, only B6 recovered, reaching 25.89% CRSR; it succeeded on the publicly inspectable Cloud workflow but failed on the other three composite workflows.The reported failures involved a Git lockfile, hidden multipart-upload state, and divergence between partial table creation and uncommitted catalog metadata.Source: §5 · pp. 7–8

6 Mechanism Isolation: Benchmark-Wide Idempotency

Benchmark-wide server-side idempotency substantially raised recovery success in the hosted-model intervention, though some capable trials still failed for reasons unrelated to duplicate effects.

6 Mechanism Isolation: Benchmark-Wide Idempotency

  • 97.24% CRSR for B2-K versus 33.20% for standard B2 on full support, with B2-K at 0.00% DER.Twenty-one of 762 capable B2-K trials still failed: 17 before any tool call and four during multi-turn continuation after duplicate suppression.Source: §6 · p. 8

7 Discussion and Systems Differentiation

UndoBench finds that recovery mechanisms work differently across mutation boundaries, and its audits support the comparability and integrity of the evaluation.

7 Discussion and Systems Differentiation

  • Before mutation, redispatch is safe; during mutation, per-call idempotency cannot restore composite invariants; after commit, server-side deduplication and pre-retry verification address commit uncertainty.The during-mutation challenge is intermediate-state reconciliation, and inspection requires admissible repair actions.Source: §7 · p. 8
  • UndoBench complements systems focused on execution integrity or runtime safety by studying competence-conditioned workflow recovery with paired trials and dual oracles.Its B2-K intervention isolates benchmark-wide idempotency as a targeted contract intervention.Source: §7 · p. 8
  • 100% capable-pair prefix equivalence and 72/72 passing adversarial tests support pair comparability and oracle conformance across the audited conditions.The audits also found zero tool mutations escaping the provider-retry proxy wrapper.Source: §7 · p. 8

8 Conclusion

UndoBench separates task competence from recovery capability and demonstrates phase-dependent recovery dynamics across the mutation lifecycle. The authors conclude that nominal completion alone is insufficient to assess operational recovery.

8 Conclusion

  • UndoBench provides an empirical foundation for resilient agent systems by separating task competence from recovery capability and exposing phase-dependent recovery vulnerabilities.The conclusion also highlights duplicate side effects under lost acknowledgments and dual state and wire oracles.Source: §8 · p. 8

Limitations

UndoBench’s evidence is bounded by its task and fault coverage, model setup, and sandboxed environments.

Limitations

  • The confirmatory study covers 12 independent TEST task clusters; 20 seeds add executions but do not increase the cluster count.Its main study centers on POST_MUTATION_PRE_ACK, while secondary studies cover PRE_MUTATION and four DURING_MUTATION workflows.Source: Limitations · p. 9
  • UndoBench injects one fault per trajectory; cascading, concurrent, or Byzantine failures remain future work.The environments mock enterprise APIs, and production systems have higher concurrency and variable latency distributions.Source: Limitations · p. 9
  • CRSR is undefined when nominal competence is zero, so those cases require joint inspection with unconditional RSR.The limitation passage identifies RB-STOR-005 as an example.Source: Limitations · p. 9

Ethical Considerations

These appendices document UndoBench’s design, evaluation procedures, and instrumentation, while noting limits on interpreting results beyond its simulated, single-fault setting.

Ethical Considerations

  • Benchmark evaluations in sandboxed environments are not a guarantee of safety for unmonitored production deployment or resilience to cascading or adversarial failures.The benchmark evaluates strictly simulated environments under single-fault injection.Source: Ethical Considerations · p. 9

A Benchmark Factorial Design and Task Specifications

  • Table 5 summarizes the factorial design, while Tables 6–7 and Figure 3 cover held-out task composition and task-level performance across 12 TEST workflows.The baseline taxonomy excludes B1, B3, and B4 from the benchmark-wide factorial evaluation for domain or framework reasons; B6 is a post-hoc verification intervention.Source: A Benchmark Factorial Design and Task… · p. 11, Table 5 · p. 11, Table 6 · p. 12

D Zero-Privilege Observability Matrix for Baseline B6

F Statistical Details and TOST Equivalence Tests

H Post-Study Hardware Interoperability Qualification

  • Three additional open-weight model families passed an 8-domain SDK interoperability qualification without benchmark-semantic modifications.These hardware runs are descriptive engineering qualifications, separate from the primary frozen experiment.Source: H Post-Study Hardware Interoperability… · p. 12

J Commercial API Model Extension: Complete Cell Breakdown and Provenance

K Effect Identity and Dual-Oracle Instrumentation

  • UndoBench pairs a final-state oracle for goal invariants with a wire-level oracle for duplicate, missing, out-of-order, or uncompensated mutations.Its effect model records invocation and acknowledgment information; Figure 4 reports that endpoint-supported idempotency eliminates duplicates in corresponding payment workflows.Source: K Effect Identity and Dual-Oracle… · p. 14, Figure 4 · p. 14

C Safety Metrics and Forensic EOR Validation

  • Naive retry produces duplicate side effects in 53.33% of TEST trials, while idempotency eliminates duplicates on supported APIs.Forensic reconstruction found EORcond of 46.72%, numerically identical to CRSR, without rerunning or altering trajectories.Source: C Safety Metrics and Forensic EOR… · p. 11, Figure 5 · p. 15

L Benchmark-Wide Idempotency Intervention: Hosted-Model Evaluation (B2-K)

Benchmark-wide server-side deduplication across all 12 TEST workflows brought recovery close to all capable trials and eliminated duplicate effects, while standard B2 recovered far less often. The remaining B2-K failures arose from provider exceptions or malformed multi-turn continuations, not duplicate side effects.

L Benchmark-Wide Idempotency Intervention: Hosted-Model Evaluation (B2-K)

  • B2-K applied server-side deduplication across all 12 TEST workflows to test whether standard B2's limited gains reflected incomplete endpoint support.The hosted intervention used 960 paired trials / 1,920 runs with Gemini 3.8 Flash and GLM-5.2 MaaS across two frameworks and 20 seeds.Source: L Benchmark-Wide Idempotency… · p. 15
  • 97.24% CRSR (741 / 762) and 0.00% DER (0 / 960) under B2-K, versus 33.20% CRSR for standard B2 on the full TEST suite.On common-capable support, B2-K reached 98.64% CRSR (728 / 738), versus 33.33% CRSR (246 / 738) for standard B2.Source: L Benchmark-Wide Idempotency… · p. 15
  • Among 762 nominally capable B2-K trials, 21 failures came from pre-tool provider exceptions or malformed continuation calls after successful deduplication.The 17 provider exceptions prevented tool initiation; four continuation malformations failed the downstream audit-log requirement, and no duplicate side effects occurred across 960 executions.Source: L Benchmark-Wide Idempotency… · p. 15

M Multi-Boundary Experiments with Commercial API Models

Commercial API extensions report similar pre-mutation recovery rates across four methods, while duplicate effects were confined to trials with nominal control failure. Verification audits support paired comparability and oracle reliability, and a two-workflow ablation illustrates observability-based reconciliation.

M Multi-Boundary Experiments with Commercial API Models

  • 78.44% CRSR for B0, 78.86% CRSR for B2 (+0.43 pp vs. B0), 77.78% CRSR for B5, and 77.34% CRSR for B6.These results cover 12 TEST workflows using Gemini 3.8 Flash and GLM-5.2 MaaS.Source: M Multi-Boundary Experiments with… · pp. 15–16
  • All four methods had 0.00% capable duplicate incidence; every duplicate-effect trial occurred in RB-STOR-005, where nominal control failed (D = 0).The passage attributes those unguided tool executions to nominal control failure.Source: M Multi-Boundary Experiments with… · p. 16
  • +57.34 pp descriptive delta; task-clustered bootstrap estimated the boundary contrast at +57.04 pp (SE = 14.79 pp; 95% CI: [+26.99 pp, +84.90 pp]).The contrast conditions on common capable support (Dcommon = 743), matched by task, model, framework, and seed.Source: M Multi-Boundary Experiments with… · p. 16
  • The DURING_MUTATION extension evaluates four qualified composite workflows in a 16-cell task-by-method matrix, with 1,280 paired trials.The workflows admit faithful partial-mutation semantics.Source: M Multi-Boundary Experiments with… · pp. 16–17, Table 14 · p. 18

N Verification Audits, Oracle Conformance, and Robustness

  • Paired-prefix equivalence was 100.00% for capable pairs in PRE_MUTATION, B2-K, and DURING_MUTATION.Across all pairs, pre-fault prompt divergences were confined to unguided exploratory actions in RB-STOR-005 (D = 0).Source: N Verification Audits, Oracle… · p. 17
  • All 72 adversarial oracle-conformance tests passed, detecting every synthetic perturbation without false positives or false negatives.The tests covered six cases across all 12 TEST contracts.Source: N Verification Audits, Oracle… · p. 17
  • Exactly 12 provider retry events occurred across 8 hosted executions (0.28%); the audit found zero tool mutations escaped the sandbox wrapper.All retries were transport-level prompt retries before tool dispatch.Source: N Verification Audits, Oracle… · p. 17

N.1 Illustrative Analysis: Two-Task Scripted EvoUndo Observability Ablation (B5-P )

  • B2 > B5 ≈ B0 recovery-method ordering remained invariant across support thresholds D > 0, D ≥20, and D ≥40, and all 12 leave-one-task-out folds.A two-workflow B5-P observability ablation reconciled 40 / 40 simulated cases without inverse compensation (100% simulated reconciliation success); it is not a benchmark-wide or model-level estimate.Source: N Verification Audits, Oracle… · p. 17, §N.1 · p. 17

Related papers

Loading 2610.05622v1…