PaperlayerView exact revision on arXiv

Source-linked AI summary

Can Terminal Agents Trust Their Own Verification? Diagnosing and Improving Self-Verification

Yingfeng Luo, Shaowei Wei, Daixin Wang, Dingyang Lin, Kaiyan Chang, Weiqiao Shan, Tong Zheng, Zhiqiang Zhang, Jingbo Zhu, Tong Xiao

arXiv:2609.38812v1cs.CLcs.LG

TL;DR

Terminal agents rely on self-verification, but whether their checks reliably assess candidate correctness is not well established. The paper diagnoses verification and recovery against objective candidate correctness, then distills a teacher’s continuation from student-generated candidates. Across three Qwen3.5 backbones, SCVD improves PASS@1 over both corresponding base models and matched FTD.

  • Problem

    Prior work did not jointly establish agents’ verification outcomes and the objective correctness of the candidates they checked, limiting assessment of self-verification reliability.

    Source: §1 · p. 1

  • Method

    The diagnostic framework evaluates the earliest complete candidate against the official task evaluator, while SCVD trains on a teacher’s verification and recovery continuation from a student-generated candidate.

    Source: §1 · p. 2

  • Results

    9.74–16.85 percentage points over corresponding base models and 4.49–8.61 points over task- and size-matched FTD: SCVD improves PASS@1 across three Qwen3.5 backbones.

    Source: §1 · p. 2

  • Takeaways & Limitations

    Verification is nearly universal, but error detection and repair remain weak points: only 61.43% of incorrect candidates are detected and 49.36% of detected errors are repaired.

    Source: §1 · p. 2

    The analysis focuses on verification after a complete candidate is formed, leaving verification of partial plans, intermediate tool outputs, and individual decisions for future work.

    Source: Discussion and Limitations · p. 10

Abstract

from arXiv · show

Terminal agents rely on self-verification to assess and correct their solutions as they solve tasks through interaction with command-line environments. Yet how trustworthy such self-verification is remains poorly understood. To investigate this question systematically, we introduce a diagnostic framework that identifies the first complete solution in each trajectory, determines whether it is objectively correct, and uses this ground truth to quantify the agent's subsequent verification and recovery behavior. Applying it to ten terminal agents on TerminalBench2.1, we find that verification is nearly universal after a complete candidate is formed, yet only 61.43\% of incorrect candidates are detected and only 49.36\% of detected errors are successfully repaired. These results show that the main weakness in self-verification lies not in initiating verification, but in detecting and repairing errors. Motivated by these findings, we propose Student-Conditioned Verification Distillation (SCVD), which lets the student first produce a candidate solution and distills a stronger teacher's subsequent verification and recovery from the same interaction context. Across three Qwen3.5 backbones, SCVD improves \textsc{Pass@1} on TerminalBench2.1 by 9.74--16.85 percentage points over the corresponding base models and by 4.49--8.61 points over the standard full-trajectory distillation, while avoiding the pronounced out-of-distribution degradation of full-trajectory distillation on SWE-bench Verified.

1 Introduction

The introduction asks whether terminal agents can trust solution-level self-verification, noting that prior work does not jointly compare agents’ checks with objective candidate correctness. It introduces a diagnostic framework and SCVD, which conditions teacher verification and recovery on student-generated candidates.

1 Introduction

  • Earlier work did not jointly establish agents’ verification conclusions and the objective correctness of the candidates they checked, complicating assessment of verification reliability.Without both, a passing check could reflect either a correct solution or an undetected error.Source: §1 · p. 1
  • The diagnostic framework identifies each trajectory’s earliest complete candidate, evaluates it with the official task evaluator, and separately assesses verification initiation, error detection, and repair.It compares agents’ own verification outcomes with candidate correctness by replaying the trajectory up to the candidate boundary in a fresh environment.Source: §1 · p. 2
  • 99.53% of eligible trajectories include verification, but agents detect only 61.43% of incorrect candidates and repair only 49.36% of detected errors.Although 92.65% of error signals correspond to objectively incorrect candidates, only 51.52% of candidates receiving a no-error signal are actually correct.Source: §1 · p. 2
  • 9.74–16.85 percentage points over corresponding base models and 4.49–8.61 points over task- and size-matched FTD: SCVD improves PASS@1 across three Qwen3.5 backbones.The reported comparison is on TerminalBench2.1; the passage also notes that SCVD avoids FTD’s pronounced degradation on SWE-bench Verified.Source: §1 · pp. 2–3

2 Diagnosing Self-Verification in Terminal Agents

The section formalizes self-verification by comparing agents’ checks after a complete candidate with the candidate’s objective correctness and final outcome. Across ten terminal agents, verification is nearly universal, but error detection and repair remain limited.

