PaperlayerView exact revision on arXiv

Source-linked AI summary

Sentry: Learning to Recover from LLM Agent Failures at Test Time

Changxiu Ji, Amy Lu, Qizheng Zhang, Kunle Olukotun

arXiv:2610.02994v1cs.LGcs.AIcs.CL

TL;DR

LLM agents can fail during multi-step tasks, and existing ways of learning from failures either expose lessons too broadly or fail to learn from interventions. Sentry retrieves external playbook lessons only after a matching failure and retains them only after verifying recovery. It outperforms runtime-intervention baselines across benchmarks and context-evolution baselines on the two benchmarks where both are evaluated.

  • Problem

    Context-evolution methods expose lessons before a failure is known to apply, while runtime interventions respond to failures but do not learn from their repairs.

    Source: §2 · p. 2

  • Method

    Sentry retrieves matching lessons from an external playbook after diagnosing a failure, verifies recovery without task rewards, and stores a lesson only if recovery succeeds.

    Source: §1 · p. 2, §3 · p. 3

  • Results

    Sentry outperforms the strongest runtime-intervention baseline on every benchmark by 37% on average and ACE by 39% on two benchmarks.

    Source: §1 · p. 2, §5.1 · p. 6

  • Takeaways & Limitations

    Learned lessons transfer to held-out tasks, while exposing the same playbook persistently lowers performance.

    Source: §1 · p. 2, §6 · p. 9

    Experiments use Qwen3.5-9B and GPT-OSS-120B, so failure patterns may differ for other models and agent settings.

    Source: §6 · p. 9

Abstract

from arXiv · show

LLM agents often fail mid-task due to invalid tool calls, repeated actions, or poorly grounded reasoning, and learning from these failures is a path to reliability. We find that how failure knowledge reaches the agent matters as much as what it contains. Failure lessons are conditional: kept in the agent's context, they misfire when their failure is absent, and removing them from an evolving playbook improves performance. Runtime interventions, in contrast, act only when a failure occurs but do not learn from their repairs. We argue that failure knowledge is conditional knowledge and should be conditionally exposed, and instantiate this principle in Sentry, a failure-management layer that runs alongside the agent. When Sentry detects a failure, it retrieves matching lessons from an external playbook to guide recovery, verifies without access to task rewards whether the agent recovered, and stores a new lesson only if it did; the full playbook never enters the agent's context. Across multiple agentic benchmarks, Sentry outperforms the strongest runtime-intervention baseline on every benchmark, by 37\% on average, and the strongest context-evolution baseline by 39\% on the two benchmarks where both are evaluated; combining Sentry with context evolution yields further gains. Learned lessons transfer to held-out tasks, and controlled experiments show that exposing the full playbook to the agent lowers performance even when relevant lessons remain available on demand.

1 Introduction

Agents often fail during multi-step tasks, while existing approaches either expose failure lessons too broadly or intervene without learning from repairs. The paper argues for conditionally exposing failure knowledge and presents Sentry as an implementation of that principle.

1 Introduction

  • Removing failure lessons from ACE improves held-out results, while persistent playbook exposure lowers WebShop reward even when lessons remain available on demand.Pruning raises WebShop reward from 0.335 to 0.391 and Mind2Web Replay completion from 0.562 to 0.643; persistent exposure lowers WebShop reward from 0.364 to 0.296.Source: §1 · p. 1
  • Failure lessons are conditional knowledge: they should accumulate across tasks but reach the agent only when a matching failure occurs.Lessons left in context can distract the agent when the relevant failure is absent.Source: §1 · pp. 1–2
  • Sentry retrieves matching lessons from an external playbook after a diagnosed failure, verifies recovery without task rewards, and stores a lesson only after successful recovery.The full playbook never enters the agent’s context.Source: §1 · p. 2
  • Sentry beats the strongest runtime-intervention baseline on every benchmark by 37% on average and ACE by 39%.The comparisons span WebShop, AppWorld, SWE-bench Lite, and Mind2Web Replay; the runtime-baseline gain reaches 77%.Source: §1 · p. 2
  • Sentry’s guidance improves local recovery, learned lessons transfer to held-out tasks, and human annotators agree with its intervention and recovery judgments in 86.0% and 81.8% of cases.Paired forks from 200 intervention points show local recovery rising from 33.5% to 60.5%.Source: §1 · p. 2

