Modifiable but Unverifiable: Three Questions That Expose the "Half-Loop" Problem in Recursive Self-Improvement

*Source: ByteDance Seed × TokenWave — benchmarks Aspire, S³Gym, HarnessDev (arXiv: 2608.31111, 2608.31100, 2609.01437)*

The Core Argument: Half-Loop vs. Closed-Loop

Most systems called "recursive self-improvement" (RSI) today share a structure: the model produces changes → a verifier judges them → changes are adopted → next round. The loop is closed, but its direction is not earned by the system itself. It is granted by an external Golden Verifier. The authors call this a half-loop.

As the paper puts it: existing work starts "after humans have operationalized a broad capability request — e.g., 'improve math reasoning' — into a fixed task-level objective — e.g., 'improve AIME scores'." The hardest step has always been performed by humans.

> "Most recursive self-improvement (RSI) systems discussed today are half-loop. They assume a Golden Verifier that keeps the model moving in the right direction."

The authors' claim is measured: *most checks agents can apply to themselves are too weak to distinguish real gains from local gains.* The problem is not that agents can't modify themselves — it's that they can't verify their own modifications.

Three Questions, Three Benchmarks

| Loop stage | Benchmark | Question | Verification method | arXiv | |---|---|---|---|---| | Goals | Aspire | Can an agent decide what to learn from a vague goal? | Hidden 520-question expert evaluation | 2608.31111 | | Experience | S³Gym | Can experience be turned into better next decisions? | Seven games with executable verifiers | 2608.31100 | | System | HarnessDev | Can models create and evolve their own harness? | Frozen held-out eval + re-run on fixed executor | 2609.01437 |

Shared design principle: signals shown to the agent during development must be separated from signals that determine the final score. The authors note they guarantee separation of access and timing, not full sample disjointness.

Aspire: Thirty Cells, One Survivor

Agents receive a broad capability goal without knowing the downstream task or scoring, then self-direct sub-goals, data, and training. A hidden 520-question expert evaluation with a retention threshold decides adoption.

Main funnel:

• 30 configuration–goal cells → 28 produced evaluated checkpoints → 21 reached qualified checkpoints → 2 beat the base model → only 1 passed the retention threshold

The damning curve: Qwen3.5-4B self-training checkpoints rose steadily (0.79 → 1.75 → 2.38) while the un-evolved baseline sat at 17.86 — a gap of −15.48. The authors' caption: *"Local gain, global regression."*

How vague goals distort search (48 matched Opus 4.8 run pairs):

• Active training/evaluation time: −76 minutes
• Decision deliberation and idle GPU time: +35 / +37 minutes
• Trajectory density: task-definition reading 2.98×, eval-script reading 2.39×, LoRA/PEFT activity 3.09×; LoRA usage jumped from 24.1% to 89.8%

This is evidence of *more* goal operationalization, not *better* goals.

Other findings:

• The best evolved harness (27.22) still trailed the engineered Qwen-Agent reference (28.64), by only 1.42.
• Improvement is not monotonic — continued search can erase earlier gains; checkpointing and regression comparison are mandatory.
• The sole positive case (9B science goal, 45.330 → 48.000, Δ +2.670) was fragile: only 26/75 questions were answered correctly in both runs; 20/75 flipped.

Failure case studies: training on mismatched data (30/32 imports used math data for a science goal); collapsing an instruct model via SFT on digit-label MMLU (21,000 single-digit targets, HealthBench 31.68 → 12.62); stopping search early after gaming its own 8-item checklist; one deleted reviewer edit causing ~70% of a score collapse (75.00/52.33 → 2.57/2.91); writing a sanity check that never triggers. The common thread: none of these are capability failures — all are judgment failures.

S³Gym: No Universal Memory

S³Gym decomposes the experience loop into Self-Testing, Self-Judging, Self-Improvement across seven games with executable verifiers (Chess, Minesweeper, Nullify, Tetris, Snake, PvZ, Trust), comparing three experience formats: 1. Raw history in context (History ICL) 2. Compressed summary memory (Summary Memory) 3. Direct parameter training (Parameter Training)

The key takeaway from this section: there is no universal memory format that reliably converts accumulated experience into better next decisions — the value of experience depends critically on the format and the verification loop it passes through.

HarnessDev: Running Is Not the Same as Surviving

HarnessDev asks whether LLMs can build a runnable agent harness and evolve it from downstream execution feedback. Verification requires frozen artifacts evaluated on held-out tasks, then re-run under a fixed executor the agent does not control. The section's warning: a mechanism that runs at submission time is not the same as a mechanism that survives — "dead code" checks that never fire recur here (echoing the zero-trigger check in Aspire).

The Checklist You Can Steal

Across all three benchmarks, the unifying test is: any verification the agent can provide for itself does not count. Concretely:

• Validate against evaluations the agent cannot choose and cannot see
• Validate learned experience on future decisions, not on the trajectory that produced it
• Validate persisted changes with frozen held-out evaluation and an executor outside agent control
• Checkpoint everything and run regression comparisons — improvement curves are not guaranteed monotonic

Caveats

• The 48 matched-run comparison is descriptive, not a controlled causal effect of prompt phrasing alone; other run metadata may differ.
• Trajectory density is normalized per 10k characters and indicates where attention shifted, not what caused score differences.
• The design guarantees separation of access and timing, not complete sample disjointness between development and evaluation signals.

Bottom Line

The paper's most quotable and most practical standard: *running the update loop is not the same as improving the target capability.* For anyone building self-improving agent systems today, the immediate actions are: save every intermediate checkpoint, evaluate on hidden fixed benchmarks, distrust all self-reported scores, and treat every "improvement" as suspect until verified by signals the agent never touched.