2 Diagnosing Self-Verification in Terminal Agents

  • The study frames three questions: whether agents verify complete candidates, whether verification outcomes are trustworthy, and whether exposed errors are corrected.It reports initial candidate accuracy alongside final task accuracy to characterize candidate quality and overall task success.Source: §2 · p. 3, §2.2 · p. 4

2.1 Formalizing Solution-Level Self-Verification

  • The framework separates a trajectory at the earliest boundary where a complete candidate exists, then examines verification and recovery in the subsequent interaction.It distinguishes objective candidate correctness, the agent’s verification outcome, and final solution correctness.Source: §2.1 · p. 3

2.2 Diagnostic Framework

  • The diagnostic framework combines trajectory annotation, candidate-state replay, and metrics for verification initiation, verification reliability, and error recovery.LLM judges annotate candidate formation and subsequent verification; replay in a fresh environment applies the official evaluator to reconstructed candidate states.Source: §2.2 · p. 4

2.3 Key Findings

  • 99.53% VTR, 61.43% EDR, and 49.36% RSR show near-universal verification but substantial gaps in detecting incorrect candidates and repairing detected errors.Figure 2 summarizes diagnostic results across models, with ranges and means in panel (a).Source: §2.3 · p. 5, Figure 2 · p. 5
  • 92.65% ESP indicates error signals are usually correct, while 90.25% CPR contrasts with a 51.52% VPR, showing that no-error signals often accompany incorrect candidates.Accuracy rises by 14.6–36.5 percentage points from initial candidates to final solutions across models, averaging 25.4 points; RSR and final task accuracy correlate at Pearson r = 0.98.Source: §2.3 · p. 5

3 Learning to Verify from Student Trajectories

Full-Trajectory Distillation demonstrates verification on teacher-generated candidates, which may differ from students’ inference-time candidates. Student-Conditioned Verification Distillation (SCVD) instead has a student produce the candidate before a stronger teacher verifies and repairs it from the same interaction context.

3 Learning to Verify from Student Trajectories

  • SCVD addresses the mismatch between teacher-generated distillation candidates and student-generated candidates encountered at inference time.The latter may differ substantially in quality and error patterns.Source: §3 · pp. 5–6

3.1 Student-Conditioned Trajectory Collection

  • The student produces the complete candidate, then a stronger teacher continues from the same interaction history and environment state to verify it and demonstrate any recovery.The collection-only instruction directs the teacher to use task-relevant checks, repair defects, and recheck the result.Source: §3.1 · p. 6

3.2 Continuation-Only Distillation

  • SCVD retains successful teacher continuations, removes the collection-only instruction, and trains on the teacher continuation while masking the student-generated prefix from the loss.A correct student candidate can supervise verification and termination; an incorrect one can additionally demonstrate error recovery.Source: §3.2 · p. 6, §3.1 · p. 6

4 Experiments

The experiments evaluate SCVD against Base and FTD on TerminalBench2.1 and SWE-bench Verified, then examine where its gains arise, how prefix source matters, and how inference cost changes.

4.2 Main Results

  • Across Qwen3.5-9B, Qwen3.5-27B, and Qwen3.5-35B-A3B, SCVD raises PASS@1 over corresponding Base models by 9.74, 16.85, and 11.61 points, respectively, and beats task- and size-matched FTD by 8.61, 8.24, and 4.49 points.Source: §4.2 · pp. 6–7
  • On SWE-bench Verified, FTD reduces PASS@1 by 25.87, 6.40, and 12.27 points, while SCVD largely preserves 9B performance and improves 27B and 35B-A3B by 2.20 and 4.27 points.The benchmark comparison is reported in Table 2.Source: §4.2 · p. 7, Table 2 · p. 7

4.3 Where Do SCVD’s Gains Come From?

  • SCVD improves initial candidate accuracy by 5.50 points over Base and raises average post-candidate net gain from 19.73% under Base to 26.97%.Across the three backbones, SCVD’s R2W remains below 2%; the paper reports that gains reflect both pre- and post-candidate improvements, with the larger improvement after candidate formation.Source: §4.3 · p. 7, Figure 3 · p. 8

4.4 Does the Prefix Generator Matter?

  • Student-generated prefixes yield 33.33% mean PASS@1, versus 31.46% and 31.83% for the other Qwen3.5 models and 29.21% for teacher-generated prefixes.The student-prefix result is 4.12 points above the teacher-prefix setting.Source: §4.4 · pp. 7–8, Table 3 · p. 8

4.5 How Does SCVD Affect Inference Efficiency?

  • Across all three backbones, SCVD reduces agent turns by 12.0–35.6%, terminal tool calls by 1.5–17.1%, and total token cost by 0.3–22.4% relative to Base.Generated tokens increase by 2.6–4.1×; fewer interaction rounds reduce repeated processing, keeping total token cost below or close to Base.Source: §4.5 · p. 8