2 Background and Motivation

Context-evolution methods learn across tasks but expose lessons before knowing whether they apply, whereas runtime interventions respond to current failures but do not learn their boundaries. The paper motivates failure-triggered exposure of retained lessons.

2 Background and Motivation

  • Context-evolution methods select lessons before execution and keep them in context, although whether a failure lesson applies depends on the agent’s state mid-trajectory.The agent must judge at each step which lessons apply; in the illustrated case, rules keep it comparing products after finding a match.Source: §2 · p. 2
  • Runtime interventions condition on the current trajectory but use fixed knowledge, so a rule that detects a genuine stall can also misfire during valid actions.Figure 1 contrasts persistent ACE rules that leave the agent comparing alternatives with a fixed AgentGuard warning that causes valid selections to be lost later.Source: §2 · pp. 2–3, Figure 1 · p. 3
  • Pruning failure-mode lessons improves held-out performance, but it also discards their potential help when the failure occurs.With the same playbook, failure-triggered exposure outperforms persistent exposure.Source: §2 · p. 3
  • Failure knowledge should be learned across tasks, surfaced only after a mid-trajectory failure diagnosis, and admitted only after recovery is verified.These three properties motivate Sentry’s design.Source: §2 · p. 3

3 Sentry: A Framework for Test-Time LLM Agent Failure Recovery

Sentry runs alongside the task agent, routes detected failures to appropriate repairs, and keeps an evolving recovery playbook outside persistent context. It uses failure-conditioned retrieval and recovery verification to determine what guidance is shown and what lessons are retained.

3 Sentry: A Framework for Test-Time LLM Agent Failure Recovery

  • Sentry routes invalid actions to hard repair and progress or reasoning–grounding failures to soft repair, then verifies recovery and adds only verified soft-repair lessons to its external playbook.The complete playbook stays outside persistent agent context; retrieved entries enter the intervention conversation.Source: §3 · p. 3, Figure 2 · p. 4

3.1 Failure detection and routing

  • Sentry checks action validity first; valid actions are screened for repetition, stalled progress, unsupported claims, or reasoning–action mismatch before any intervention.When no failure is detected, execution continues without playbook retrieval.Source: §3.1 · pp. 3–4

3.2 Soft repair with playbook retrieval

  • For soft repair, Sentry retrieves at most five entries matching the diagnosed failure type and at least one retrieval label, then uses them with local evidence to guide the next step.When no entry shares a retrieval label, retrieval falls back to the most recent entries of the same failure type.Source: §3.2 · p. 4

3.3 Recovery verification and playbook update

  • Soft-repair verification checks the next ten reasoning–action–observation cycles for the failure pattern to stop and task-relevant, observation-grounded progress to resume.The verifier has no access to benchmark rewards or final task-success labels; unresolved episodes add no playbook entry.Source: §3.3 · p. 5

4 Experimental Setup

The evaluation spans four agentic benchmarks, compares runtime-intervention and context-evolution baselines, and uses distinct online-from-scratch and held-out protocols.

4.1 Benchmarks and Metrics

  • Four benchmarks cover web interaction, software engineering, and stateful app-based tool use, with benchmark-specific primary metrics.Mind2Web Replay is an interactive adaptation where rejected actions can be retried; its scores are not comparable to official step-wise Mind2Web metrics.Source: §4.1 · p. 5

