Tencent Maps 549 Papers to Show When Self-Rewriting AI Can Be Trusted

AI agents that rewrite themselves are no longer a thought experiment. Systems that update their own prompts, retrain on their own outputs, or redesign their own improvement procedures are already shipping. The open question is not whether agents can self-evolve, but whether any of those updates can be trusted. A new survey from Tencent Hunyuan and collaborators at Zhejiang, Peking, and Tsinghua universities tries to answer exactly that.

The paper, Diving into Reliable Self-Evolving Agents: A Survey, organizes 549 works into a single structural map and introduces two tools practitioners have been missing: a five-level taxonomy of how deeply an agent can modify itself, and a reliability ladder that pairs each level with the kind of external evidence needed to accept an update.

The core problem nobody was naming

Self-evolving agents use information produced during their own execution to revise outputs or modify retained components that shape future behavior. That loop is powerful, but it contains a structural trap: the same system proposing a change can also be the one deciding whether the change was good. The survey's central principle is blunt about this: no update should control the only evidence used to accept itself.

The field had been accumulating techniques, from self-play to skill libraries to reward shaping, without a shared vocabulary for what kind of change was actually happening or what evidence would be sufficient to trust it. That gap is what this survey fills.

Five levels of self-modification

The survey classifies self-evolution into five levels defined by the deepest evolution target whose change takes effect. Think of it as how far down the agent's architecture a change actually reaches:

• L0 , Output-Level: Changes remain inside the current task and do not persist into later independent tasks. Classic examples include Self-Refine, Tree of Thoughts, and chain-of-verification. The characteristic failure is self-confirmation, where the same model both generates and judges its answer.
• L1 , Model-Level: The deepest active target is the trainable model or policy state. This covers self-training, self-play, and cooperative co-evolution. The risk here is model collapse, where the model iteratively trains on its own outputs and degrades.
• L2 , Scaffold-Level: The scaffold, meaning prompts, skills, memory, workflows, and the runtime harness, is what evolves. This is the most populated level in the catalog, with 257 works. Failure mode: scaffold overfitting, where the agent's wrapper becomes tuned to the evaluation conditions rather than the actual task.
• L3 , Improver-Level: The deepest active target is the procedure governing future updates. This is where recursive self-improvement (RSI) formally begins under the survey's definition. Systems like the Darwin Gödel Machine and Gödel Agent live here. The failure mode is metric capture, where the updater learns to game the fixed criterion rather than genuinely improve.
• L4 , Criterion-Level: The deepest active target is the evaluation protocols, rewards, constraints, or values used to judge improvement. The failure mode is criterion drift, where the agent gradually shifts what it is even optimizing for.

L0 is task-local; L1 through L4 require a retained change that affects later independent tasks or future updates. The levels describe how far a change reaches, not how capable or reliable the system is.

The reliability ladder

Knowing the level of a change is only half the picture. The survey's second contribution is a reliability ladder that maps each level to the evidence needed to trust an update. The key architectural requirement is that the evidence source and the acceptance gate stay outside the update boundary, so the loop cannot rewrite them.

In practice, this means:

• L0: An external verifier or held-out test, not the model's own self-assessment, confirms the output.
• L1: Evaluation on tasks the model did not generate its own training signal for, guarding against collapse and tail narrowing.
• L2: Scaffold changes are tested on tasks outside the conditions that triggered the update, with rollback capability.
• L3: The new improver is audited by a criterion it did not help design before it is promoted.
• L4: Protected outcomes, cross-criterion comparison, and external authorization prevent the agent from redefining success in its own favor.

Reliable self-evolution depends not on self-evolution depth alone, but on whether evaluation and oversight remain independent of the update and cover the relevant tasks, conditions, and constraints.

What the catalog reveals

The 549-paper companion catalog is organized across eight sections. The distribution itself tells a story:

L2 dominates because most current work on agent memory, skill libraries, and multi-agent workflows lives there. L3 and L4 are sparse, which reflects both the difficulty of the problem and the fact that very few deployed systems have reached that depth of self-modification.

Where this is useful right now

The survey identifies four application domains where self-evolving agents are already active:

• Executable engineering: Software agents that build, test, and optimize code, with unit tests providing a natural external audit.
• Persistent digital agents: Assistants that adapt across sessions, reusing workflows and learning from failures in live environments.
• Scientific discovery: Agents accelerating analysis and experimentation, where verifiable outputs are possible.
• High-stakes systems: Robotics, healthcare, finance, and law, where the reliability requirements are highest and the audit evidence must be most rigorous.

What the framework does not solve

The survey is honest about its limits. It is a structural map, not a benchmark. It tells you what kind of change is happening and what evidence you would need, but it does not provide off-the-shelf tools to generate that evidence. The L3 and L4 sections are thin because the research community has barely started on systems that modify their own improvement procedures or evaluation criteria. Open problems include longitudinal measurement, adaptive auditing, and scalable oversight as agents grow more capable.

There is also a harder question the taxonomy surfaces: at L4, the agent is changing what counts as improvement. No internal metric can catch that drift. The survey's answer is external authorization and protected outcomes, but operationalizing those in a production system remains an open engineering problem.

What to take away

The L0-L4 taxonomy and the reliability ladder give teams a shared language for a problem that was previously discussed in fragments. If you are building a system where an agent updates its own prompts, retrains on its own outputs, or redesigns its own evaluation, the first question to ask is: which level is this, and is my acceptance gate outside the update boundary? The full paper is on OpenReview, and the complete reading list is browsable on GitHub.