5 Related Work

Prior work studies self-revision, verification, and trajectory distillation through several approaches. This paper focuses on solution-level verification after a complete candidate forms and conditions teacher supervision on student-induced states.

Self-verification in interactive agents

  • Self-Refine and Reflexion use model-generated critiques or reflections, while CRITIC and Self-Debugging ground revision in external tools or execution feedback.Training-based methods SCoRe and S2R optimize multi-turn verification and revision.Source: §5 · p. 8
  • Coding environments provide tests and execution signals, but agent-generated tests can be weak, and separate verifier agents or broader trajectory analyses offer other ways to study failures.The cited work includes agent-generated test studies, verifier or reviewer agents, and trajectory analyses.Source: §5 · pp. 8–9

Distilling interactive agent trajectories

  • Full teacher-trajectory imitation exposes students to teacher-induced states, whereas SCVD supervises verification and recovery after a student forms a complete candidate.Related student-centered and on-policy distillation methods condition expert supervision on learner-generated rollouts.Source: §5 · p. 9

6 Conclusion

The paper analyzes solution-level self-verification in terminal agents and introduces SCVD, which conditions teacher verification and recovery on student-generated candidates. Across three Qwen3.5 backbones, SCVD improves task success over Base and FTD while avoiding FTD’s pronounced out-of-distribution degradation.

6 Conclusion

  • The diagnostic analysis jointly characterizes candidate correctness, agents’ verification outcomes, and final task outcomes.Agents almost always initiate verification, yet many errors go undetected and many detected errors remain unrepaired.Source: §6 · p. 9
  • SCVD distills a stronger teacher’s verification and recovery behavior on student-generated candidate solutions.The student forms a candidate before the teacher continues from that context.Source: §6 · p. 9
  • Across three Qwen3.5 backbones, SCVD improves task success over Base and FTD while avoiding FTD’s pronounced out-of-distribution degradation.The paper identifies error detection and recovery as central challenges for reliable self-verification.Source: §6 · p. 9

AI Use Statement

The authors report using generative AI in the research methodology and manuscript preparation, with outputs reviewed and verified by the authors.

AI Use Statement

  • LLM-based trajectory annotation and teacher verification-and-recovery trajectory generation were part of the research methodology.Source: AI Use Statement · p. 9
  • Generative AI tools also assisted with language editing and improving the manuscript’s clarity and organization.Source: AI Use Statement · p. 9
  • The authors reviewed and verified AI-assisted outputs and analyses and take full responsibility for the final work.Source: AI Use Statement · p. 9

Discussion and Limitations

Post-candidate interaction can materially improve solutions, but realizing that potential requires checks that produce diagnostic evidence and guide revision. The paper illustrates this process with a candidate that fails compilation, receives actionable feedback, and is repaired.

Discussion and Limitations

  • Post-candidate interaction can materially change task outcomes, but teaching agents to produce diagnostic checks and use their evidence for revision remains open.The gap between initial candidate accuracy and final task accuracy indicates that this stage can still improve solutions at test time.Source: Discussion and Limitations · p. 10
  • Because verification and repair depend on the candidate, SCVD conditions the teacher continuation on a student-produced solution; its gains in initial-candidate accuracy raise a question about effects before candidate formation.The paper leaves how this supervision shapes pre-candidate behavior for future work.Source: Discussion and Limitations · p. 10
  • The analysis covers solution-level verification after complete candidates, not checks of partial plans, intermediate tool outputs, or individual decisions.The paper identifies these finer-grained forms and their failure modes as future research directions.Source: Discussion and Limitations · p. 10

A Example of Solution-Level Self-Verification

Agent content: constructing the initial candidate

  • The first complete proof candidate is objectively incorrect: replaying the official evaluator at its boundary returns yc = 0, although the agent initially plans to compile it.The candidate boundary is placed immediately after the tool call that produced the complete, submit-ready proof.Source: Agent content: constructing the… · p. 14

Agent tool calls: solution-level verification

Agent tool calls: revising the candidate and checking it again

Agent content: stopping decision

The trace ends with a successful official evaluation after the candidate fails an earlier check and is repaired.

Agent content: stopping decision

  • The final official evaluation passes (yf = 1), completing a trajectory whose initial candidate was incorrect and whose verification outcome was error.The full diagnostic state is (yc, z, yf) = (0, error, 1).Source: Agent content: stopping decision · p. 16
  • The trace shows a task-relevant check turning an incorrect candidate into actionable feedback that supports repair and a correct stopping decision.The successful ending follows compilation feedback and revision.Source: Agent content: stopping decision · p. 16

B Diagnostic Details and Full Results

The diagnostic procedure combines multi-judge trajectory annotation with replay of candidate states under the official evaluator. Calibration, agreement, and replay coverage are reported for the resulting analysis.