4.2 Baselines

  • The comparisons include four runtime-intervention baselines, four context-evolution baselines, Base, and ACE+Sentry.ACE+Sentry adds Sentry’s failure manager to ACE.Source: §4.2 · p. 5

4.3 Implementation Details and Evaluation Protocols

  • Runtime comparisons and ablations use online-from-scratch learning, while context-evolution comparisons and analyses use a held-out protocol.Held-out methods initialize memory on 50 tasks and are scored on 50 disjoint tasks; the default model is Qwen3.5-9B, GPT-OSS-120B is also evaluated, and results are means ± standard deviations across five runs.Source: §4.3 · p. 5, Table 1 · p. 6, Table 2 · p. 6

5 Results

Across four benchmarks, Sentry beats the strongest runtime-intervention baseline by 37% on average and ACE by 39% where evaluated. Recovery analyses, ablations, held-out tests, and robustness results further characterize its performance.

5.1 Main results

  • Sentry outperformed the strongest runtime-intervention baseline by 37% on average and ACE by 39% on evaluated comparisons.Adding Sentry to ACE gave the best result on both benchmarks where the combination was evaluated.Source: §5.1 · p. 6

5.2 Intervention effectiveness and human validation

  • Sentry resolved 81.7% of 939 detected failures; action-validity recovery reached 92.6%, versus 64.0% for progress and 70.2% for reasoning–grounding.Progress recovery was especially difficult on SWE-bench Lite, at 34.0%.Source: §5.2 · p. 6, Figure 3 · p. 7
  • Soft repair raised local recovery from 33.5% to 60.5%; human agreement was 86.0% for intervention decisions, and 85.8% of interventions were judged locally helpful.Across 200 paired checkpoints, the intervened branch scored higher in 74, tied in 101, and scored lower in 25; inter-annotator agreement was κ = 0.82–0.89.Source: §5.2 · p. 7

5.3 Ablations

  • Removing the intervention-need check caused the largest average relative drop (54.7%); removing soft repair reduced performance by 41.9% on WebShop and 30.3% on AppWorld.Removing self-evolution, failure-specific retrieval, and recovery verification reduced performance by 31%, 26%, and 20% on average, respectively.Source: §5.3 · p. 7, Table 3 · p. 8
  • On held-out tasks, frozen retrieval raised WebShop reward from 0.251 to 0.364 and Mind2Web Replay completion from 0.533 to 0.651; verified updates raised these to 0.495 and 0.729.The playbook was initialized on 50 tasks and evaluated on 50 disjoint tasks.Source: §5.3 · p. 7, Table 4 · p. 8
  • Persistent playbook exposure lowered WebShop reward from 0.364 to 0.296 and Mind2Web Replay completion from 0.651 to 0.599.The comparison retained failure-triggered retrieval and intervention; only the exposure setting differed between the frozen variants.Source: §5.3 · p. 8, Table 4 · p. 8
  • Relative to Full Sentry, broad-type, unfiltered, and random retrieval reduced performance by approximately 11.3%, 18.8%, and 28.9%, respectively.Relative to k = 5, k = 3 and k = 10 reduced performance by approximately 4.5% and 6.2%, respectively; label-filtered k = 5 was the default.Source: §5.3 · p. 8

5.4 Efficiency and robustness

  • With GPT-OSS-120B, Sentry outperformed the strongest runtime-intervention baseline by 51% on average.Sentry used 1.54× the base agent’s tokens versus 2.44× for AgentForesight; it added 7.1s on WebShop and 46.0s on Mind2Web Replay, but removed 31.7s on SWE-bench Lite and 45.6s on AppWorld.Source: §5.4 · p. 9, Table 5 · p. 9

6 Conclusion and limitations

Sentry conditionally surfaces verified recovery lessons from an external playbook and outperforms runtime-intervention baselines on four benchmarks and context-evolution baselines on two. The experiments are limited to two models and settings, and the playbook may accumulate redundant or overly specific entries.

