TL;DR · CLOSED-LOOP RSI

ByteDance Seed and TokenWave · September 1, 2026

Self-Developing Agents

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. Like human learning and improvement, RSI faces three problems: How does a broad, vague goal become concrete action? Without a teacher, can we judge our own behavior and learn from it? How does experience become part of the way we act?

Three benchmarks · three questions

Three questions for self-evolving agents

We break the path to closed-loop RSI into three questions, each studied with a separate benchmark.

01 / TARGET

What should the agent improve?

AspireView paper

Aspire gives the agent a broad goal such as “improve mathematical reasoning,” without revealing the downstream task or final evaluation. The agent must decide what to learn and how.

TestDoes the agent-built objective transfer to the hidden evaluation?
02 / EXPERIENCE

Can it learn from experience?

S³GymView paper

S³Gym tests whether an agent can generate experience, judge what worked, and turn the result into better future decisions.

TestDoes the experience transfer to held-out conditions?
03 / SYSTEM

Can the improvement persist?

HarnessDevView paper

HarnessDev tests whether a model can build a runnable agent harness, then evolve it using downstream execution feedback.

TestDo changes generalize to held-out tasks, and does evolution still work under a fixed executor?
Experimental evidence · three failure modes

Where self-evolution breaks

Aspire · five decision-agent configurations × six capability goals

Choose what to improve

1 retained gain / 30 cellsOnly one cell produced a gain that cleared the retention threshold
Most runs produced a checkpoint. Only one retained a gain.Each run starts from a broad capability goal; later stages apply completion and baseline checks
0102030 30 28 21 1 AllcellsEvaluatedcheckpointEligiblecheckpointRetainedimprovement
The checkpoints improve, but all remain below the base modelQwen3.5-4B Self · hidden-evaluation mathematics score by checkpoint
Self-trained checkpointsUnevolved baseline
05101520CK1CK2CK3 Unevolved base 17.86 0.791.752.38 Best CK: −15.48 vs base Local gain, global regression
Running the update loop is not the same as improving the target capability. Of 30 configuration–goal cells, 28 produced an evaluated checkpoint. Two beat the base model; only one cleared the retention threshold and was kept.Adaptive-feedback protocol · hidden evaluation set
Hover, click, or use ← → to move between studies.
Why the gains fail

Three gaps break the loop.

The target can be wrong, the lesson can fail to transfer, or the mechanism can exist in code but not at runtime.

01 / TARGET FORMATIONAspire

A vague goal changes the search before it improves the model.

With a fixed budget, agents spend more time interpreting the goal and choosing a proxy, and less time training and evaluating. That is more target operationalization, not evidence of a better target. An agent can complete an update without improving the intended capability.

Evidence boundary. This is a descriptive comparison of 48 matched Opus 4.8 run pairs, not an isolated prompt-only effect. Other run metadata may differ. Trace densities are normalized per 10,000 characters; they show where effort moves, not what caused the final score gap.

More decision time, less active GPU work

Vague-goal − explicit-task · minutes per matched pair Decision thinking GPU idle Active training / eval +35 +37 −76 −600+30

Vague goals increase target-interpretation activity

Trace-density ratio vs explicit-task · per 10,000 characters Read task definitions Inspect eval scripts LoRA / PEFT activity 2.98×2.39×3.09× 01×2×3× LoRA use: 24.1% → 89.8%
02 / EXPERIENCE INTEGRATIONS³Gym

No experience pathway wins across environments.

The ranking changes with the metric. Under baseline-normalized NABA, Summary Memory leads in Nullify, Tetris, and Trust. History ICL leads in Minesweeper, Snake, and PvZ. Chess splits 3–3–1. With raw AUC+, the tie moves from Chess to Tetris. The evidence does not support one default pathway. Parameter updates are also unstable: Trust improves across most checkpoints, while PvZ falls from 23 to 6 and stays there. Self-judgment barely predicts the next gain (ρ = −0.010 and −0.018).

Evidence boundary. The NABA chart covers 49 matched model–game pairs and uses NABA = AUC+ / max(y₀, ε). When y₀ = 0, ε uses the game’s first non-zero score scale. The leaderboard uses raw AUC+, so its win counts can differ. Parameter training is a separate 20-checkpoint Qwen3-8B study and is not matched to the context methods. We observe persistent degradation in PvZ; the cause is unknown.

Which memory pathway wins more model comparisons?

Model-level ΔNABA wins · seven paired models per game ChessMinesNullifyTetrisSnakePvZTrust 33 34 42 51 34 34 43 111 SummaryHistoryTie