B.1 Annotation Protocol

  • Three LLM judges independently annotate each trajectory, and a manually reviewed set of 20 trajectories is used to calibrate the annotation procedure.The study collects three runs on 89 TerminalBench2.1 tasks per model using Terminus-2; judges do not see official task rewards.Source: §B.1 · p. 16
  • The calibration judges achieve joint accuracies of 86.67%, 76.67%, and 83.33%, respectively, across candidate formation, verification triggering, and verification outcome.The authors report these results as empirical support for annotation reliability at scale.Source: §B.1 · p. 16
  • Candidate boundaries are annotated at the exact tool-call level, so replay stops after the call that first makes the solution materially complete.This avoids including later calls in the same agent step that may already perform verification.Source: §B.1 · p. 16
  • A majority vote resolves 96.03% of trajectories; the remaining 3.97% use the DeepSeek-V4-Pro-0813 annotation as tie-breaker.Three-way exact agreement is 74.29% for candidate boundaries and 85.16% for verification semantics.Source: §B.1 · p. 16

B.2 Candidate-State Replay

  • Replay reconstructs the candidate in a fresh environment and invokes the official evaluator; 2,498 of 2,549 submitted replays produce valid labels (98.00%).Failed replays and invalid evaluator outputs are excluded.Source: §B.2 · p. 16

B.3 Dependence on the Agent Scaffold

The diagnostic findings use Terminus-2 as a shared scaffold, and the authors interpret the high verification rate in that setting rather than as a scaffold-independent rate.

B.3 Dependence on the Agent Scaffold

  • The near-universal verification rate should be interpreted in the context of the Terminus-2 scaffold used for all diagnostic experiments.Its protocol uses a single tmux-based terminal interface and does not explicitly instruct verification or automatically invoke a verification module.Source: §B.3 · pp. 16–17
  • Table 4 reports candidate-formation and candidate-state replay coverage on TerminalBench2.1, while Table 5 identifies initial and final accuracy metrics among its diagnostics.The supplied captions do not provide the table cell values.Source: Table 4 · p. 17, Table 5 · p. 17
  • The scaffold does not explicitly prescribe verification, and the reported annotation rule counts only checks that obtain external evidence about task satisfaction.The authors regard the high rate under this lightweight setup as evidence that checking can arise without a dedicated verification mechanism.Source: §B.3 · p. 17

C Inference Cost Details

This section describes inference-cost accounting on common-success tasks, with Pass@1 evaluated across all 89 tasks, and highlights verification practices involving task-aligned artifact evidence, careful interpretation of checks, and rechecking after repairs or stateful tests.

C Inference Cost Details

  • N counts tasks solved at least once by Base, FTD, and SCVD; inference costs are averaged over successful runs per task, then macro-averaged across common-success tasks.Token counts are reported in thousands, and terminal tool-call counts exclude the scaffold’s completion signal.Source: C Inference Cost Details · p. 17
  • PASS@1 covers all 89 TerminalBench2.1 tasks, whereas inference costs are measured on common-success tasks within each backbone.Table 7 reports detailed performance and inference-cost statistics.Source: Table 7 · p. 18

TRAJECTORY

  • Check required behavior directly, compare contractual outputs and protected state exactly, and use repeated measurements with an appropriate statistic and safety margin for stochastic or performance requirements.A single favorable run is not enough.Source: TRAJECTORY · p. 22
  • When exact references or evaluator-only inputs are unavailable, use the strongest independent surrogate and state remaining uncertainty; mocks or temporary fixtures cannot prove final integration.Properties, differential checks, round trips, and fresh proxy inputs are examples of surrogates.Source: TRAJECTORY · p. 22
  • Run destructive or stateful checks on copies or temporary state when possible, then recheck the final artifact and any persistent state that matters.Bound potentially blocking commands and clean up temporary state without removing required artifacts or services.Source: TRAJECTORY · p. 22
  • Do not change task-provided tests, acceptance criteria, or the deliverable merely to make a diagnostic check pass or convenient.Replace the diagnostic method rather than altering a deliverable to suit it.Source: TRAJECTORY · p. 22
  • When a check fails or is unclear, distinguish an artifact defect from a faulty check, environment limitation, or ambiguous evidence; change the artifact only when evidence supports a real defect.A broken check is not proof that the result is wrong, and a passing but irrelevant check is not proof that it is correct.Source: TRAJECTORY · p. 22
  • For a confirmed defect, repair the smallest relevant root cause, rerun the failed or stronger check on the repaired final state, and stop only when core conditions have strong evidence and no actionable limitation remains.Set task_complete to true only after that stopping condition is met.Source: TRAJECTORY · p. 22

Related papers

Loading 2609.38812v1…