Conclusion

  • Sentry outperforms runtime-intervention baselines on four benchmarks and context-evolution baselines on two, transfers lessons to held-out tasks, and persistent playbook exposure lowers performance.The conclusion also reports that combining Sentry with context evolution yields further gains.Source: §6 · p. 9

Limitations

  • Experiments use Qwen3.5-9B and GPT-OSS-120B, so failure patterns for other models and agent settings remain uncertain.Sentry also uses the same model as task agent, detector, and verifier; decoupled detector and verifier models remain to be studied.Source: §6 · p. 9
  • The playbook may accumulate redundant or overly specific entries, motivating confidence-based admission, merging, and pruning.These are proposed directions for managing the evolving playbook.Source: §6 · p. 10

A.1.1 Context Evolution

Context-evolution methods accumulate reusable experience across tasks and expose it during future executions. Sentry instead keeps failure-recovery memory outside persistent context and surfaces relevant lessons only after a matching runtime failure.

A.1.1 Context Evolution

  • Context-evolution methods reuse experience from prior tasks as reflections, workflows, reasoning strategies, or evolving playbooks.Examples include Reflexion, AWM, ReasoningBank, and ACE [15] [18] [21] [30].Source: §A.1.1 · p. 13
  • Other approaches reuse prior experience through retrieved insights or executable skills, while GEPA evolves prompts from execution feedback.The passage names ExpeL and Voyager [20] [31] and GEPA [1].Source: §A.1.1 · p. 13
  • Sentry restricts persistent memory to failure-recovery experience, keeps it outside persistent task-agent context, and introduces relevant lessons only after a matching runtime failure.The design is complementary to task-level context evolution, as examined in ACE+Sentry experiments.Source: §A.1.1 · p. 13

A.1.2 Runtime Intervention

Runtime-intervention methods monitor current executions and provide corrective feedback when intervention criteria are met. Sentry adds persistent, cross-task learning from verified recovery experience.

A.1.2 Runtime Intervention

  • Runtime-intervention methods monitor trajectories and provide corrective feedback when intervention criteria are met.AgentGuard, AgentForesight, Wink, and AgentFixer combine runtime monitoring, failure prediction, validation, and corrective guidance in different ways [8] [12] [13] [28].Source: §A.1.2 · p. 13
  • Self-Refine and CRITIC improve a current attempt through critique or external feedback, while Dubey [5] studies monitoring, deterministic checks, and rollback-and-rerun repair.These approaches are related feedback-driven or lightweight monitoring mechanisms.Source: §A.1.2 · p. 13
  • Sentry retains verified recovery experience across tasks, retrieving principles learned from earlier successful repairs rather than generating each intervention only from the current trajectory.This distinguishes its runtime interventions from methods relying solely on the current execution.Source: §A.1.2 · p. 13

A.1.3 Harness Adaptation and Failure Diagnosis

Harness-adaptation work modifies the components mediating observations, tool use, and execution, while failure-analysis work characterizes breakdowns. Sentry instead uses operational failure categories to route repairs and retrieve recovery lessons.

A.1.3 Harness Adaptation and Failure Diagnosis

  • Life-Harness, AutoHarness, Self-Harness, and HarnessFix adapt or synthesize harness components from observed failures.Sentry does not modify its monitoring, routing, or retrieval procedures during execution; its evolving state is external recovery knowledge.Source: §A.1.3 · p. 13
  • Failure-analysis work characterizes breakdowns across planning, reasoning, memory, action, and system-level execution.Examples include MAST and AgentErrorTaxonomy, AgentErrorBench, and AgentDebug [32].Source: §A.1.3 · p. 13
  • Sentry uses failure types operationally to determine whether to intervene, which repair route to use, and which recovery lessons to retrieve.This operational categorization differs from work focused on analyzing failure modes.Source: §A.1.3 · p. 13

A.2 Detailed Motivating Examples