The same parameter update can produce opposite results

Qwen3-8B · strict-mode score across 20 checkpoints Trust18 / 19 above baseline · max 30 PvZ19 / 19 updates remain at 6 300 300 236AUC+ 163.5 05101519
03 / SYSTEM INTEGRATIONHarnessDev

A runnable harness can still contain dead mechanisms.

In HarnessDev, LLMs created 18 Code harnesses, and all of them run. But some state and memory mechanisms in the code never appear during formal execution. During evolution, agents mostly change execution flow and tools, and rarely change state management.

Evidence boundary. Creation analysis covers 18 Code artifacts. A triggered component is not necessarily useful. Evolution categories overlap and cover 64 version switches from nine single trajectories. Post-freeze held-out evaluation covers SWE-Pro only.

Agents edit execution far more than state management or verification

64 official switches · overlapping edit categories Execution / control Tools Lifecycle recovery Context State Standalone verifier 583717 1640 016324864

State mechanisms in code and at runtime

Declared in code → observed at runtime ARTIFACT DESIGN · 18 CODE HARNESSES State class defined State-save interface Periodic checkpointing 11 / 181 / 181 / 18 OBSERVED RUNTIME 0 checkpoint eventsacross 26,679 task trajectories 18 / 108 components never observed · all state or memory

Which changes should persist?

These results come from the three benchmarks: Aspire tests whether the target was chosen well, S³Gym tests whether experience improves the next decision, and HarnessDev tests whether harness changes generalize to held-out tasks and whether evolution still works under a fixed executor.

01

Test the target on an evaluation the agent cannot see.

Twenty-one of 30 Aspire cells produced an eligible checkpoint; only one retained a gain. With vague goals, decision time rises, active training and evaluation fall, and LoRA use increases from 24.1% to 89.8%. The search changed. The target was not yet validated.

02

Test the lesson on the next decision.

Self-judgment barely predicts the next gain (ρ = −0.010 and −0.018). No experience representation wins across environments, and changing the normalization reorders the leader. Choose the pathway per environment and confirm it on held-out decisions.

03

Test evolution on held-out tasks under a fixed executor.

Visible and held-out scores agree on 34 of 64 switches. Only 2 of 9 declared final versions are held-out optimal. In four separate evolution runs with Gemini as executor throughout, only Opus improves over its own H₀ on held-out tasks; the other three regress. Keep changes only with versioning and rollback.

An analogy: forward-deployed engineering

FDEs turn local work into reusable capability.

Field work faces the same three tests: choose the right problem, learn from evidence, and keep only what the next project can reuse.

01
PlatformStart with a general platform
02
DiscoverFind the real customer problem
03
DeliverBuild a working solution
04
LearnExtract the reusable pattern
05
CompoundIntegrate the validated capability

The final test is reuse: the next project must be able to use the result.

What these results mean in practice

A useful self-evolving agent must become better at real work, not just score higher on public benchmarks.

It must adapt to the organization’s goals, workflows, data, and quality standards without turning every local workaround into permanent complexity.

The goal is not constant change. It is knowing which changes to keep.

Our research goal

We study agents that grow into a role, not just complete a task.

We give an agent a role-level objective and ask whether it can infer what good work means in that organization, build tests from imperfect feedback, and update its model, memory, and harness as evidence accumulates. The aim is not to replace an FDE end to end. It is to turn repeated field work into reusable capability.

What the benchmarks provide

Each benchmark also provides a reusable test. Aspire pairs hidden evaluation with auditable trajectories. S³Gym separates exploration from strict held-out evaluation and checks self-judgment with executable verifiers. HarnessDev freezes runnable artifacts and tests held-out generalization. Its Creation stage uses Unified-Eval for cross-executor portability; its Evolution stage also runs separate lineages under a fixed Gemini executor.

Aspire

Aspire asks whether an agent can choose what to learn from a vague goal. It includes six capability goals, a sealed 520-item expert evaluation, and a minimal interactive environment for weight and harness updates. It also provides 48 matched vague-goal/explicit-task run pairs with auditable trajectories.

S³Gym

S³Gym asks whether an agent can turn experience into better future decisions. It separates Self-Testing, Self-Judging, and Self-Improvement across seven verifier-backed games. It compares raw-history ICL, summary memory, and parameter training, with seven complete context-level models and a separate 20-checkpoint Qwen3-8B training study.

HarnessDev

HarnessDev evaluates whether a model can build a runnable agent harness and evolve it through downstream execution feedback. It evaluates the harness itself on held-out tasks, rather than looking only at task outputs.