Figure 4 expands two Figure 1 trajectories from Qwen3.5-9B on WebShop, showing an ACE context-evolution case and two outcomes from AgentGuard's fixed warning.

A.2 Detailed Motivating Examples

  • In task 4494, ACE's rules from task 6594 persist in context, but the agent keeps comparing alternatives after finding a matching item and takes no action.Source: Figure 4 · p. 14
  • In task 3980, AgentGuard's fixed warning helps the agent recover from repeated searches, but no recovery lesson is stored.Source: Figure 4 · p. 14
  • In task 4585, the same warning follows valid option selections that leave the page unchanged, and the agent buys the item without those options.Source: Figure 4 · p. 14

A.3 Experimental Setup Details

This appendix details Sentry’s experimental setup and failure-management procedures, including benchmark, model, memory, evaluation, retrieval, and verification controls. It also reports supplementary results and analyses, including component ablations, a human audit, and an illustrative WebShop repair example.

A.3.1 Benchmarks and Metrics

  • The evaluation uses 100 tasks each for WebShop, AppWorld, and Mind2Web Replay, and 50 for SWE-bench Lite, with benchmark-specific reward, pass-rate, resolution, or trajectory-completion metrics.Task sets are sampled from eligible tasks and remain fixed across compared methods and repeated runs.Source: §A.3.1 · p. 15
  • Mind2Web Replay preserves recorded tasks, states, and target actions while adding retries after incorrect actions, enabling recovery evaluation in a controlled setting.Its trajectory-completion scores are not directly comparable to original Mind2Web step-wise metrics.Source: §A.3.1 · pp. 15–16

A.3.2 Baseline Implementations

  • Runtime methods share the Qwen3.5-9B backbone and a 384-token task-agent output limit; context baselines use official method-specific memory procedures.ACE+Sentry keeps the task-level and recovery playbooks separate, with Sentry retrieving only when soft repair is triggered.Source: §A.3.2 · pp. 16–18

A.4.1 Evaluation Protocols

  • Online runs start with an empty Sentry recovery playbook, while held-out evaluation uses 50 initialization tasks and 50 disjoint evaluation tasks; updates use only information seen so far.In the frozen-playbook exposure control, the only difference is whether the complete playbook is also placed in persistent context; failure-triggered retrieval remains enabled in both conditions.Source: §A.4.1 · p. 19

A.5.1 Full Benchmark Results

  • Tables 6–9 provide the complete runtime-intervention results, including benchmark-specific secondary metrics and intervention-level diagnostics.The tables expand the main-text comparison in Table 1.Source: §A.5.1 · p. 19, Table 6 · p. 19, Table 7 · p. 20

A.5.2 Results with GPT-OSS-120B

  • With GPT-OSS-120B, Sentry has the highest measured primary task metric on WebShop and Mind2Web Replay, but this evaluation covers only two of the four benchmarks.The results are reported in Table 10.Source: §A.5.2 · p. 20, Table 10 · p. 21

A.6.1 Paired Soft-Repair Evaluation

  • The paired soft-repair evaluation forks 200 checkpoints across four benchmarks, compares identical pre-intervention states with and without guidance, and allows no further interventions.Local recovery is measured after H = 10 steps, after which both branches continue to the benchmark-specific final metric.Source: §A.6.1 · p. 20

A.6.2 Component Ablations

  • Component ablations use Full Sentry’s task sets and online-from-scratch protocol, separately disabling schema-invalid-action hard repair or progress and reasoning-grounding soft repair.Removing soft repair also removes the source of new recovery entries, while hard repair remains enabled.Source: §A.6.2 · p. 21
  • Full Sentry outperforms every component-ablated variant on WebShop and AppWorld; every ablation reduces the primary task metric.The ablations cover selective intervention, soft and hard repair, playbook evolution, failure-conditioned retrieval, and recovery verification.Source: §A.6.2 · p. 22

A.6.3 Held-Out Playbook Controls

  • Held-out controls compare retrieval-disabled, frozen, persistently exposed, and evolving playbooks across 50 initialization and 50 disjoint evaluation tasks.The frozen-playbook exposure comparison holds the setup fixed except for placing the complete playbook in the agent’s background context.Source: §A.6.3 · p. 23

A.6.4 Retrieval Ablations

  • Retrieval ablations vary selection from random or unfiltered entries to failure-type-only or label-filtered entries, with label-filtered k ∈{3, 5, 10} and default k = 5.All other Sentry components are held fixed.Source: §A.6.4 · p. 23

A.6.5 Hyperparameter Sensitivity

  • Hyperparameter sensitivity tests context-window W ∈{1, 3, 5, 7, 10, 15} and recovery horizon H ∈{3, 5, 10, 20} on WebShop, with defaults W = 5 and H = 10.Other components and settings are held fixed for each sweep.Source: §A.6.5 · pp. 23–24

A.7 Human Evaluation

  • Human audit results were 86.0% intervention accuracy, 81.8% recovery-judge accuracy, and 85.8% helpful rate.The audit compared Sentry’s judgments with consensus labels; recovery-judge accuracy was the lowest metric on every benchmark, while annotator agreement had κ between 0.82 and 0.89.Source: §A.7 · pp. 25–26, Table 18 · p. 26

A.8.1 Failure category and retrieval label definitions

  • Sentry groups failures into invalid actions, unproductive progress, and reasoning or grounding failures, with retrieval labels refining the latter two categories.Progress examples include repetition, planning stalls, over-exploration, and termination errors; reasoning or grounding examples include hallucination, objective drift, and reasoning-action mismatch.Source: §A.8.1 · pp. 26–27

A.8.2 Retrieval and update rules

  • Sentry retrieves entries matching failure type and at least one label, ranks by label overlap with recency as a tiebreaker, and adds a verified recovery to the playbook only after H cycles.It selects up to five entries with a diversity cap when possible, falling back to the most recent same-type entries if no label matches; injected guidance remains top-k bounded.Source: §A.8.2 · p. 27

A.8.3 Sentry prompt templates

  • Sentry’s prompt templates specify detector inputs and failure diagnoses, schema-correct hard repair, and soft repair using general advice, local evidence, and retrieved recovery lessons.The soft-repair prompt directs the agent to continue the original task from a corrected next step.Source: §A.8.3 · pp. 27–29
  • The verifier checks whether the diagnosed behavior stops and valid, task-relevant, observation-grounded progress resumes, rejecting persistent failure, further drift, or unsupported assumptions.It judges the specific retrieval labels and resolution criteria rather than generic task success alone.Source: §A.8.3 · p. 29
  • Playbook updates summarize only verified successful repairs into concise entries with a failure type, subtype, trigger pattern, and repair principle.Entries should be specific enough to help with similar future failures without applying only to the original trajectory.Source: §A.8.3 · p. 30

A.8.4 Example playbook

  • WebShop lessons address repetition and planning stalls by recommending meaningful query changes, state-changing actions, and concrete checks of candidate items or attributes.The examples advise against repeating unproductive searches or restating the goal when an actionable next step is available.Source: §A.8.4 · p. 30
  • Lessons for over-exploration and termination miscalibration recommend inspecting plausible candidates and committing when constraints are met, especially near the action limit.They advise direct comparison of visible candidates and using a valid purchase action rather than continuing broad searches or stopping before purchase.Source: §A.8.4 · pp. 30–31
  • Grounding and objective-drift lessons prohibit inferring unseen attributes or abandoning the user's hard constraints for a merely similar, popular, or cheaper item.When attributes are missing, verify them through visible options or choose another candidate.Source: §A.8.4 · p. 31
  • Reasoning-action mismatch lessons require the agent's click target and next action to align with its stated reasoning, the promising candidate, and visible controls.Source: §A.8.4 · p. 31
Loading 2610.02994v1…