Diving into Reliable Self-Evolving Agents: A Survey

1. Introduction

Large language models (LLMs) are increasingly embedded in agentic systems that can plan, use tools, maintain memory, interact with environments, and coordinate multi-step actions [1,2,3]. Recent work emphasizes that the capabilities of an agentic system depend not only on its base model but also on the surrounding harness, which organizes execution, tool use, context, persistent state, and evaluation [4]. As these model–harness systems are considered for open-ended, knowledge-intensive settings, their ability to specialize and adapt after deployment becomes an important design requirement [5]. Conventional improvement pipelines depend heavily on human-generated data, expert feedback, manually designed workflows, and repeated engineering effort. Although these external inputs and engineering resources remain indispensable, their limited availability and the difficulty of covering open-ended deployment conditions can constrain the scalability of conventional improvement pipelines [5]. At the same time, agents can generate training data [6], critique candidate solutions [7], write and test code [8,9], retain reusable plans or skills [3], and evaluate candidate system components [10,11]. These capabilities shift improvement from a purely external engineering process toward an increasingly endogenous one, in which agents help produce the knowledge, feedback, and mechanisms that shape their future behavior. When this participation produces changes that enhance the system’s capacity for further improvement, self-evolution becomes recursive, making recursive self-improvement (RSI) an operational research problem for LLM-based agents. We therefore situate RSI within the broader landscape of agent self-evolution rather than treating it as an isolated category.

To describe ordinary self-evolution and its recursive forms within a common framework, we organize this landscape into five levels according to self-evolution depth. Self-evolution depth is determined by the deepest evolution target whose semantic modification causally affects the functional chain that produces behavior, collects evidence, proposes later changes, and judges those changes. Representative systems illustrate the progression from task-local output refinement in Self-Refine [7], through retained model updates in WebEvolver [12] and persistent scaffold changes such as PromptAgent’s optimized prompts and SkillWeaver’s reusable skills [11,13], to changes that reach the procedures and criteria governing subsequent updates. The Darwin Gödel Machine retains self-modifications that affect how later descendants are generated [14], while the Red Queen Gödel Machine promotes evaluators that govern subsequent search [15]. L0: Output-Level Self-Evolution changes only a task-local output or trajectory, whereas L1: Model-Level Self-Evolution writes experience produced during agent execution into trainable model state and retains the resulting parameter update across later independent tasks. L2: Scaffold-Level Self-Evolution retains changes to structures surrounding the model, including prompts, tools, memory operations, workflows, runtime harnesses, and multi-agent topology. L3: Improver-Level Self-Evolution brings the procedure that proposes, selects, commits, or rolls back future updates inside the update boundary. L4: Criterion-Level Self-Evolution retains changes to the evaluator protocol, judgment tasks, rewards, metric semantics, constraints, or values that determine how later updates are judged. These levels are not parallel method categories: each transition is classified by its self-evolution depth, with L0 remaining task-local and L1–L4 requiring a retained change that affects later independent tasks or future updating. Under this structural definition, RSI begins at L3, where a retained change reaches the improver, and extends at L4 to the criterion. This boundary does not by itself imply that the system improves or that improvement accelerates. Accordingly, the hierarchy describes the functional position of a modification rather than its magnitude, complexity, or reliability.

A growing body of surveys has examined parts of this landscape from complementary perspectives. General surveys of LLM self-evolution organize the process as a cycle of experience acquisition, refinement, model updating, and evaluation, or classify methods by their evolution objectives [16]. A recent system-level account complements these process views by separating foundation-model improvement from scaffold improvement and further organizing methods by the object updated and the source of the improvement signal [17]. Experience-centered surveys trace how interaction histories become memory, skills, model behavior, and meta-level control [18], while self-feedback surveys examine the interaction between self-evaluation and self-update [19]. Related work distinguishes internal model adaptation from retrieval- and tool-based lifelong learning [20], and frames long-horizon agency through the coupling of externalized harness engineering and internalized model optimization [21]. Component-centered surveys analyze memory mechanisms [22] and agentic environments [23], while surveys of trustworthy agentic AI organize risks around safety, robustness, privacy, and system security [24]. Together, these works provide process taxonomies, system and component analyses, evaluation resources, and accounts of individual reliability challenges.

Existing surveys have discussed aspects of reliability by examining evolution processes, system components, and trustworthiness concerns, but they do not generally treat reliability as a unified axis for analysis across levels. In particular, existing work has not yet fully developed a cross-level synthesis linking self-evolution depth, the persistence of modifications, audit-evidence boundaries, promotion conditions, and characteristic reliability failures. This gap becomes more consequential as self-evolution expands from task-local revisions to persistent structural changes. Broader update processes can create longer causal chains and wider downstream effects, increasing opportunities for errors or misaligned objectives to propagate across rounds.

Reliability therefore becomes increasingly central, not because deeper self-evolution is necessarily less reliable, but because evaluating improvement claims and assessing robustness, traceability, controllability, and safety become more demanding parts of system design and evaluation. In this survey, reliability depends on how well the evidence supports the claimed improvement. The external target used to evaluate that improvement must remain fixed and cannot be changed by the update. Accordingly, this survey examines self-evolving agents as its broader subject, situates RSI within that landscape, and adopts reliability as a unified analytical perspective. Across the L0–L4 taxonomy, we ask how reliability requirements vary with the evolution target, the persistence of the modification, and the degree of recursion. A central concern is what evidence remains outside each update’s control and can therefore support a trustworthy improvement claim. We assess whether claimed improvements are supported by evidence outside the optimization process, whether they generalize across tasks and environments, and whether their origins and downstream effects remain traceable and independently verifiable. We further examine whether improvement processes preserve safety constraints, support monitoring and intervention, and permit rollback or termination when failures occur. Reliable self-evolution therefore depends not on self-evolution depth alone, but on whether evaluation and oversight remain independent of the update being assessed and adequately cover the scope of the improvement claim. Reliability is not a final check at the end of an evolution pipeline. It is a requirement that extends across self-evolution and its recursive forms.

The remainder of this survey is organized into three parts. Figure 1 maps these three parts onto the sections that follow and shows the audit decision that recurs at every level. Part I establishes the foundations of agentic self-evolution in Section 2 by introducing the key concepts, formalizing the agent and improvement loop, and clarifying the relationships among adaptation, self-evolution, and RSI. Part II develops the L0–L4 taxonomy across Section 3, Section 4, Section 5, Section 6 and Section 7 and examines the evolution targets, feedback sources, update mechanisms, and reliability requirements at each level. Figure 3 maps the mechanism sections and representative works reviewed under these five evolution targets. Part III provides a cross-level reliability synthesis and research outlook. Section 8 synthesizes shared failure modes, examines external audit signals and promotion reliability, and analyzes boundary conditions under adversarial pressure, safety, and trust. Section 9 examines foundational limits and early-warning signals, the evaluation paradox under adaptive benchmarks, applications and reliability challenges, and the limits of external oversight under uncertainty, alignment, and human coordination. Section 10 concludes with a reliability-centered synthesis and a research agenda for agent-centric self-evolution. Together, these parts provide a unified taxonomy of how agents improve themselves and a framework for determining when such improvements can be trusted.

2. Preliminaries

This section introduces the concepts and compact agent-level model used throughout the survey. We first separate occurrences of self-evolution from claims of improvement, then define self-evolution depth and reliability. We next describe the agent state and update loop. Finally, we order the five evolution targets by self-evolution depth and position our survey relative to related surveys.

2.1. Definitions of Key Concepts

Agents may use their own outputs, interaction experience, or environmental feedback to improve their behavior or internal components. Prior work uses different terms for such processes [16,18,25,26]. Throughout this survey, we consistently use self-evolution.

Self-evolving agents. We call an agent self-evolving when information generated during execution is fed back into the system. This feedback must revise either the current output or a retained component that affects later behavior or updating. The defining feature is not the number of execution steps, but whether information gathered during those steps leads to a further change. Within a single task, producing an answer is not enough. The agent must use feedback, evaluation, or search to revise, replace, or select candidate outputs [7,27]. This loop, whether feedback and revision or verification and acceptance, does not by itself determine whether the resulting output is reliable. For a change to persist across tasks, storing a trace or a proposed update is not enough. The stored change must affect later behavior or future updates [28,29].

Evolution target and self-evolution depth. The evolution target is the output or agent component changed by a transition. Self-evolution depth is determined by the deepest active semantic modification in a transition. This is the deepest target whose changed semantics affect a decision-relevant output, update, or judgment. For concise level-boundary equations, we write $A^{\prime }{\equiv }_{\mathrm{act}}A$ when two versions are equivalent in their active, decision-relevant semantics. The negation $A^{\prime }\neg {\equiv }_{\mathrm{act}}A$ denotes a semantic change with the causal effect just described. Depth therefore describes where a change occurs, not how large, irreversible, or reliable it is. When one transition changes several targets, we assign it to the deepest target whose semantic modification has such a causal effect. At L0, the change revises the task-local output or trajectory. At L1–L4, the change should affect later independent tasks or future updates. We call this the retention condition.

Reliability and improvement claims. A self-evolution event and an improvement claim are separate. The first states that a change occurred, while the second states that a measured aspect improved relative to the pre-update state. The evolution target asks what the system changed. The external target asks how we judge whether that change is better. The external target specifies the measured outcome, baseline, evaluation horizon, constraints, and matched resource conditions. The transition under evaluation does not modify these semantics. In this survey, reliability asks how strongly the available evidence supports the improvement claim under that target. A higher score alone is not enough because the loop may influence the proposed change, the evidence, or the retention rule.

External audit. An external audit assesses the improvement claim against the external target using evidence and a decision procedure outside the relevant update boundary. The evidence source produces results under declared data and procedures, while the acceptance policy maps those results to accept, reject, or escalate. The external target, evidence source, and acceptance policy should be versioned and remain outside the update boundary defined below [30]. This role differs from both the environment, which supplies observations and raw feedback, and the internal criterion, which uses rewards, rankings, metrics, or constraints to guide the update. The external audit assesses the resulting change using evidence such as held-out tests, executable checks, controlled experiments, formal verification, or human review. An audit is external because of how it is controlled, not where it runs. Its independence can weaken if the update can choose the evidence or repeatedly query the results.

2.2. A Functional View of Self-Evolving Agents

We now use a compact functional model to compare systems with different implementations. This view follows recent component-based accounts of self-evolving and lifelong agents [18,25,29]. The model keeps only the state, execution, retained updates, and audit needed for the taxonomy and reliability analysis.

Agent state and evolution targets. We model the retained agent state at iteration k with four components:

$$X_k=\left({\theta }_k,{\sigma }_k,{\mathcal{U}}_k,{\mathcal{C}}_k\right).$$

(1)

The update boundary describes what the loop may modify, what evidence it may access, what resources it may use, and what actions it may authorize. Two systems may modify the same components yet differ in how strongly evidence can support their improvement claims, because their evidence access, resource limits, or authority differ. Here, ${\theta }_k$ denotes the trainable model or policy state. The scaffold ${\sigma }_k$ is the retained, nonparametric runtime structure around the model. It includes prompts, tools, memory, workflows, and the runtime controls that shape execution and retained evidence. An object in this runtime structure belongs to ${\sigma }_k$ by default. If its active role is to produce later updates or define later judgments, it belongs to the improver or criterion instead. We use ${\sigma }_k^{\mathrm{rt}}\subseteq {\sigma }_k$ to denote memory contents and indices that execution may update directly, while the outer loop controls the memory policy and schema. The improver ${\mathcal{U}}_k$ comprises the mechanisms that propose, select, commit, or roll back candidate modifications. The internal criterion ${\mathcal{C}}_k$ specifies the objectives, rewards, evaluation protocols, comparison rules, and constraints used to judge behavior and candidate states. Data and experience do not add a separate coordinate to $X_k$. They are classified with the retained component they modify. Learned router or evaluator parameters belong to ${\theta }_k$, while nonparametric workflows and memory mechanisms belong to ${\sigma }_k$. Rubrics or evaluation protocols that govern later judgments belong to ${\mathcal{C}}_k$.

The current output $y_k$ is temporary and therefore sits outside the retained state $X_k$. For the taxonomy, we add this output to the four retained components and denote the five possible targets by

$$T_k^{\mathrm{evo}}=\left(y_k,{\theta }_k,{\sigma }_k,{\mathcal{U}}_k,{\mathcal{C}}_k\right).$$

(2)

Equation (2) lists the five taxonomy targets in order: output, model, scaffold, improver, and criterion.

Execution, proposal, and selection. At iteration k, the agent runs task $q_k$ from state $X_k$ under a declared resource budget $b_k$. Execution returns trajectory ${\tau }_k$, output $y_k$, and a temporary experience summary $e_k$:

$$({\tau }_k,y_k,e_k)\sim {Exec}_{X_k}(·\mid q_k,b_k).$$

(3)

An output-only revision changes $y_k$ or its trajectory while leaving retained state unchanged, and is therefore L0. Execution may instead write to runtime memory ${\sigma }_k^{\mathrm{rt}}$ directly. Let $X_k^{\mathrm{exec}}$ denote the resulting retained state. If no runtime-memory update occurs, $X_k^{\mathrm{exec}}=X_k$. A runtime-memory update reaches Scaffold-Level Self-Evolution only when it stays active and changes behavior on a later independent task. Likewise, $e_k$ affects later rounds only if it is stored in runtime memory or used in an accepted update. When a runtime-memory update is the only retained change, the round may end at $X_{k+1}=X_k^{\mathrm{exec}}$ without an outer update.

For an outer retained update, under the same implicit resource budget $b_k$, the current improver proposes candidates from $X_k^{\mathrm{exec}}$, $e_k$, and evolution history ${\mathcal{H}}_k$. The history is maintained outside the update boundary, and the current criterion supplies the internal selection rules:

$$\begin{array}{c}\hfill {\mathbf{X}}_k^{\mathrm{cand}}\sim {Propose}_{X_k^{\mathrm{exec}}}(·\mid e_k,{\mathcal{H}}_k),\\ \hfill X_{k+1}={Select}_{X_k^{\mathrm{exec}}}({\mathbf{X}}_k^{\mathrm{cand}};{\mathcal{H}}_k).\end{array}$$

(4)

Here ${\mathbf{X}}_k^{\mathrm{cand}}$ is a set of candidates that may modify any subset of the retained components. The selected $X_{k+1}$ is provisional: internal selection determines which candidate proceeds to audit, not whether it is promoted.

External assessment instead uses evidence source $\mathcal{S}$ and acceptance policy $\mathcal{G}$ outside the agent state:

$$\begin{array}{cc}\hfill z_k^{\mathrm{ext}}& \sim {Evidence}_{\mathcal{S}}(·\mid X_k,X_{k+1}),\hfill \\ \hfill a_k^{\mathrm{ext}}& ={Gate}_{\mathcal{G}}\left(z_k^{\mathrm{ext}}\right)\in \{\mathrm{accept},\mathrm{reject},\mathrm{escalate}\}.\hfill \end{array}$$

(5)

Here $z_k^{\mathrm{ext}}$ is the external evidence and $a_k^{\mathrm{ext}}$ is the resulting gate decision. The external target, $\mathcal{S}$, and $\mathcal{G}$ are controlled outside the update boundary of the transition being assessed. The audit uses the pre-execution state $X_k$ as its baseline. It therefore covers both direct memory and outer updates unless they are declared and assessed separately.

Persistence, audit, and loop closure. Internal installation establishes a state transition, but does not by itself support an improvement claim. Without an external audit, the transition still counts as self-evolution, but no independent evidence supports an improvement claim. We use promotion for acceptance by the external gate, after which the candidate becomes the retained state for the next round. The audit may occur before installation or certify a provisional installation. An escalated case counts as accepted only after an authorized reviewer approves it. Acceptance means that the evidence meets the declared audit requirements. It is not a claim that the system improved in every respect. Rejection may trigger rollback. The state retained after any required rollback then conditions the next execution round and closes the self-evolution loop. Figure 2 summarizes this process.

2.3. The L0–L4 Taxonomy

We classify each transition by the deepest evolution target whose active semantic change affects a decision-relevant output, update, or judgment. Table orders these targets by self-evolution depth. The levels are neither a temporal sequence nor a ranking of capability, sophistication, or reliability.

Classification rules. Classification follows the changed object rather than the algorithm that produces the change. Reflection, training, search, reinforcement learning, and evolutionary algorithms may therefore occur at several levels, and runtime use or storage alone does not establish a rewrite. When a transition changes several targets, the deepest causally active semantic change determines its level. If the available evidence does not establish that effect, we report the assignment as conditional. L0 is task-local, whereas L1–L4 must satisfy the retention condition. Retained data are classified by the deepest component whose later behavior they causally change. We call a system L4-facing when its core realized transition remains below L4 but it generates or uses criterion-related artifacts without changing the active judgment semantics.

Relation to RSI. In this survey, recursive self-improvement (RSI) denotes a retained transition whose deepest active change reaches the improver or criterion. L3 changes how later modifications are proposed, selected, committed, or rolled back, while L4 also changes how behavior or candidate states are judged. This structural convention is not field-wide and neither establishes improvement nor implies accelerating gains. At these levels, an audit must establish which evidence remains outside the expanded update boundary.

2.4. Positioning Our Survey

Existing surveys characterize self-evolution research along several complementary dimensions. Broad surveys organize the literature by the evolved component, training stage, system architecture, feedback mechanism, or model–environment relation [16,17,18,25,26,31]. Focused surveys instead examine topics such as inference-time self-evolution, multimodal models, agentic reinforcement learning, memory, environment engineering, and lifelong learning [19,20,22,23,32,33,34,35,36]. We add two questions: how deep does the change reach, and what evidence outside the relevant update boundary supports the improvement claim? These questions permit comparison across algorithms and architectures without treating depth as a reliability ranking. Table 1 compares the coverage of these two perspectives in our survey and related surveys.

Together, the taxonomy identifies what changes, while the reliability analysis asks what evidence supports the improvement claim.

3. L0: Output-Level Self-Evolution

L0 at a Glance

Boundary. L0 changes only the current output $y_k$ or its task-local trajectory ${\tau }_k$. The retained agent state $X_k$ remains unchanged across independent tasks, so any audit-supported improvement claim is task-local.

Roadmap. We follow the task-time control loop from iterative revision (§3.1) to search, verification, and acceptance (§3.2), then examine shared errors, coverage, stopping, and claim scope (§3.3).

Reliability focus. Revision and search can alter or enlarge the candidate set, but they do not establish improvement by themselves. Acceptance should rely on an external audit whose evidence source and acceptance policy remain outside the update boundary. The evidence must remain informative about the external target. Repeated access or shared blind spots can otherwise make the loop self-confirming.

Output-Level Self-Evolution is the task-time layer of the taxonomy: the agent may revise, replace, or select the current answer, rollout, code candidate, reconstruction, or reasoning trace, but the retained state used for later independent tasks remains unchanged. This section asks how task-time mechanisms produce candidate outputs, how evidence selects among them, and what scope of improvement that evidence can justify. We organize the section into three parts: iterative revision repairs one incumbent, search, verification, and acceptance expands and evaluates alternatives, and the reliability and persistence analysis defines the resulting claim boundary. Table 3 compares these three categories by their task-local role, representative mechanisms and systems, and reliability focus. Figure 4 follows the task-time path from a draft through reflection, exploration, and verification while retained state remains fixed.

Boundary and persistence. Writing the current trajectory, output, and retained agent state as $({\tau }_k,y_k,X_k)$, the L0 boundary is

$$({\tau }_k,y_k,X_k)⟼({\tau }_k^{\prime },y_k^{\prime },X_k^{\prime }),({\tau }_k^{\prime },y_k^{\prime }){\not\equiv }_{\mathrm{act}}({\tau }_k,y_k),X_k^{\prime }{\equiv }_{\mathrm{act}}{X}_k,$$

(6)

This is the L0 case: the active output or the trajectory that produces it changes, but no active retained state does. Critique, self-play, search, verification, and substantial temporary working state can all operate inside this boundary. For example, Focus compresses a long software-engineering trajectory into a compact Knowledge block and prunes earlier interactions so that the agent can continue solving the current task [164]. Such state can extend the effective reasoning horizon without becoming persistent self-evolution. The absence of persistence is both a containment property and a capability limit: a harmful revision is usually discarded with the episode, while a valid correction must be rediscovered on a later task.

3.1. Iterative Revision

Iterative revision maintains one incumbent candidate and repeatedly applies a feedback–repair loop. Its main design choice is the diagnostic signal: self-critique and role separation remain model-mediated, whereas execution, formal checks, environment observations, and localized evidence expose additional task structure.

3.1.1. Self-Critique and Role-Separated Feedback

The most direct revision loops generate feedback from the same model or from several model-mediated roles. Self-Refine repeatedly generates, critiques, and rewrites one candidate, with gains that vary substantially across code, dialogue, and mathematics [7]. Table-Critic instead separates error localization, critique, and revision across a Judge–Critic–Refiner cycle [37]. These designs make the repair process explicit, but neither repeated prompting nor role separation guarantees an independent diagnosis when the participants share the same criterion and blind spots.

3.1.2. Grounded Repair

Execution, tests, and proofs. Executable and formal systems narrow the repair set by returning behavioral or symbolic diagnostics. SELF-DEBUGGING revises programs from execution results, while AlphaCodium and Agentless combine reflection, localization, test construction, execution, and patch validation [8,9,38]. Baldur uses proof-assistant errors to repair Isabelle proofs, and AgentCoder separates programming, test design, and execution roles [39,171]. These checks are more discriminating than unconstrained critique, although incomplete tests and specifications can still admit incorrect artifacts.

Environment and localized evidence. Interactive and multimodal systems ground revision in observations from the current task. Inner Monologue and DEPS revise plans from success signals, scene descriptions, human feedback, and observed failures, while Kestrel and Reflect-R1 retrieve localized visual or temporal evidence before revising an answer [40,41,165,172]. Such evidence can expose errors that verbal self-critique misses, but its reliability still depends on whether observation and retrieval cover the claimed property. When one evolving trace cannot recover from an early commitment, L0 systems broaden the task-time state from an incumbent candidate to a set or structure of alternatives.

3.2. Search, Verification, and Acceptance

Search expands the task-local candidate set, while verification and acceptance determine whether evidence warrants revision, rejection, or return. Flat sampling aggregates complete candidates, structured search controls intermediate states, and evidence-guided gates compare candidates against rubrics, retrieval, tools, execution, or internal proxies. These operations form one decision pipeline: candidate diversity is useful only when the acceptance signal can recognize a beneficial alternative without reproducing the search’s shared error. The second row of Table 2 summarizes this pipeline from candidate generation through evidence-guided task-local decisions.

3.2.1. Candidate Generation and Structured Search

Sampling and search topologies. Sampling broadens the candidate pool without an explicit topology, while tree, graph, beam, and planning methods expose intermediate states for scoring, pruning, backtracking, or aggregation. Self-Consistency improves answer selection by marginalizing across sampled reasoning paths, whereas Tree of Thoughts and LATS organize explicit search over reasoning or agent trajectories [1,42,43]. Beam search, RAP, Graph of Thoughts, and rStar vary the topology and division of proposal and evaluation [44,45,46,173]. These structures can diversify exploration and localize decisions, but agreement and model-derived value functions can still amplify errors shared across candidates.

Consequences, compute, and reuse. World-model systems compare predicted futures, whereas systems that execute tools can use observed consequences. WAC and WebDreamer simulate future states, while START executes and debugs tool-augmented traces [6,166,174]. Adaptive methods instead decide where inference should be spent. Fast–slow reasoning, difficulty-aware test-time scaling, CodeMonkeys, and S* allocate computation across uncertain cases or parallel edit–test trajectories [167,175,176,177]. Buffer of Thoughts and Forest-of-Thought reduce search cost through templates or sparse ensembles [178,179]. Across these variants, additional computation helps only when predicted consequences are accurate, reused structure matches the task, and the selector recognizes informative alternatives.

3.2.2. Evidence-Guided Verification and Acceptance

Verification forms the outer task-time gate: it uses rubrics, retrieved evidence, tools, execution, tests, or internal consistency to return, reject, or escalate a candidate. Escalation transfers an unresolved case to an authorized reviewer or a stronger external verification process. The relevant distinction is not whether a check exists, but who controls its evidence and which errors it can observe.

Rubrics, sources, and tools. DeepVerifier and CoSPlay make acceptance criteria explicit through rubrics, critics, generated tests, and execution outcomes [50,51]. RARR and Chain-of-Verification ground revision in separately retrieved or elicited factual evidence, while CRITIC generalizes tool-interactive checking to search engines and interpreters [2,49,168]. These channels can expose evidence absent from the initial output, but self-generated rubrics, tests, queries, and stopping rules remain vulnerable to shared omissions and adaptive overuse.

Execution and internal proxies. Execution-based methods compare observable behavior: CodeT ranks program–test consensus groups, MBR-EXEC groups programs by sampled behavior, LEVER combines execution with a learned verifier, and code-based self-verification uses an interpreter to check mathematical answers [47,48,180,181]. When no executable or source-grounded check is available, Key Condition Verification, backward self-verification, and bidirectional manifold consistency construct reconstruction or consistency tests from the model’s learned distribution [182,183,184]. Execution provides a checkable behavioral relation but remains limited by test coverage, while internal proxies can reject inconsistency without establishing correctness when the checking process shares the candidate’s misconception.

3.3. Reliability and the Persistence Limit

The three task-time components expose a common reliability problem. Revision can repeat the generator’s diagnosis, search can aggregate correlated candidates, and verification can accept a test or proxy that shares the proposer’s blind spot. An L0 improvement claim is credible only if the audit measures the intended task outcome. The evidence and the decision rule must also remain outside the update’s control.

Self-confirmation and negative evidence. The characteristic L0 failure is self-confirmation: additional reasoning endorses an error already present in the candidate, critic, candidate pool, generated test, or consistency score. Without oracle labels or external feedback, intrinsic self-correction reduces reported GPT-4 accuracy from $95.5\%$ to $89.0\%$ on GSM8K and from $49\%$ to $43\%$ on HotpotQA [169]. After accounting for model calls, self-repair gains are often modest or absent, while replacing self-feedback with human feedback raises the reported repair success rate from $33.3\%$ to $52.6\%$ [170]. These results do not show that task-time inference is ineffective. They show that more inference cannot substitute for evidence that distinguishes a repair from a newly introduced error.

Coverage and stopping. Evidence externality is necessary but not sufficient because every task-time check has a coverage boundary. Execution observes only tested behavior, retrieval observes only located sources, environment feedback observes only visited states, and fixed rubrics observe only encoded criteria. Repeated access can turn a nominally external check into development feedback, so a defensible protocol couples each evidence source to stopping, abstention, escalation, and matched-budget rules. Candidate diversity and selector quality then determine whether additional search improves the returned artifact rather than increasing opportunities to overfit the check. The relevant comparison is between the accepted candidate and the incumbent under the same task, budget, and evidence protocol, not between systems that receive different amounts or kinds of feedback.

Claim scope and persistence handoff. When coverage and stopping are adequate, L0 evidence can support a claim about the selected output on the current task. Agreement and model-based critique are inexpensive but can reproduce a shared error, whereas execution, retrieved sources, environment observations, and fixed rubrics can provide more independent checks when their coverage is declared. None of these task-local checks by itself establishes that the retained agent will perform better on later independent tasks because Equation (6) leaves $X_k$ unchanged. This absence of cross-episode retention contains the downstream effect of a harmful edit but also prevents a verified correction from accumulating. The next section turns to Model-Level Self-Evolution, where selected experience changes trainable state and thereby carries both improvements and errors into later tasks.

4. L1: Model-Level Self-Evolution

L1 at a Glance

Boundary. L1 persistently changes the trainable model or policy state ${\theta }_k$, and the change affects later independent tasks. The scaffold ${\sigma }_k$, improver ${\mathcal{U}}_k$, and criterion ${\mathcal{C}}_k$ remain fixed. Any audit-supported improvement claim therefore concerns later behavior under the declared external target. The training signal may come from the agent’s outputs, interaction experience, other models, or environmental feedback, but its source does not determine the level.

Roadmap. We organize the level by the structure of the training relation, moving from single-model self-training (§4.1) through competitive self-play (§4.2) to cooperative co-evolution (§4.3).

Reliability focus. Self-generated supervision, rewards, and peer signals can guide a model update, but they do not establish improvement under the external target. Promotion should compare the candidate with the incumbent under matched resource conditions, using an external audit outside the update boundary. Otherwise, low-quality labels, stalled self-play, or shared population bias can compound across rounds and contribute to collapse or drift.

Model-Level Self-Evolution is the first level whose retained rewrite lands on the trainable model state ${\theta }_k$. The model may evolve its own weights or refine its own outputs, but it cannot evolve the structure or workflow around it, because the scaffold ${\sigma }_k$, improver ${\mathcal{U}}_k$, and criterion ${\mathcal{C}}_k$ stay fixed (Table ). Because the update is kept in the weights rather than in the task-local output of L0, both useful changes and errors induced by self-generated supervision can carry over into later independent tasks. The core question is therefore under what conditions this signal remains informative about the external target and can support an improvement claim about the weight update. We organize the level by the structure of the training relation—who emits the signal and how that role differs from the trainee—rather than by the signal’s surface form. Figure 5 shows this progression in signal-producing roles. Table 3 then indexes representative systems relation by relation, giving for each one the mechanism family it belongs to, the retained move it makes, and a public implementation where one exists.

Boundary and persistence. Model-Level Self-Evolution is a retained transition whose deepest active semantic change modifies the trainable model or policy state and affects later task execution. Within this boundary, we organize the surveyed methods by how the evolving system participates in producing the training signal. Writing the retained state as $X_k=({\theta }_k,{\sigma }_k,{\mathcal{U}}_k,{\mathcal{C}}_k)$, the L1 boundary is

$$X_k⟼X_{k+1},{\theta }_{k+1}{\not\equiv }_{\mathrm{act}}{\theta }_k,({\sigma }_{k+1},{\mathcal{U}}_{k+1},{\mathcal{C}}_{k+1}){\equiv }_{\mathrm{act}}({\sigma }_k,{\mathcal{U}}_k,{\mathcal{C}}_k),$$

(7)

so a method belongs here whenever its retained update lands on the model parameters ${\theta }_k$, whatever mechanism produces the signal. The training relation then forms one progression. It begins with a single self-training role, where producer and trainee coincide, and moves to two competing copies whose relative outcome may be more informative than a self-asserted label. It ends with cooperative helping roles that range from a privileged teacher to a whole population and differ from the trainee in information, function, parameters, or membership. Self-play that instead moves the target distribution is deferred to Section 7, since the deepest active change then reaches the criterion (§2.3). For the families surveyed here, the internal training signal may help produce a candidate update, but it does not by itself support an improvement claim under the external target. That claim requires an audit whose evidence source and acceptance policy remain outside the update boundary.

4.1. Single-Model Self-Training

This section collects the methods in which one model in a single role produces and consumes its own training signal, so producer and trainee coincide. We divide it by whether the signal is selected or created, separating methods that filter and curate outputs the model already produced from methods that must manufacture the supervision, reward, or alignment signal a task does not supply. The order distinguishes whether the signal comes from one role, competing roles, or cooperative roles. These arrangements expose different failure modes, but they do not by themselves determine reliability.

4.1.1. Filtering and Curating Existing Output

This part covers the base case, in which the model selects rather than manufactures its signal. The same model both produces and consumes the signal, and it retains only the high-confidence outputs it can filter and the data it can repair, so nothing enters the loop that the model did not already generate.

Bootstrapping from filtered self-output. The oldest and simplest way to close the loop on the weights lets a single model filter its own high-confidence outputs or distill its own trajectories and then write the result back into its parameters [52,53,185,186]. STaR bootstraps reasoning by rationalizing the model’s own correct answers, Self-Instruct grows an instruction-tuning corpus from its own generations, and ReST alternates growing a self-generated sample pool with reward-filtered fine-tuning [52,53,186]. Recent systems keep this single-role structure but vary the part of the training pipeline the self-generated signal targets [54,187,188,189]. One line targets the training data itself. Middo rewrites its own fine-tuning set along complexity, diversity, and quality axes so that the data tracks the model’s competence [54], and PolicyLong keeps the pool on-policy by re-filtering it with the current model before each update [187]. Another line distills a persisted capability into the weights without ground truth. SelfEvo cross-distills depth and pose from unlabeled video [188], while a further study asks when context-level experience can be internalized into parameters without the capability collapse that repeated internalization tends to induce [189].

Recurrence in label-scarce domains. The same filter-and-retrain loop is not confined to general reasoning. It recurs wherever a domain lacks cheap labels and the model must supply its own [190,191,192]. It appears in assembly-code comprehension under obfuscation [190], in streaming-video adaptation where the base model is its own data generator and annotator [191], and in medical slow-thinking bootstrapped from verifiable MCTS traces [192]. The most recent instances carry the same idea into still narrower settings, from embodied agents that internalize experience through inverse dynamics or idle-time updates [193,194,195,196] to self-collected curricula for perception, coding, and retrieval [197,198,199,200,201,202,203]. Across these settings the grounding varies with the domain, but the loop’s single-role structure does not.

Dynamics of the single-role loop. Because this loop is so widely reused, a methodological line studies its dynamics in their own right. This work examines how self-evolving training saturates and can be rebalanced [204], how a one-way policy update forms a ratchet without an external reference [205], and how self-consistency under geometric or visual invariance regularizes the signal [206,207].

4.1.2. Synthesizing Supervision, Reward, and Alignment

This part covers the case in which no external label or teacher exists, so the single model manufactures the signal it will train on rather than selecting it from prior output. It draws that signal from synthesized tasks, self-generated critiques, and its own hindsight [55,56,57,208,209,210,211,212,213,214,215,216], and the paragraphs below run outward from task supervision, through a self-produced reward, to a self-generated stand-in for human alignment feedback. Alignment is placed last because its manufactured signal targets values rather than task correctness, which puts it at the outer edge of what a single role can safely produce.

Synthesizing supervision targets. One line synthesizes explicit supervision targets. MindGYM composes cognitive multi-hop questions for thinking-centric fine-tuning [55], CoTEvol evolves chain-of-thought traces by genetic search before training on them [208], and LongPO pairs a model’s long- and short-context responses to bootstrap long-context ability [56]. DITTO reports that the same self-comparison suffices for personalized alignment from fewer than ten demonstrations [209], and Learning-to-Label reinforces a self-evolving labeler that manufactures its own supervision targets [210].

Self-evaluation and retrospective reward. Another line draws the signal from the model’s own evaluation or retrospection. Self-Rewarding Language Models use the evolving model as its own judge to build preference pairs for iterative alignment, and process-based self-rewarding extends this to step-wise judgments [211,212]. SCRIT trains critique ability on self-generated contrastive critiques [213], and SER lets a reward model relabel data to improve itself [57]. RetroAgent turns hindsight into intrinsic numerical and language feedback for online updates [214], retrospective in-context learning converts sparse outcomes into dense advantage estimates for on-policy refinement [215], and reward-free world-knowledge exploration scores self-generated knowledge by its downstream success [216]. SERL closes the loop with the model as both actor and judge, and it derives its reward from Copeland-style pairwise self-ranking of its own generations with no external signal [58].

Shaping and stabilizing the self-reward. Because a self-produced reward is cheap but fragile, a further line shapes it to lower cost and collapse risk. Test-time synthesis and offline iteration reduce the compute a round demands [217,218], latent-logic reward decomposition sharpens the credit signal [219], and easy-sample warm-up curricula stage what the model trains on first [220]. DARE adds a difficulty-adaptive curriculum whose difficulty signal is a self-normalized statistic over the model’s own rollouts rather than a separate model, and the weight update is still driven by a fixed verifier [221].

Self-generated alignment. A parallel line applies the same single-role idea to alignment, replacing human preference labels with signal the model or a fixed rule produces [59,60,61,222]. Constitutional AI critiques and revises its own responses against a fixed set of written principles and then trains a preference model from the resulting AI feedback [59]. RLAIF shows that an off-the-shelf model can replace the human labeler in the RLHF pipeline [60]. TTRL pushes the idea to test time by deriving a reward from majority vote over the model’s own samples on unlabeled data [61], whereas RLHI instead anchors the signal in real user interactions rather than the model’s own distribution [222]. These methods update ${\theta }_k$ under a fixed criterion ${\mathcal{C}}_k$, so they remain Model-Level even when the signal is evaluative. Activating a rubric or evaluator protocol whose judgment semantics have changed would instead make the realized transition Criterion-Level Self-Evolution (§7).

Across the whole single-role family the defining feature is the structural absence of a second party. Producer and trainee coincide, so nothing in the loop can contradict a confident error. This is the mechanism behind the self-consuming dynamics of Section 4.4, and it is the weakness that the next groups repair by reintroducing a second party into the loop.

4.2. Competitive Self-Play

This section covers the methods that reintroduce a second party as a competing copy, so the signal comes from a relative outcome rather than a self-asserted label. We divide it by how the competition is structured, starting with the symmetric comparative case and then the asymmetric proposer-solver schema that specializes the two roles. The second case is placed after the first because it adds a mechanism for keeping the competition informative rather than changing the underlying relation.

4.2.1. Symmetric Self-Play

The most direct way to reintroduce a second party is to let the model compete with a copy of itself and to take the training signal from the relative outcome of the competition [62,63,64,69]. Self-play breaks the single-role closure by instantiating the model as two competing copies and reading the signal from a win or loss, a passed or failed test, or a preference between two responses. Because this relative signal is harder to fabricate than a label the model asserts about a single output, it is the first step away from the self-confirming loop. Two anchor cases make the mechanism explicit. SPIN converts a weak model into a strong one purely by having it distinguish its own earlier generations from reference data, with no extra annotation [62]. SPAG sharpens reasoning by casting the model as both attacker and defender in an adversarial language game [63].

4.2.2. The Proposer–Solver Schema

From the comparative base, the dominant instantiation specializes the two symmetric copies into a proposer rewarded for posing hard problems and a solver rewarded for answering them, with a verifier or consistency check closing the loop [64,65,66,68,223,224,225]. Its appeal is that the proposer manufactures the solver’s curriculum automatically. The schema then recurs across domains according to what can play the verifier.

Executable verifiers. Where a code executor can adjudicate answers, Absolute Zero and G-Zero drive reasoning from zero external data [64,65]. TSP and ACE instead turn unit tests or adversarial tests into the solver’s signal [67,223]. A pure instance of the schema is R-Zero, which starts from zero human data and co-evolves a Challenger rewarded for posing frontier-difficulty problems with a Solver trained on majority-vote pseudo-labels [66]. It updates both roles by reinforcement on the weights under a fixed reward.

Perceptual and cross-domain verifiers. Where the judgment is perceptual rather than executable, the same loop is closed by self-consistency or a learned check in multimodal and video understanding [224,226,227,228]. VisPlay illustrates the perceptual case, pairing an image-conditioned questioner with a multimodal reasoner and co-evolving them from unlabeled images alone [68]. Spatial and geospatial reasoning instead ground the check on deterministic geometry or executable programs [229,230]. The schema extends further to instruction following [231], search grounded in knowledge graphs [232], translation without parallel data [72], and affective dialogue [233]. It also scales from single turns into multi-turn and multi-agent games, which include long-context evolution [71], zero-sum reasoning games [69], and competitive visual games in which the roles must reason about hidden state [70].

Stretching the competitive relation. Two variants stretch the competitive relation to its limit without abandoning it. An error-driven opponent is actively rewarded for producing wrong outputs so that the solver learns to discriminate [234,235]. An adversarial discriminator instead supplies dense step-level judgments against the reasoner [236]. The relation stretches further to full self-play defect injection-and-repair for software agents [237] and to intrinsic-supervision proposer-solver loops that reward the whole trajectory rather than only the final answer [238].

Keeping the competitive signal live. Because the competitive signal is only as informative as the competition is live, a substantial line of work turns from applying the schema to stabilizing it, and these methods are best read as patches for its specific failure modes [73,239,240,241,242,243]. When the preference oracle grows overconfident on semantically similar responses, S-SPPO anneals the win-rate target toward a maximum-entropy baseline [73]. When the current advantage vanishes across iterations, TPAW plays the policy against its own historical checkpoints and T-SPIN adds a historical-advantage triplet [239,240]. When the game becomes deterministic and the gradient dies, DEPT detects the resulting “evolutionary impasse” and reshapes the advantage [241]. When the proposer’s distribution narrows and the curriculum collapses, vocabulary dropout forces diversity [242]. When only relative reward is optimized, SPACE adds noise-contrastive estimation to anchor the absolute values and provably converge to the true distribution [243]. Foresight over an opponent [244], continuously tunable Rényi-divergence objectives [245], and guided asymmetric curricula anchored on benchmark problems [246] extend the same stabilizing agenda. A game-theoretic line further reframes self-play preference optimization as convergence to a Nash equilibrium [247,248]. These stabilization methods delimit when the comparative signal remains informative. The comparative signal advances beyond self-training only while the competition keeps injecting learnable information, and it decays into noise once the two copies stop meaningfully disagreeing. That failure is the one Section 4.4 analyzes as the level’s ceiling [249,250].

4.3. Cooperative Co-Evolution

This section covers the methods in which a functionally distinct role co-evolves to help the trainee rather than to defeat it. We divide it by how the helping role differs from the trainee, including privileged information, a distinct evaluation function, separately trained parameters, or population membership. These distinctions may affect signal informativeness, but they do not establish external audit status. The four parts therefore run from a privileged teacher, through a co-evolving verifier, to two mutually trained models, and finally to a whole population.

4.3.1. Privileged Teachers

The near end of the cooperative range is a teacher that differs from the trainee only by a privilege gap, such as access to hindsight, distilled skills, or trajectory context the student lacks. Because the teacher remains closely coupled to the trainee, its additional information comes from that privilege gap rather than from genuine audit independence.

Teachers with a privilege gap. A third group keeps two roles but reverses their relation, so that a functionally distinct role co-evolves to help the trainee rather than to defeat it [75,78,79,251]. At the near end, that role is a teacher conditioned on information the student lacks, such as distilled skills, hindsight, or privileged trajectory context. It supplies dense token-level supervision on the student’s own rollouts, so the student internalizes guidance it could not have produced alone. GenEvolve abstracts best-versus-worst trajectory differences into privileged visual experience [252]. OPD-Evolver internalizes read, use, write, and maintain memory competence through privileged-hindsight distillation [74]. $\pi$-Play uses problem-construction paths as the teacher’s privileged context [253]. VPD casts the teacher as an actively refined variational posterior over language feedback [254].

4.3.2. Co-Evolving Verifiers and Critics

The second role may instead become an evaluator rather than a teacher. A separately trained evaluator can contribute a signal with different errors or information from the generator, although separate training alone does not make that signal an external audit. Q-Evolve learns an in-distribution critic that emits per-step process rewards [75]. CME goes furthest by scoring the generator under an independent verifier model whose signal cannot be gamed by self-consistency [251]. Self-Guide and MAESTRO learn an internal reward or scalarization jointly with the policy [155,255]. A visual critic co-evolves with a proposer to sharpen GUI grounding [256]. DPA-GRPO lets a verifier issue safety-assurance cases that ground the generator’s revisions [257]. In agent settings the evaluator is often a full reward model trained apart from the policy. WebRL learns an outcome-supervised reward model whose binary success signal drives the web agent’s update [76]. SEAgent fine-tunes a World-State-Model critic that labels each action and emits the step-level reward the computer-use agent trains on [77].

4.3.3. Two Co-Trained Models

When both roles are trained together, the question becomes what distinguishes genuine cooperation from a relabeled single-role loop. At the far end, both roles become full trainable models that supply each other’s signal. A world model and a policy co-evolve so that the model predicts the feedback the policy learns from [12,258]. Two networks with complementary strengths tutor each other on-policy [259,260,261,262]. A coder and a unit tester co-evolve so that the tester learns directly from the coder’s errors [78,263], and ZeroCoder rewards the coder and tester for reaching consensus rather than for defeating each other [264]. A generator and a generative, process-level verifier are reinforced together to resist the reward hacking that fixed verifiers invite [79]. An extractor and a solver are jointly optimized so that experience is both found and used [265]. An agentic recommender and a user model co-evolve from a shared interaction reward [266]. A skills-manager and a worker share one policy across a reasoning hierarchy [267]. Cooperative agentic pipelines with dedicated planner, verifier, and generator modules belong here as well [268], as do solver and reframer schemes whose second role reframes the input to harden the pseudo-label rather than to defeat the solver [269]. Across this range, the recurring design is the same, because a second model is trained precisely so that its signal remains useful to the first. This deliberate coupling, rather than the diversity of the pairings, makes the group a single mechanism rather than a catalogue.

The cooperative-objective test. The cooperative-objective test that defines this group is also what separates it from self-play at the boundary. DUEL, for instance, builds a challenger that constructs hard negatives, which reads as adversarial. Its purpose, however, is to stabilize the solver’s visual grounding rather than to beat it, so we place it here and flag the ambiguity [270]. The general point is that this group differs from self-play not through the mere presence of a second role, but through a cooperative objective that makes the second role supply guidance to the trainee. An independently trained verifier may provide more informative guidance when its errors differ from the trainee’s, but its control and query permissions determine whether it can also participate in an external audit.

4.3.4. Multi-Agent and Population Signal

The helping role reaches its widest form when a whole group, rather than a single partner, produces the training signal for one model. This is the far end of the cooperative range, since a group can average out an individual helper’s blind spots but also risks a shared bias that no member is positioned to correct. It is separated from the co-trained case because the reliability question shifts from the alignment of one partner to the diversity of the collective.

Forms of collective signal. The signal is then manufactured not by one role or a dyad but by a collective whose incentive structure shapes what the single trained model learns [80,271,272,273]. The forms this takes vary with what the collective is asked to produce, but each extends the cooperative idea from two parties to many. SERM assigns a multi-agent miner-and-annotator pipeline to detect distribution shift and emit reliable labels for a single relevance model [271]. DPE runs the same multi-agent recipe for a multimodal learner. Multiple agents annotate and quality-control unlabeled data with tools such as web search and image editing, generating weakness-targeted samples that a single diagnosed model trains on across successive rounds [81]. ProDa likewise builds its fine-tuning corpus with a multi-LLM pipeline of an extractor, a synthesizer, an LLM judge, and a debugger, so that the signal a separate target model trains on is produced and repaired entirely by other models [274]. Collaborative self-play rewards a team only when it collectively reaches the correct answer. Metacognitive knowledge about when to rely on parameters, when to rely on tools, and when to abstain emerges from this group incentive and is then internalized into one agent’s policy [80]. Multi-agent deliberation has personas negotiate to synthesize a collective-alignment signal [272]. PopuLoRA replaces single-model self-calibration with cross-subpopulation evaluation over a population of LoRA adapters and weight-space evolutionary operators [273].

Error-averaging and its limit. The premise that motivates them all is that a collective can denoise the idiosyncratic errors that trap a lone self-trainer, since a bias one agent holds need not be shared by the group. The promise is thus a form of error-averaging that a single model cannot achieve from inside itself. The risk is that this averaging holds only while the collective’s consensus tracks the truth rather than a bias the whole group happens to share. A further risk is that the consensus itself becomes an optimization target the training loop can learn to satisfy without becoming more correct. The group therefore does not escape the level’s ceiling. It relocates the point at which the self-generated signal can decouple from truth, moving it from a single model’s confidence to a population’s agreement.

4.4. Reliability and the Fixed-Scaffold Limit

Having traced the three groups from a single self-teaching role out to a whole population, we can now state precisely what each one buys and what none of them can. The three relations can be placed side by side by the identity and function of the signal-producing party, each paired with the failure mode it characteristically incurs. The comparison identifies the signal source available to each group and the condition under which that signal remains trustworthy.

Signal source. In the families surveyed here, the training signal is a model-produced label, reward, or preference. The three groups vary only in who produces it, namely a single role in self-training, a competitor in self-play, and a cooperating teacher, critic, or population in cooperative co-evolution. In no case is this signal itself the external target. The groups differ in whether the signal comes from the trainee itself, an opponent, a cooperative role, or a population.

Condition for reliability. In every case, the improvement claim is supported only to the extent that the internal training signal predicts outcomes under the external target. Self-training meets it only while the model’s confident outputs happen to be correct, because nothing in its loop can contradict a confident error. Self-play meets it while the competition keeps injecting learnable information, and it fails when the two copies stop disagreeing. Cooperative co-evolution can add privileged information, distinct errors, or complementary roles, but those properties do not guarantee correctness. Population signal meets it while the collective consensus tracks truth rather than a shared bias. The comparison therefore organizes internal signal sources rather than ranking reliability. Reliability still depends on target-matched external evidence and on who controls the evidence source and acceptance policy.

When the reliability condition breaks, the loop amplifies its own error, and even a stable loop still leaves a fixed scaffold that L1 cannot rewrite.

Failure mode. When the condition fails, self-generated noise is amplified instead of corrected, and the resulting degenerations are the empirical signature of this level rather than incidental bugs. Under self-consumption the effect appears first as model collapse, which is formalized as a change of scaling laws [275]. It also appears as tail-narrowing stagnation, which arises when easy samples are over-sampled and hard ones are starved [276]. A further form is “superficial” self-improvement, which lifts in-distribution accuracy while eroding out-of-distribution generalization [277]. A final form is capability erosion under lifelong adaptation [278]. For self-play specifically, the failure takes the form of stalling. Stalling occurs when the self-synthetic pipeline stops adding learnable information [249], or when data gating and reward grounding no longer hold the loop stable [250]. A complementary line of work explains why the condition is fragile rather than merely reporting that it breaks. One result bounds how closely self-generated supervision can approach oracle supervision [279]. Another shows that problem-solving RL implicitly induces the very process-reward capability it appeared to presuppose [280]. A third stabilizes learning against uncertain feedback through confidence orchestration [281]. At the most abstract, a further group models self-referential recoverability collapse as a structural consequence of capacity saturation [282,283,284,285]. Read together, these analyses explain why the reliability condition above cannot be assumed to hold.

The next ceiling. Two limits force the descent to the next level, and they operate even when the reliability condition does hold. The first is that the model remains trapped in its own distribution, so that retraining is both costly and collapse-prone, which caps how far weight updates alone can carry the system. The second limit is the decisive one. The scaffold around the model, meaning its prompts, tools, memory, and control flow, has stayed hand-coded and fixed throughout this level, and it is frequently the true bottleneck on what the trained weights can express. To break that bottleneck the loop must step outside the model body, so that the object of improvement becomes the scaffold itself rather than the weights it surrounds, which is the move to L2 (§5). Its price continues the pattern established here, because the per-sample self-generated referent of this level is surrendered in turn, leaving end-to-end behavior as the sole remaining observable against which improvement can be judged.

5. L2: Scaffold-Level Self-Evolution

L2 at a Glance

Boundary. L2 persistently changes the scaffold ${\sigma }_k$, including prompts, tools, memory, workflows, topology, skills, and runtime controls. The model state ${\theta }_k$ may also change, but the scaffold remains the deepest active evolution target. The improver ${\mathcal{U}}_k$ and criterion ${\mathcal{C}}_k$ remain fixed. Any audit-supported improvement claim therefore concerns later end-to-end behavior under the declared external target.

Roadmap. We organize the level by the scope of the mutable scaffold, moving from prompts and programs (§5.1) to architecture and workflows (§5.2), skills and experience (§5.3), memory and retrieval (§5.4), and the runtime harness (§5.5).

Reliability focus. Local inspection, compilation, and regression tests can screen individual edits, but they do not establish end-to-end improvement. Promotion should compare the candidate and incumbent on representative later tasks under matched resource conditions, using an external audit outside the update boundary. Versioned provenance and a rollback path should accompany deployment. Component interactions, repeated benchmark access, or silent memory drift can otherwise make the scaffold overfit the development setting.

Scaffold-Level Self-Evolution is the level whose deepest retained rewrite lands on the scaffold ${\sigma }_k$, meaning the prompts, tools, memory policies, communication graphs, and runtime harness around the model, while the improver ${\mathcal{U}}_k$ and the criterion ${\mathcal{C}}_k$ stay fixed (Table ). The model parameters ${\theta }_k$ may also be updated, but they are not the deepest change, so an improvement is consolidated in ${\sigma }_k$ and must be assessed against the external target defined in Section 2.1. The evidence coarsens from per-example supervision to aggregate end-to-end behavior, so the operative question is no longer whether one self-generated example is a valid target, but whether the revised agent behaves better over a representative task distribution. We organize the level by the scope of the mutable object and widen the scaffold one layer at a time, so that each layer widens the causal footprint of an edit and presupposes the objects below it. As the scope widens from a compilable program to a silently retrieved memory entry, the local checks weaken and certification leans increasingly on an end-to-end comparison against the incumbent scaffold. This places the Scaffold-Level between the local supervision of the Model-Level and the update-rule changes of the Improver-Level. Table 4 aligns each method category with its mechanisms and with the check and characteristic failure that govern how hard it is to certify. Figure 6 fixes the cumulative widening of scope from a single artifact to the loop that runs every other layer. Table 5 then indexes representative systems layer by layer, giving for each one the mechanism family it belongs to, the retained move it makes, and a public implementation where one exists.

Boundary and persistence. At L2 (Table ), the deepest retained rewrite is the scaffold ${\sigma }_k$, meaning system prompts, rule files, executable tools, workflow graphs, role pools, routing policies, memory schemas, skill libraries, validators, and runtime controls, while the improver and criterion remain fixed. Writing the retained state as $X_k=({\theta }_k,{\sigma }_k,{\mathcal{U}}_k,{\mathcal{C}}_k)$, the L2 boundary is

$$X_k⟼X_{k+1},{\sigma }_{k+1}{\not\equiv }_{\mathrm{act}}{\sigma }_k,({\mathcal{U}}_{k+1},{\mathcal{C}}_{k+1}){\equiv }_{\mathrm{act}}({\mathcal{U}}_k,{\mathcal{C}}_k),$$

(8)

so a method belongs here whenever the scaffold is the deepest retained change, even when the model parameters ${\theta }_k$ are updated as well, provided the improver and criterion stay fixed. Agentic-RL roadmaps and persistent-agent architectures motivate this scope by treating trajectory protocols, workspaces, skills, and evolution control as first-class parts of learning systems [287,288,289,290]. The object rule keeps mixed systems separable. A learned router, adapter, or verifier is a Model-Level update only when its parameters are retained, whereas an external symbolic policy or validation program stays here. Promoting a new rubric or evaluator protocol instead reaches the Criterion-Level, and retained state that changes how later edits are proposed reaches the Improver-Level. Because the evidence has coarsened from a per-example label to end-to-end behavior, a proposed scaffold must transfer beyond the examples that prompted it, improve beyond a single successful interaction, and keep enough provenance to attribute later regressions. Reliable comparison therefore needs matched budgets, an incumbent scaffold, ablations, and fresh probes rather than a single score.

5.1. Prompts and Programs

Having fixed the scaffold boundary and its behavioral-evidence standard, we begin the scaffold layering at the smallest persistent scaffold: a single text or code artifact revised while the base model stays frozen. A prompt clause, rubric, or program is the most inspectable and auditable editable object, because it is local and, for code, also compilable and testable. It precedes the architecture layer, which composes such artifacts into interacting roles and control flow.

5.1.1. Editing Prompts and Text

This first part covers the smallest scaffold edit, a rewrite of natural-language control surfaces and other human-readable artifacts while the model stays fixed. We separate it from program editing because a text edit is inspected by reading rather than by compiling, so its reliability rests on human judgment rather than on an executable check.

Rewriting the control surface. The base move keeps the model fixed and rewrites the natural-language control surface, meaning orchestration prompts, generation prompts, and test-time prompt configurations, in response to observed failures [82,83,84]. For instance, self-optimizing deep-research orchestration searches prompt combinations through self-play to match or surpass expert hand-written prompts [82]. AutoVQA-G applies the same idea to annotation prompts, refining them through consistency-checked criticism from a prompt-optimization agent [83]. EEVEE goes a step further and co-evolves a task router with per-cluster prompt configurations to limit cross-dataset interference [84]. This is the smallest and most inspectable edit available, but its attribution is weak, because a single reworded instruction can at once alter tool use, evidence selection, and stopping behavior, so gains measured on the tuning stream need held-out confirmation.

Typed, auditable artifacts. A more disciplined branch narrows the edit surface to typed or human-readable artifacts that support localized comparison [85,86,87]. SHARP replaces free-text mutation with atomic edits to a condition-action rubric, and it localizes rule failures with a cross-sample attribution agent under walk-forward validation [85]. Relatedly, Combee scales parallel prompt learning from aggregated trajectories without loss of quality [86]. Meta Context Engineering extends the pattern to reusable context-engineering skills, co-evolving them together with the context files and code they produce [87]. The reliability advantage is inspectability and rollback, because a constrained rubric or context operator makes each accepted change diffable and attributable, unlike opaque free-form rewriting.

Toward the improver boundary. Text edits reach the improver boundary when the retained prompt begins to govern how future prompts are optimized [291]. SePO has the prompt agent optimize its own system prompt alongside the task-agent prompt within an open-ended evolutionary search over a candidate archive [291]. The retained task-agent prompt is a Scaffold-Level object, but the prompt agent’s own retained system prompt governs how future task prompts are optimized and therefore reaches into the Improver-Level. This case marks where text edits stop being purely scaffold and begin to touch the mechanism that proposes edits. The distinction follows from which future process the retained prompt controls, not from self-referential terminology alone.

5.1.2. Editing Programs and Symbolic Artifacts

This second part moves from instructions to executable programs and symbolic rules, which enlarges the reach of an edit while strengthening the local checks available before promotion. It is placed after prompt editing because a program can be compiled, run, and regression-tested, so the reliability question shifts from readability to whether those executable checks predict transfer.

From instructions to programs. The most direct case has a frozen model rewrite an executable artifact under a loop that compiles and scores each candidate [88,292,293]. A frozen model iteratively rewrites the source of the ABC logic-synthesis system under a joint correctness-and-quality loop [88]. SelfEvolve applies the same approach at runtime, synthesizing and integrating new functions to extend a live software system without restart [292]. A game-playing agent likewise refines a Python control policy from execution traces and language feedback [293]. Because a candidate program can be compiled, executed, diffed, and regression-tested, the local evidence is stronger here than for text, but these checks establish syntax and behavior only on covered executions and not transfer.

Program discovery under a simulator. The same propose-compile-evaluate pattern recurs in scientific and algorithmic discovery, where the language model evolves an external program while a simulator or downstream utility decides retention. Instances include a fluid controller refined from simulation diagnostics [294], MLEvolve’s tree-searched AutoML pipelines with retrospective memory [89], co-evolved coupled heuristic operators for combinatorial optimization [295], and archived causal-effect estimators [296]. These loops iterate across generations, which superficially resembles self-improvement, but the improver stays frozen and only the external program evolves, so the retained object is Scaffold-Level rather than Improver-Level, and a one-off controller not carried across tasks is merely an ephemeral output. The characteristic reliability caveat is simulator exploitation, because a program can win on the evaluation harness without transferring.

Screened symbolic rules. A final group generates symbolic rules and structured representations that a verification loop can screen before promotion [90,297,298]. GenTI turns analyst prompts into deployable Snort, Suricata, and YARA intrusion rules through a chain-of-verification pipeline [90]. HIER instead refines injected hierarchical semantic representations from multimodal-LLM feedback at inference time [297]. Dense-feedback policy synthesis produces code-based policies scored by social metrics rather than a single scalar reward [298]. Rejecting malformed artifacts before promotion is a reliability gain, but compilation and unit tests certify only syntax and behavior on covered cases. Held-out end-to-end evaluation is still required to establish broader benefit, which motivates the coarse behavioral-evidence standard that recurs throughout this level. Once individual prompts and programs are editable, the next layer widens the scope from single artifacts to their organization, meaning which roles exist and how control flows between them, and that organization is the agent architecture.

5.2. Architecture and Workflows

Where the previous layer rewrote what a single prompt says or what a program computes, this layer widens the object to how components are organized and how control flows among them. The mutable object is now which roles exist, how they communicate, which tools they may call, and how work is routed through the system. A structural edit changes the interaction pattern rather than one component’s behavior, which places it above the text and code layer. It also fixes the organization within which reusable competence will later accumulate, which places it below the skills layer.

5.2.1. Designing and Searching Structure

This first part concerns the organization itself, ranging from hand-designed staged roles to architectures treated as candidate artifacts scored by an evaluator. We group these together because they all fix or search which roles exist, which is logically prior to how those roles then communicate or accumulate skills.

Staged roles with verifiers. The smallest structural move decomposes a monolithic agent into specialized roles bound by a staged workflow, closing each stage with a verifier so that failure can be localized [91,299,300]. SEMA-RAG illustrates the pattern by separating interpretation, exploration, and adjudication into distinct roles [91]. The same division appears in clinical and planning systems, which instantiate doctor, patient, and measurement roles or policy, world-model, and critic roles [299,301,302]. A stricter variant closes every stage with a check, and these verification-closed pipelines route biological-protocol generation, C-to-synthesizable-C conversion, image restoration, and articulated-CAD assembly through staged verifiers under a central coordinator [300,303,304,305,306]. AgentOrchestra takes the coordination further by placing specialized agents beneath a central conductor through a Tool-Environment-Agent protocol, and it retains the conductor’s memory, tools, and prompts across independent tasks while the base model stays frozen [92]. The reliability contribution is attribution: role separation and per-stage verifiers make it easier to say which component failed. But the decomposition here is designed rather than searched, so it provides evidence about a good hand-built structure rather than about a structural edit that transfers. What persists across tasks is the experience accumulated inside the fixed roles, and not yet a transferable structural edit.

Architecture as candidate artifact. A second group treats the architecture itself as the candidate artifact, searching, recombining, and selecting over a role pool, module graph, or agent configuration [94,307,308,309,310,311,312,313,314,315,316,317]. AgentSquare searches a modular design space of planning, reasoning, tool-use, and memory blocks [94]. GPTSwarm instead casts language agents as computational graphs and runs automatic graph optimizers that both refine node-level prompts and rewire edge connectivity, and it retains an optimized topology that transfers across MMLU, HumanEval, and GAIA [95]. SERO evolves a typed role-card pool and admits a proposal only when it preserves the structural contracts and improves task score [307]. MetaGen rewrites query-conditioned roles and topologies [308]. Further systems evolve reasoning architectures, share exploration across a population, accumulate executable sub-agents, evolve the entire configuration without gradients, or expand a factorized action space [309,318,319,320,321]. These systems are Scaffold-Level only when a selected structure is retained and reused on later independent tasks: MAS-Zero designs a fresh configuration per instance and does not qualify unless that configuration is carried forward, and MetaGen’s per-query generation counts only when a role cache is kept [96,308]. Reliability then turns on transfer beyond the selecting tasks and on matched model calls, tools, and latency, so that additional coordination is not mistaken for a better structure.

Reward-scored workflow synthesis. Workflow-synthesis systems close the search loop with an evaluator or reward signal that scores generated topologies [93,322,323,324]. Mimosa’s meta-orchestrator generates workflow topologies and refines them from an LLM judge [93]. HERA jointly evolves orchestration and role prompts with reward-guided sampling and credit assignment [322]. GraphMind mines operational traces into an executable workflow graph and reinforces the paths that succeed [323]. The Puppeteer paradigm schedules agents through a central orchestrator [324]. Retained workflows are L2 when no deeper active target changes. If persistent optimization experience changes how later workflows are proposed, the realized transition reaches L3. The Puppeteer orchestrator also contains a simultaneous L1 scheduling-policy update, but we cite it here for its retained orchestration structure.

5.2.2. Communication, Routing, and Coupled Edits

This second part holds the set of roles fixed and instead evolves how they communicate and how instructions co-evolve with the tools they call. It is separated from structure search because the edit now targets the interaction pattern rather than the inventory of roles, which raises attribution as the central difficulty.

Communication graph and routing. The first object of this kind is the communication graph together with the routing policy that moves work through it [97,98,99,325]. QueenBee treats the inter-agent DAG as a retrievable design skill and guards each edit with held-out acceptance and motif-level attribution [97]. Along the same lines, TopoEvo, TacoMAS, EVOCHAMBER, and SkillGraph co-adapt edges, expertise, or team composition at test time [98,325,326,327]. Routing-centric designs narrow the object further, and they co-evolve routing with prompts, send problems to disjoint reasoning frameworks as an epistemic-control layer, or route prompts across generative back-ends [99,328,329]. The characteristic risk is confounding: an apparently superior graph may exploit a benchmark-specific ordering, a permissive judge, or extra compute rather than a transferable coordination principle, so a claim should report what persists and control for communication volume and total inference budget. A parametric caveat also applies, because a differentiable or fine-tuned router is a Model-Level update when its parameters are retained, as in the differentiable mixture-of-agents router [330]. By contrast, a symbolic router that changes no weights stays at the Scaffold-Level, and a test-time topology is Scaffold-Level only when the resulting graph crosses the task boundary.

Coupled instruction-tool edits. Structure rarely evolves in isolation: instructions co-evolve with tools, and layered agent architectures are revised from execution traces, so the added reliability requirement is attribution across a widened edit surface [331,332]. EGL-SCA couples an instruction (prompt) space with a tool (program) space under a verifier and uses structural credit assignment to route each failure either to prompt optimization or to tool synthesis and repair [331]. CyberEvolver instead turns noisy execution logs into actionable revision signals through a trace-to-diagnosis mechanism and preserves diverse variants with population-based beam search [332]. Once several structural components change together, a single score cannot reveal which edit helped, and explicit credit assignment is what keeps a coupled-space edit auditable.

5.2.3. Domain Evidence and the Improver Boundary

This third part collects the domain systems that supply most of the layer’s evidence and marks where architecture search begins to press against the improver boundary. It closes the section because these cases test the boundary rather than extend the mechanism, showing when an evolving structure stays Scaffold-Level and when it starts to change how future edits are proposed.

Domain systems as evidence. In these systems a frozen model gains capability because the workflow around it evolves, and the domain supplies the executable or simulator-anchored evidence that certifies each edit [333,334,335,336,337,338,339,340,341,342,343,344,345,346,347,348]. In engineering design, repository-level and multi-agent loops evolve hardware and HLS code, RF amplifiers, power-flow analyses, and catalyst digital twins on executable or simulator-anchored evidence [333,349,350,351,352,353]. In production and operations, comparable systems iterate industrial recommenders, mobility heuristics, safety-critical driving scenarios, cloud defense, literature retrieval, feature-engineering trees, and NOTAM interpretation [334,354,355,356,357,358,359]. In embodied control, further systems evolve modular on-orbit and robotic control stacks [335,360,361]. These systems are Scaffold-Level only when the evolved structure persists and is reused: a configuration produced within a single task and then discarded remains transient, and mixed cases must be split. SpaceMind and the metasurface framework state explicitly that no weights are updated [335,351]. C-NAV instead includes a simultaneous L1 update through feature distillation and replay [362]. Across this family, validation must match models, tools, and latency so that extra coordination or a stronger sub-agent is not mistaken for a better architecture.

Approaching the improver boundary. Toward the outer edge of this layer, architecture search begins to press against the Improver-Level [138,140,363]. AIRA and TacEvo let an LLM search harness autonomously design external neural architectures and training scripts, and BaSE studies how to allocate compute across an evolutionary search [363,364,365]. In each of these the search rule and evaluator stay fixed, so the evolving object is an external artifact rather than the improver itself, and the systems remain Scaffold-Level in substance while only motivating recursive self-improvement. The genuine crossings are EvoTrainer, which co-evolves an LLM policy (a Model-Level update) with a training harness and retained diagnostics that shape subsequent search [140], and TPGO’s meta-learner, which learns from past optimization experience how to propose better edits [138]. Because these retained changes alter the procedure that generates future updates, the complete realized transitions are L3 and are discussed in Section 6. Once these structures begin to accumulate experience across episodes, the question shifts from how components are arranged to which competences should persist and be reinvoked, which is the subject of the next layer on skills.

5.3. Skills and Experience

Once structural search has fixed how roles, tools, and workflows are arranged, the next question is which of the competences those arrangements produce should be retained and reinvoked on later independent tasks. This layer therefore advances from structural configuration to the persistent, invocable competence that configuration yields, widening the mutable object from a system’s organization to its retained experiential state. It sits after architecture because skills accumulate only once components are stably arranged, and before memory because a skill is disciplined experience equipped with an explicit invocation interface and a declared validity domain, whereas general memory can shape behavior with neither.

5.3.1. Forming and Verifying Skills

This first part concerns how a skill is created and checked, from a distilled trajectory to a form a verifier can screen before promotion. We treat formation before governance and sharing because a bank can only be curated or distributed once its entries exist and can be validated.

Distilling trajectories into skills. The base move of this layer is to distill successful and failed trajectories into named, retrievable artifacts, such as natural-language strategies, self-evolving rewrite rules, reflective heuristics, metacognitive knowledge, or visual concepts, that a frozen model consults through an explicit retrieval-and-injection interface [100,366,367,368,369,370,371,372,373,374,375,376,377,378,379,380,381]. What distinguishes such an entry from a raw episode is that it is meant to be invoked on independent tasks and carries an implicit validity domain, whether an input type or a task class. This is why early lifelong learners already pair accumulation with input-type routing and with explicit create, validate, and retire operations over rules [29,382,383]. For reliability, the operative question thus shifts from whether the library grows to whether an invoked entry transfers beyond the trajectory that produced it, and playbook-style artifacts push this further by claiming transfer even to weaker backbones [384]. As a strength-of-evidence caveat, EvolveR is a mixed system whose policy-reinforcement component is a Model-Level (weight) update [385]. It is cited here only for its persistent external rule store, not as a scaffold-only method.

Skills as verifiable programs. Representing a skill as a program, a logic-grounded procedure, a callable tool, or a formally specified contract narrows its invocation interface and strengthens the local evidence available before promotion, because a candidate can then be compiled, model-checked, or rejected by a verifier. Some hybrids go further and crystallize recurring plans into deterministic code that needs no inference-time model call [386,387,388,389]. Verification-guided systems turn counterexample traces into text-gradient revisions of the skill contract, and co-evolving surrogate verifiers can vet multi-file skill packages when ground-truth tests are absent [101,102]. For reliability, however, formal or execution checks establish syntax and behavior only on the executions they cover, so held-out, end-to-end evidence remains necessary to establish transferable benefit. On classification, VASO (skill contracts) and KBSpec (an evolving formal knowledge base) were originally flagged as Improver-Level boundary cases. Yet their base weights stay frozen and they include no self-modifying improver, so they evolve a skill or specification artifact rather than the improver itself, and they appear here as Scaffold-Level cases [102,390].

5.3.2. Governing the Library

This second part treats the skill bank as an object with a lifecycle, covering admission, revision, typed composition, and retirement. It is separated from formation because the reliability concern is no longer whether one skill is valid but whether the bank as a whole stays useful as it grows.

Lifecycle governance. The first requirement of such governance is an admission rule that keeps the bank from growing without control [103,104,391,392,393,394,395,396,397,398]. Such stores admit a candidate only when it yields a net improvement on balanced held-out probes under a hard regression budget, revise skills from execution evidence, and expose explicit create, improve, merge, and retire operators with provenance and rollback [103,104,391,399,400]. Selection is increasingly multi-objective over utility, cost, and regression risk, whether in Pareto or training-free-GRPO style [105,401,402]. Error-driven revision clusters failures, for example into missing, wrong, or conflicting cases, and turns them into targeted patches that are committed only when a regression gate passes and can compile to auditable deterministic code [403,404]. What separates cumulative capability from library bloat is a sequestered acceptance set together with regression accounting, and a useful counterfactual asks whether removing an entry degrades fresh-task performance, while still allowing for redundant or substitutable skills. A recurring hazard, framed as an empirical finding rather than a definition, is silent regression: an added skill can improve its targeted cases yet quietly break previously correct behavior, which is precisely what admission gates and rollback are designed to catch.

Typed composition and tool co-evolution. As libraries scale, skills must be selected and combined without silently changing meaning, which calls for typed interfaces, explicit dependency and conflict structure, and skills that co-evolve with the tools they call [106,405,406]. Typed skill graphs meet part of this need by exposing a structural retrieval interface and registering edges only with execution evidence under a propose-then-commit protocol [106]. In the same spirit, ecological utility models bind competence to executable tool interfaces and retire recorded anti-patterns [405,407], while on-demand tool forging recycles verified procedures back into the callable set [406,408]. On-demand tool generation extends this to whole toolboxes. A generalist agent with minimal predefinition dynamically forges and persists callable MCP tools in a reusable toolbox across independent tasks [107], and a closed-loop orchestration pipeline maintains a persistent tool dataset of generated tools that later tasks reuse [409]. In both cases callable capability accumulates while the base model stays frozen. Explicit contracts and conflict signals make composition auditable and let a later regression be localized to a specific edge, skill, or tool, which flat skill lists cannot support. Several of these systems also contain trained sub-components, such as a jointly optimized planner, that are separate Model-Level updates and are cited here only for the scaffold-level skill and tool structure they retain.

5.3.3. Sharing and Deploying Skills

This third part concerns the largest scope, where skills become shared assets that move across agents, models, or users rather than staying private to one agent. It follows governance because sharing adds a compatibility requirement on top of curation, so a bad entry can now propagate beyond the agent that created it.

Shared skill assets. As shared assets rather than private notes, these skills take several forms: living knowledge bases link heterogeneous resources to provenance-bearing reusable skills, validated skill packages are assembled from scientific corpora, and portable specifications or federated skill diffs move competence across agents, models, and clients without a common weight update [108,410,411,412,413]. Open-world and collective variants bootstrap or synchronize libraries that transfer across models through self-built verification anchors and cross-user aggregation, and they add institutional safeguards such as audit separation, contract protocols, and organizational memory to guard against knowledge degradation [414,415,416]. Sharing introduces a new compatibility requirement: interfaces and semantic versions must remain valid across models, tools, and users, so transfer success must be measured separately from within-agent reuse. Shared stores also raise the stakes of admission, because a bad entry now propagates.

Domain deployments. Most of the empirical support for this layer comes from domain deployments that wrap a frozen model in an evolving skill or heuristic library, and these deployments share the coarse, end-to-end evidentiary burden of the level [417,418,419,420,421,422,423,424,425,426,427,428,429]. In embodied navigation and manipulation, agents distill trajectories into scene-aware or heuristic skill libraries with confidence-gated retrieval and pre-action foresight, and robot-design trials are turned into transferable skills [417,430,431,432,433,434,435,436]. Web agents built on a frozen model autonomously discover and hone a library of lightweight, plug-and-play APIs that persist and are reused across tasks [13]. Medical, emotional-support, and recommendation agents accumulate value-aware, procedural, or per-user policy skills [418,437,438,439,440,441,442,443], and a biomedical research agent distills successful reasoning strategies into reusable templates archived in a growing library and tool collection that a frozen base consults across tasks [444]. Software, data-science, and finance agents record which repair procedures or edit motifs succeed and which fail [419,445,446,447,448,449,450,451,452], and multimodal agents evolve skill harnesses for image workflows, retrieval, few-shot reasoning, and guide-to-skill distillation [453,454,455,456,457,458,459,460]. These settings expose the same failure risk as the layer as a whole, namely fitting benchmark, judge, or router quirks rather than a transferable procedure, and the strongest instances pair accumulation with execution-anchored validation and with explicit cautionary failure entries rather than storing only successes. Skills expose competence through an explicit invocation interface and a declared validity domain. The next layer widens the scope to governable memory, where retained experience can influence later behavior without any such interface or local validity check.

5.4. Memory and Retrieval

Skills expose reusable competence through an explicit invocation interface, whereas persistent memory removes that boundary, so a single stored entry can steer a later decision without ever being deliberately called. This layer therefore extends the mutable scaffold to its widest and least-visible causal footprint within the Scaffold-Level. It sits after skills because dropping the invocation boundary also drops the local validity check that made a skill auditable, and before the runtime harness because governing these silent writes is exactly what motivates a versioned, replayable execution substrate.

5.4.1. Write and Recall Policy

This first part concerns the operations over the store and the policy that governs what to write and recall, made auditable and in some systems adaptive. We treat the policy before the store’s structure because what enters and leaves memory is prior to how the retained entries are then organized.

Typed, auditable writes. Because a memory entry can shape a later decision without being explicitly invoked, the reliability question shifts from whether an artifact was called correctly to what silently entered context and whether that write can be inspected [109,461,462]. A first group answers this by replacing free-form summarization with typed, auditable operations over the store. ACE treats the context as an evolving playbook and updates it through structured incremental edits that avoid the context collapse produced by iterative rewriting [109]. In the same spirit, Evo-RAD casts evidence acquisition as an MDP with explicit DELETE, INSERT, and TERMINATE moves [461], while Thought-Retriever narrows what is stored to reusable intermediate reasoning rather than raw chunks [462]. MemRes follows the same typed approach and accumulates structured, reusable resolution patterns in a domain error-pattern base [463]. Evo-RAD’s GRPO-trained graph agent is a simultaneous L1 update. We cite the system here only for its structured evidence operations over the retained store. A typed write surface is diffable and attributable, whereas unconstrained rewriting leaves no record of what changed or why.

Adaptive write and recall policy. Beyond fixing the operation set, several systems make the policy governing what to write and recall itself adaptive while leaving base weights fixed [110,111,464,465,466]. MemRL applies reinforcement learning over episodic memory but is explicitly nonparametric, so the update lands on the retained store rather than the model, and it remains Scaffold-Level despite the RL label [111]. ReasoningBank distills generalizable strategies from self-judged successes and failures, then retrieves and rewrites them at test time and scales the process with memory-aware test-time search [110]. MemSkill recasts memory operations as learnable memory skills and pairs a controller that selects them with a designer that reviews hard cases to propose new ones [464]. MetaMem evolves a meta-memory that governs how stored knowledge is used [465]. SEDM goes further by adding a distributed controller that admits writes through reproducible replay, then ranks and consolidates entries by empirical utility. Its cross-domain knowledge diffusion abstracts reusable insights so that entries transfer and evolve across heterogeneous tasks while the base stays frozen [466]. The taxonomy boundary is the operative caveat: a curator whose parameters are trained and retained is a Model-Level update, even when the store it governs remains a Scaffold-Level object.

5.4.2. Structure and Silent Injection

This second part concerns how the store is organized and how its entries reach later behavior when they are injected silently rather than by a deliberate call. It follows the write policy because organization determines what remains retrievable, and silent injection is the risk that makes this layer harder to audit than skills.

Structuring the store. How the store is organized decides what stays retrievable and whether a later regression can be localized, so a second line of work structures the store itself rather than the write policy [112,114,467,468,469,470]. xMemory decouples interaction history into a revisable message-to-fragment-to-component-to-group hierarchy that is maintained incrementally [112]. H-Mem combines temporal and semantic trees with a knowledge graph so that short-term entries consolidate into long-term ones [467]. SE-GA layers episodic, semantic, and experiential memory for test-time extension, while its MASE stage adds a simultaneous L1 update by training the base policy [468]. AI-Agent School maintains parallel experience and knowledge stores [471]. SHIMI organizes memory into layered semantic nodes and supports top-down traversal from abstract intent to specific entities, with agents maintaining local hierarchical memory trees that are synchronized asynchronously, so the layered structure persists and shapes retrieval on later tasks without base-model training [469]. SGMem represents dialogue as sentence-level graphs and combines retrieved raw turns with generated summaries, facts, and insights that persist across conversations to supply the frozen LLM with accumulated long-term-dialogue context [470]. RGMem borrows renormalization-group coarse-graining to consolidate episodic dialogue into stable user profiles [114], and AutoAgent orchestrates elastic prompt-level cognition over the store [472]. Consolidation controls which state stays active, but every compression step is also a chance to discard the provenance needed to audit a later failure.

Silent injection over long horizons. The defining risk of the layer becomes concrete when experience is injected by retrieval or runtime hooks rather than by a deliberate call, since it then shapes behavior with no local validity check [113,473,474,475]. WebCoach condenses cross-session navigation logs and injects advice through runtime hooks, remaining model-agnostic and requiring no retraining [113]. PRINCIPLES derives a reusable synthetic strategy memory from offline self-play to guide planning at inference [473]. PRIME accumulates user preferences together with success and failure modes without gradients, then evolves them with meta-operators [474]. The FRIDAY agent of OS-Copilot, built on a frozen LLM, accumulates tools and skills into a self-improving procedural memory after successful completions and generalizes to unseen applications in a generalist-computer-agent setting [475]. Mem²Evolve co-evolves an experience memory with an asset memory that spawns tools and sub-agents [476], and NavMorph and Richelieu maintain contextual or self-play memory that adapts online in navigation and diplomacy [477,478]. Because these stores condition tool use and planning silently and persistently, their effect must be measured over long horizons rather than within the session that wrote them.

5.4.3. Provenance and Deletion

This third part treats temporal provenance and validated deletion as part of the learning rule rather than as mere capacity management. It closes the layer because a store that only grows eventually accumulates stale or conflicting entries, so what is removed matters as much as what is written.

Temporal provenance and reconciliation. Persistent state accumulates stale and contradictory entries, so these systems add temporal provenance and query-time reconciliation [115,479,480]. APEX-MEM keeps an append-only property graph that preserves the full temporal evolution of the store and uses a multi-tool retrieval agent to resolve conflicting or evolving facts at read time [115]. MemoTime attaches a temporal knowledge graph and stores verified reasoning traces and tool decisions for reuse [479]. ARIA maintains a timestamped knowledge base, evaluates its own uncertainty, and requests human guidance to detect and resolve conflicts or outdated knowledge [480]. Temporal provenance is what lets the system tell a stale fact from a current one, and conflict resolution is needed precisely when user preferences, world state, or learned procedures disagree, and neither capability is achievable over an undated flat store.

Deletion as a learning rule. The layer culminates in treating deletion and demotion as part of the learning rule rather than as capacity management [116,481,482]. ReMe manages a procedural-memory lifecycle with utility-based refinement that actively removes stale entries to keep the pool compact [116], and Live-Evo learns online from continuous feedback, reweighting useful experience while forgetting misleading or stale entries under distribution drift [481]. A cautionary case sharpens why such filtering is not optional. CTIM-Rover augments a software-engineering agent with a cross-task-instance episodic memory retained across tasks on a frozen base, yet it fails to outperform its memoryless baseline in any configuration. The reported analysis attributes the degradation to noise from distracting retained items rather than to accumulated useful knowledge [117]. This negative finding is direct evidence that an unfiltered store persisting across tasks can accumulate noise instead of competence, reinforcing that continuous writing without validated deletion is itself a reliability hazard. The interpretive claim that closes the layer is that continuously rewritten memory can degrade even when it was initially useful, so a deletion must be validated by replay against retained raw episodes to confirm that it repairs one failure without silently reintroducing another. This is the Scaffold-Level analogue of Model-Level self-consumption, because the weights are unchanged yet future behavior is conditioned on state produced by earlier, potentially incorrect system behavior. Because memory has a wider and less-visible causal footprint than an explicit skill, promotion and retirement here should be judged over longer horizons and with probes that exercise retrieval, tool use, and downstream decisions together. Because memory writes act silently and over long horizons, they demand an execution substrate that can version, replay, and roll them back, which is the runtime harness that governs every scaffold edit and forms the final layer.

5.5. Runtime Harness

Skills and memory settle which experience persists, whereas the harness settles how every persistent component is invoked, observed, and committed. This closing layer therefore widens the mutable scaffold from the objects being run to the loop that runs them: the harness builds context, calls tools, observes traces, attributes failures, and executes internal checks, while the fixed improver controls proposal, internal selection, commit, and rollback. It sits last because the harness is the substrate that executes and observes every earlier layer, so making it writable subsumes prompts, architecture, skills, and memory under one editable loop. It is also the thinnest layer, since much apparent loop engineering retains trained weights and therefore belongs to the Model-Level rather than the scaffold.

5.5.1. The Harness as Peripheral Object

This first part treats the harness from the outside, either analyzing its feedback channel or building it into a verification apparatus. We separate these cases because neither retains the harness as an evolved object, so they set up the contrast with the durable-harness systems that follow.

Feedback channel as object. The first such move studies the harness’s feedback channel rather than the harness as a whole. CUDAnalyst freezes trajectories and selectively injects individual feedback components, using coalition-style attribution to identify which signals actually drive planning decisions in CUDA-kernel generation [118]. Its reliability contribution is observability and causal attribution inside the loop, because it renders the feedback-to-plan pathway diagnosable rather than opaque, so that a later gain can be traced to a specific reasoning-feedback interaction. This remains a diagnostic analysis of the loop’s peripheral feedback mechanism with no weight change, and such attribution supports, but does not by itself constitute, a persistent scaffold update.

Harness as verification apparatus. A related move makes the harness itself the verification apparatus. AutonomyLens unifies scenario specification, simulation execution, telemetry analysis, and counterfactual test generation into a single self-evolving testing loop for autonomous systems, synthesizing new test cases from observed failures to close the loop [119]. Here the harness is the machinery that produces the end-to-end behavioral evidence on which the Scaffold-Level regime depends. Yet building a testing loop is distinct from certifying a persistent scaffold gain, because this is engineering of the verification harness, a peripheral program with no weight update, so the loop generates evidence rather than constituting the retained capability itself. A writable testing harness can therefore supply development evidence, but it cannot serve as the external audit of its own update.

5.5.2. The Harness as Retained Program

This second part covers the systems that retain the harness itself as a durable program which governs every lower layer within one loop. It follows the peripheral cases because here the loop is the evolved object rather than a fixed wrapper, which is the deepest form a scaffold edit can take.

Harness as durable program. A cluster of systems makes the harness the durable, evolvable program rather than a fixed wrapper. M^★ evolves task-specific memory harnesses by iteratively adding and removing retrieval, indexing, and scoring mechanisms from a RAG baseline, so that each task receives a customized executable memory loop [121]. In the same spirit, Milkyway maintains a persistent, editable prediction harness of reusable procedural guidance, updating it from pre-resolution signals gathered by repeatedly revisiting unresolved questions [483]. Meta-Harness treats the whole harness as the optimization target and has a coding agent search the full execution history, logs, and source of prior runs rather than a compressed summary. Each retained edit to context construction, tool use, error recovery, and state management is therefore grounded in complete diagnostic evidence [122]. Self-Harness structures the same idea as a repeating loop that mines weakness patterns, proposes a harness improvement, and admits it only after regression verification, which makes internal admission explicit rather than implicit [123]. SemaClaw carries the same durable-harness view into production personal agents, organizing execution through a two-phase orchestration graph with tiered context management and an explicit permission layer. The harness rather than the frozen model thereby becomes the auditable and controllable object [124].

Specializing the harness object. Other systems keep the durable-harness view but vary how much of it is placed under evolution. HarnessForge is a mixed case that co-adapts the retained harness together with the internal reasoning policy. The realized transition is L2 with a simultaneous L1 policy update, and we cite it here for the harness change [125]. AutoHarness narrows the object to the guard code itself, automatically synthesizing the harness that wraps a frozen agent so that prohibited or invalid actions are caught before execution rather than corrected afterward. This replaces the hand-written harnesses that such systems usually require [120]. LedgerAgent instead makes the harness state explicit, maintaining a persistent ledger of the facts, identifiers, and constraints observed across turns. Policy-adherent tool calls then read from a retained structured state rather than reconstructing it from the prompt on every step [484].

Scaling and navigating the harness. A further group scales the retained harness across cases and makes its codebase navigable for the next edit. MemoHarness treats the whole harness as the adaptive object, learning from its own executions to adjust six editable control dimensions, namely context, tools, orchestration, memory, decoding, and output handling, per case rather than reusing one global harness for every task [126]. The Last Harness pushes this to two levels, pairing a per-task harness-evolution loop with a cross-task meta-evolution loop that generalizes harness blueprints. We read the retained object here as the harness itself, while noting that the meta-loop begins to touch the improver machinery formalized in Section 6 [127]. A complementary line makes the harness itself navigable, since before any edit can be applied a developer or coding agent must first find every code location that implements the target behavior. The Harness Handbook synthesizes a behavior-centric representation of a harness codebase through static analysis and LLM-assisted structuring, linking each behavior to its source and guiding edits from high-level behavior to implementation. It thereby treats behavior localization rather than edit generation as the central bottleneck in harness evolution [128]. Across these harness-as-program systems the retained Scaffold-Level object is an executable harness, checkable by execution rather than only by prose.

Capstone: governing every layer. Continual Harness is the capstone case, a reset-free, online self-improving harness for embodied agents that alternately executes and refines its own prompts, subagents, skills, and memory from a minimal environment interface [129]. It shows the runtime substrate governing every earlier layer within a single loop, which is why it sits last in the progression. As a mixed system, it also contains a teacher-relabeling co-learning step that updates the model at L1. We cite it here for the retained harness change, which is the deeper L2 target. The harness completes the scaffold-scope layering, yet every harness edit is still proposed, internally selected, and committed by a fixed improver. External acceptance remains a separate decision made by the acceptance policy, which motivates the reliability accounting for scaffold overfitting and the subsequent move to Improver-Level Self-Evolution, where the internal update procedure itself becomes writable.

5.6. Reliability and the Fixed-Improver Limit

The closing observation of Section 5.4, that continuously rewritten memory can silently corrupt future behavior as the Scaffold-Level analogue of Model-Level self-consumption, shows that local component-level checks are insufficient to certify a scaffold edit. This section steps back from individual mutable objects to ask what single standard of evidence certifies any scaffold edit once weights are held fixed and the signal has coarsened to end-to-end behavior. It supplies the Scaffold-Level analysis summarized later in the cross-level reliability ledger of Table 8: the external audit, reliability condition, characteristic failure mode, and fixed-improver ceiling. The reliability column of Table 4 already set the five method categories side by side on the axis that governs how hard each is to certify, pairing the strongest locally available check with the failure that check cannot catch. The following analysis identifies the external audit that can certify a scaffold edit and the condition a revised scaffold must meet before promotion.

External audit. The certifying evidence for a scaffold edit is a controlled end-to-end comparison of the revised agent against its incumbent scaffold on tasks the edit did not select. It is not an aggregate benchmark number, which conflates the edit’s contribution with sample luck, extra tool calls, more retrieved context, or a more permissive judge. The load-bearing support is the decoupling of two abilities that are usually collapsed, namely producing a persistent scaffold update from execution evidence (harness-updating) as distinct from actually benefiting from that update at solve time (harness-benefit) [286]. At its stated strength the finding is that updating is roughly flat in base-model capability while benefit is non-monotonic, and this holds as an empirical result on specific models rather than a law. The decoupling therefore explains why a successful update and a higher score do not by themselves certify improvement under the declared external target. It anchors the reliability analysis that follows.

Reliability condition. The reliability condition requires representative fresh tasks evaluated under matched models, tools, token budgets, and stopping rules. It also requires acceptance gates whose evidence the proposer cannot query indefinitely, together with a tested rollback path. For accumulating stores the condition sharpens into bounded lifecycle management rather than append-only growth. SkillBrew formalizes skill-bank curation as a constrained multi-objective problem over usefulness, diversity, and coverage, solved by a bi-level propose-then-verify loop, so that redundant, outdated, or harmful skills are removed rather than merely accumulated [485]. A more minimal variant, Ratchet, works around a frozen model and combines outcome-driven retirement, a bounded active cap, meta-skill authoring guidance, and schema normalization [486]. Its non-divergence result should be read as a stated proposition under its assumptions, that performance should not fall below the no-skill baseline, which is the external anchor that makes rollback meaningful. Matched budgets matter throughout, so that additional coordination or compute is not mistaken for a better scaffold. Two consequences follow from this evidence standard. The first is a characteristic failure mode, scaffold overfitting, and the second is that even a well-audited scaffold leaves the fixed improver as the ceiling that the next level takes as its object.

Failure mode: scaffold overfitting. The characteristic failure is scaffold overfitting, which fits benchmark, judge, memory, or router quirks rather than a transferable procedure, and it appears in three diagnosable variants. First, holdout erosion and long-horizon drift turn a repeatedly queried nominal holdout into adaptive development evidence. A 391-consecutive-session action study reports this pattern: trading more formal and symbolic constraints for reliability backfired, and the system degraded into symbol-layer self-reference at the expense of task semantics [487]. This evidence remains a single-project case study rather than a general law. Second, component-interaction confounds arise because errors surface late in long multi-agent trajectories and dependencies intertwine, so a candidate can look better only because work shifted or context grew, which means failure must be localized to responsible agents, steps, and harness artifacts. ErrorProbe performs symptom-driven back-tracing plus verified episodic-memory updates committed only on confirmed evidence, and HARNESSFIX maps trace-grounded attribution to scoped repair operators accepted under regression-aware validation [488,489]. Third, silent store drift appears when a locally beneficial edit degrades behavior after the retrieval policy or neighboring skills change, which Library Drift documents with a reproducible drift-trigger ablation together with per-skill contribution scores and routing-participation logs [490]. Across these variants, a local check can miss failures that emerge only through component interactions, repeated use, or later retrieval. These failures are precisely why the external audit must be a controlled procedure rather than a score.

The next ceiling. No scaffold edit removes the final ceiling, because even a fully editable scaffold is optimized by a fixed, hand-built improver that determines which edits can be proposed, how candidates are internally selected, and how exploration is budgeted, while the fixed criterion supplies the internal judgment rules. Under tight evaluation budgets this improver choice is consequential in its own right. A systematic comparison covers Elo-tournament selection in RoboPhD, Pareto selection, and greedy hill-climbing under a fixed evaluation budget [491]. RoboPhD also uses validation-free evolution with Elo scores computed on training data. Together, these settings show that the improver, not the scaffold alone, governs which candidates are generated and selected internally. Whether those candidates should be accepted and promoted remains a question for an external acceptance policy using target-matched evidence. RoboPhD is strictly an Improver-Level boundary case, because its object is the optimization paradigm itself, so under the survey’s numbering it belongs to the Improver-Level section (§6) and must not be read as a Scaffold-Level capability result. Making the improver writable is what Section 6 examines: the procedure proposing, selecting, committing, and rolling back scaffold edits becomes the evolution target rather than a fixed update process.

6. L3: Improver-Level Self-Evolution

L3 at a Glance

Boundary. L3 persistently changes the improver ${\mathcal{U}}_k$, the procedure that proposes, selects, commits, or rolls back later updates. Here, self-reference means that the current improver helps produce or internally select a candidate successor that can become the retained ${\mathcal{U}}_{k+1}$ after external audit and promotion. The criterion ${\mathcal{C}}_k$ remains fixed, so any audit-supported improvement claim concerns future update production rather than criterion validity.

Roadmap. We examine self-referential agents (§6.1), learned improvement strategies (§6.2), and reliability under a fixed criterion (§6.3).

Reliability focus. Internal traces, archive results, and descendant scores can identify a promising improver, but they do not establish that it produces better future updates. The declared external target and matched resource conditions define the comparison, a protected evidence source supplies fresh-task results, and an acceptance policy outside the update boundary maps that evidence to accept, reject, or escalate. Only a candidate accepted under that policy should be promoted, with versioned lineage and a tested rollback path. Otherwise, metric capture or correlated self-evaluation can favor an improver without corresponding improvement relative to the declared external target.

Section 5 allows persistent changes to prompts, memory, workflows, runtime harness, and other scaffold components while the improver stays fixed. The improver ${\mathcal{U}}_k$ is the mechanism that proposes, selects, commits, or rolls back candidate changes. It may interpret experience, allocate search resources, and make selection decisions. It does not define the criterion used to judge candidates. The criterion ${\mathcal{C}}_k$ stays fixed in L3, so the claim concerns the quality of later update production rather than the validity of the criterion.

Boundary and persistence. Writing the retained state as $X_k=({\theta }_k,{\sigma }_k,{\mathcal{U}}_k,{\mathcal{C}}_k)$, as in Equation (1), the L3 boundary is

$$X_k⟼X_{k+1},{\mathcal{U}}_{k+1}{\not\equiv }_{\mathrm{act}}{\mathcal{U}}_k,{\mathcal{C}}_{k+1}{\equiv }_{\mathrm{act}}{\mathcal{C}}_k,$$

(9)

A transition is L3 when the improver is the deepest component whose active semantics change and causally affect later updates. The model parameters ${\theta }_k$ or scaffold ${\sigma }_k$ may also change in the same transition, but the criterion must remain fixed. A practical test first ignores the answer, algorithm, or task solver produced in the current round. It then asks whether the next round would propose, select, commit, or roll back changes differently because of what was retained. If the same update procedure still controls those actions, classify the transition by the retained target that actually changed. A model-state change is L1, an installed runtime-structure change is L2, and a transition with no retained agent-state change is L0. A standalone artifact outside the retained agent state does not by itself constitute an L3 transition.

Self-reference. Self-reference is a functional relation rather than a system name. Recursive calls or source-code editing alone do not establish it. It is present only when the current improver helps modify its own successor and the retained modification affects later update rounds. The required evidence is a retained causal change in how future updates are made.

Table 6 groups representative systems under the section’s two main mechanism families. It compares the L3-relevant retained change, the internal signal or screening rule, and the main limitation. Figure 7 shows how both mechanism families produce a candidate improver under a fixed criterion.

6.1. Self-Referential Agents

6.1.1. Proof-Based Self-Modification

Proof-gated self-modification. Proof-based methods turn the decision to install a self-modification into an explicit proof obligation. They therefore provide a clear formal starting point for self-referential updating. The Gödel Machine searches for rewrites under fixed axioms and a fixed utility function. It executes a rewrite only after proving that the rewrite has higher expected utility than continued search [130]. The proof searcher is also part of the writable program. The machine can therefore change both its task policy and the process that finds and certifies later changes.

Limits of formal guarantees. The guarantee is conditional rather than a general safety result for real agents. The formal result need not imply target-relative gains in deployment if the axioms omit relevant facts or the utility function misses the intended goal. It also provides no practical gain when the proof system cannot find a proof within the available budget [130]. The Gödel Machine makes the logic of L3 explicit, but its proof-gated installation rule remains tied to a fixed criterion. Later empirical systems replace full proofs with task scores, backtesting, or lineage performance. This makes the mechanism easier to apply, but shifts the reliability burden to evaluation coverage, matched resources, and control over benchmark access.

6.1.2. Code-Based Self-Modification

Direct code self-modification. Source code is a general way to implement self-reference. The key issue is whether a retained edit changes the code that controls future updating. Gödel Agent separates a task policy ${\pi }_t$ from a self-referential learning algorithm $I_t$. The current $I_t$ produces both ${\pi }_{t+1}$ and $I_{t+1}$, rather than changing only the task policy [131]. Its implementation reads its own functions, classes, and other code from Python runtime memory. It uses monkey patching to add, replace, or remove logic. A recursive main function runs the changed learning logic at the next depth [131]. This mechanism meets the functional condition for self-reference. Its task feedback still comes from a fixed high-level goal and environment interface, so it does not provide a Gödel Machine proof guarantee.

Combining task and improvement logic. Code-based systems also span a range from generating an improvement algorithm to combining task and meta-improvement logic. Self-Developing proposes, implements, and refines executable improvement algorithms. A fixed outer evaluation and preference process guides this algorithm search [133]. A retained algorithm can later control model merging or another update. Otherwise, it remains an artifact produced by a fixed search process. SICA selects a strong agent from its archive to perform the next meta-improvement step. That agent reads the archive, proposes a change, and edits its full Python codebase [132]. Fixed utility and benchmark checks decide whether the new code enters the archive. The agent’s task ability can help with later meta-improvement, but outer rules still set cost, speed, and benchmark weights [132]. HyperAgents places the task agent and the meta-agent that can modify both agents in one editable program. It also allows the meta-improvement process to change itself [492]. Reported changes such as persistent memory and performance tracking affect how later agents are produced.

Separating task code from update code. Practical systems often edit task code and control code in the same repository. MOSS can rewrite an agent’s source code and test candidates through replay and trial runs. Its fixed pipeline also provides rollback after provisional installation. Its stage order, arbitration, and coding tools remain in a fixed pipeline [493]. Live-SWE-agent keeps editing its scaffold while it solves software tasks [494]. PACE alternates between faster prompt updates and slower control-logic updates. It admits control-logic candidates after held-out validation [312]. Across these systems, task-execution edits must be separated from edits to the update process.

6.1.3. Open-Ended Agent Evolution

Archive-based evolution. Open-ended evolution extends one self-modification chain into a population that keeps several search paths. This openness does not imply that the outer search rules also change. The Darwin Gödel Machine (DGM) selects a parent agent from an archive. The parent reads its benchmark logs, proposes a feature change, and edits its own code. Coding benchmarks evaluate the new agent before it enters the archive [14]. The new agent can later become a parent and produce further agents. Its retained code can therefore change future self-modification rather than only one task output [14]. Archive management, the parent-selection formula, the base model, and benchmarks such as SWE-bench and Polyglot remain fixed. The reported evidence therefore supports only a benchmark-scoped claim about archived descendants under the stated budgets and selection rules. It does not support improvement claims outside the tested domains or evaluation horizons [14].

Evaluating future improvement. Open-ended search also exposes a gap between current performance and future improvement ability. The Huxley–Gödel Machine selects agents using both current coding scores and the aggregate performance of several descendants. The aggregate estimates a lineage’s ability to produce later higher-scoring descendants [134]. This longer horizon can preserve a parent with modest current performance but strong later potential. The estimate is not external audit evidence because it shares fixed coding benchmarks and search budgets with candidate selection. Long-term update productivity beyond the reported evaluation horizon remains unobserved. Lineage evidence can compare how improvers produce later benchmark gains, but external audit still requires fresh tasks, matched resources, and longer horizons.

6.2. Learning Better Improvement Strategies

6.2.1. Learning from Failures and Experience

Learning repair policies from failures. Stored experience can become a retained policy that changes later proposals, filtering, or rollback. Polaris turns failure traces into small policy-code patches through failure analysis, policy formation, and experience abstraction. Conservative checks select patches that are then used on unseen instances from the same benchmark [137]. The important change is not the stored failure itself. The patch changes how later failures are analyzed and repaired. A fixed patch format, validation set, and outer loop still limit this self-referential process.

Using experience in later updates. TPGO represents a multi-agent system as a graph of textual parameters. It derives textual gradients from execution traces to locate faults. The mechanism studies past successes and failures, so later proposals change with optimization experience [138]. A single graph-node edit changes the current system, while retained GRAO experience can change the distribution of later proposals. Meta Context Engineering evolves both context artifacts and context-engineering skills. Its meta-agent searches with skill history, execution, and evaluation, so reusable skills affect later context construction [87]. Some skills support task execution, while others guide how later context changes are searched, combined, or selected for reuse. These studies need causal tests that separate stored content from changes to the improvement strategy.

6.2.2. Adapting Search and Training

Self-applied search strategies. Adaptive search and training can change the search target, model weights, or the search procedure itself. STOP gives a seed improver to itself as an input program. It uses the resulting scaffolding improver for later program generation [135]. The language model, utility function, and outer self-application process remain fixed. Promptbreeder evolves task prompts and the mutation prompts that control later task-prompt mutations. Only retained mutation prompts that control future mutations change the improver [136]. Retained task prompts remain scaffold changes. SePO optimizes both the task agent’s system prompt and the prompt agent’s own system prompt. After multi-task pretraining, the prompt agent’s retained prompt continues to guide prompt optimization on target tasks [291]. Its archive search, fitness evaluation, and base model remain fixed. These systems expose local self-application, but they do not make the whole improvement process writable.

Adapting training strategies. Larger training systems place changes to the improvement strategy inside training operations and backtesting. A-Evolve-Training changes the requested search direction when an internal development metric stops tracking a fixed performance measure. It avoids continuing to optimize a failed proxy [139]. When the switch persists into later interventions, it changes the search strategy rather than the fixed performance measure. Changes to the judgment used for internal candidate selection belong to the criterion and are discussed in Section 7. Search actions and judgment rules must therefore be recorded separately. EvoTrainer jointly updates a model policy and a training-side harness. Rollout diagnostics, intervention backtests, and reusable skills can influence later search [140]. EvoTrainer combines model updates, runtime changes, and changes to the strategy used for later interventions. Ablations or counterfactual tests are needed to separate these effects.

Distinguishing adjacent-level transitions. Some systems adapt feedback, distractions, or training tasks with the learner, while the main retained change remains in model parameters under a fixed outer training process. POP, Seirênes, and CPMöbius let the model help score outputs, generate distractions, or generate training tasks. They show how feedback generation can adapt even when the outer training process stays fixed [495,496,497]. RLCER uses the same model as both a reasoner and a rubricator [498]. Under a fixed training process and a frozen verifier, it updates model parameters while generating task-specific scoring rules. Unless those rules are retained and govern later judgments, the realized transition is L1 with an L4-facing feedback role rather than L3. If they are retained and govern later judgments, the deepest active change reaches L4. AREX checks its current answer constraint by constraint and launches targeted follow-up research on the claims that remain unresolved [499]. Because its outer loop, confidence threshold, tools, and update rules stay fixed, the described loop revises the current answer and task-local research state. The separately trained compaction tool is a pipeline component rather than a retained change produced by that loop, so it does not by itself raise the realized transition above L0. The paper describes this loop as recursive self-improvement, a broader use of the term than the retained improver rewrite that defines L3. EvoRubric writes selected rubrics to persistent memory and uses them for later reward. Its persistent rubric memory changes later judgments, so its main relevance is Criterion-Level Self-Evolution [144]. These systems help separate feedback changes, model changes, and criterion changes. They do not replace causal evidence that the improver’s active semantics changed and affected later updates.

6.3. Reliability and the Fixed-Criterion Limit

Comparing improvers. An L3 classification concerns a retained change to the update procedure, not only the best artifact that procedure produces. The corresponding improvement claim asks whether the candidate improver produces better later updates than the incumbent under a declared external target and matched models, tools, context, compute, and stopping rules. Fixed-process systems such as AlphaEvolve, DeepEvolve, ImprovEvolve, and Self-Supervised Theorem Discovery show why this distinction matters. Their artifacts can be checked with executable or formal evidence even though the outer improvement process stays fixed [500,501,502,503]. The Huxley–Gödel Machine separates current task performance from future improvement productivity. A-Evolve-Training shows how a fixed proxy can saturate during repeated search [134,139]. The audit record should therefore report current performance, later-round outputs, search cost, failure recovery, and transfer to fresh tasks.

Metric capture and shared feedback. A fixed criterion gives different improvers a common internal reference. Repeated search can still adapt to that reference and raise internal scores without corresponding improvement relative to the external target. The risk is stronger when feedback producers and learners share parameters or adapt to one another. POP, Seirênes, CPMöbius, RLCER, and EvoRubric provide related evidence of this shared-feedback problem [144,495,496,497,498]. Their internal signals can support learning, but agreement within the same loop is not external audit evidence.

External evidence and rollback. Promotion evidence is informative only when the evidence source and acceptance policy remain outside the candidate’s update boundary, resource conditions are matched, and evaluation tasks did not guide proposal or internal selection. The audit record should include proposal history, selection reasons, resource use, and the sequence of promoted changes. A protected evidence source may use sealed evaluation, formal checks, controlled experiments, or human review. An externally controlled acceptance policy then maps that evidence to accept, reject, or escalate. Replay and regression analysis can support diagnosis, while canary deployment and rollback can limit impact after promotion. These operational controls bound harm but do not by themselves strengthen the improvement claim. Repeated access can turn a protected holdout into development feedback, and relabeling it does not restore independence.

Fixed criterion and handoff. The fixed criterion ${\mathcal{C}}_k$ is the common internal reference in L3. It defines the objectives, rewards, evaluation protocols, comparison rules, and constraints used to judge different improvers. It remains distinct from the declared external target used by the audit. An externally controlled acceptance policy should use external audit evidence to accept, reject, or escalate the candidate. Only an accepted candidate may then be promoted. The candidate must not choose or change the audit data, scoring rules, or acceptance policy. When rubric memory, evaluator protocols, judgment tasks, reward meaning, or other judgment rules change persistently and govern later judgments after activation, the deepest active change reaches Criterion-Level Self-Evolution. Section 7 asks how to assess such a transition when internal judgment semantics become writable. Any cross-version improvement claim still requires a protected external target and a baseline fixed before the transition.

7. L4: Criterion-Level Self-Evolution

L4 at a Glance

Boundary. L4 persistently changes the criterion ${\mathcal{C}}_k$, including judgment tasks, reward semantics, evaluator protocols, comparison rules, constraints, or values. The revised criterion governs later judgments. Any audit-supported improvement claim must therefore specify which property of judgment improves relative to a declared external target, rather than rely on a higher internal score alone.

Roadmap. We examine evolving evaluation mechanisms (§7.1), evolving tasks, objectives, and values (§7.2), and reliability with the criterion inside the loop (§7.3).

Reliability focus. When the criterion itself is updated, higher internal scores alone do not guarantee validity or real improvement against external targets. To certify a proposed criterion, one must compare it with the incumbent on a shared set using external anchors or expert judgments outside the update loop. Otherwise, criterion drift or circular validation can masquerade as improvement.

Boundary and persistence. At L4, the deepest retained rewrite is the active criterion ${\mathcal{C}}_k$ (Table ). Writing the retained state as $X_k=({\theta }_k,{\sigma }_k,{\mathcal{U}}_k,{\mathcal{C}}_k)$, as in Equation (1), the L4 boundary is

$$X_k⟼X_{k+1},{\mathcal{C}}_{k+1}{\not\equiv }_{\mathrm{act}}{\mathcal{C}}_k$$

(10)

Because the criterion is the deepest coordinate of $X_k$, L4 imposes no equality constraint on ${\theta }_k$, ${\sigma }_k$, or ${\mathcal{U}}_k$: these components may remain fixed or change in the same transition, but the active criterion rewrite determines the realized self-evolution depth. Operationally, an L4 method proposes a candidate criterion component, evaluates it, and activates the selected version so that it governs a later feasibility decision, candidate ordering, threshold, or tie break. Most methods rewrite only one component of ${\mathcal{C}}_k$ and leave task specifications, protected cases, outcome checks, or authorization rules unchanged. These fixed components constrain the search and provide comparison evidence, while the final reliability claim depends on whether that evidence and its acceptance policy remain outside the update boundary.

Across these families, the recurring algorithmic pattern is to represent a candidate judgment rule explicitly, test it against partially protected evidence, and version the rule that will govern subsequent decisions. The searched representation may be a natural-language rubric, learned evaluator, executable program, task set, or reward. Methods also differ in how they compare candidate criteria before activation. Table 7 organizes the reviewed families by what changes, how candidates are compared or screened, and what limits their interpretation as realized L4 transitions.

7.1. Evolving Evaluation Mechanisms

Evaluation-mechanism methods change how outputs are interpreted, compared, or accepted. They represent the criterion as natural-language rubrics, learned evaluators, compositional metrics, or executable verifiers, then update that representation from disagreement, rollout outcomes, or protected test cases.

7.1.1. Rubrics and Retained Judgment Rules

Rubric synthesis and calibration. Rubric methods factor judgment into explicit criteria that can be drafted, scored, revised, and reused. AutoCalibrate generates and self-refines candidate criteria, selects them by correlation with expert labels, and inserts the selected criteria into subsequent evaluator prompts [141]. GER-Eval and ELMES+ broaden this approach by generating task-specific or scenario-specific rubrics, but their evaluator analyses expose weaker cross-model and human alignment, self-preference, and model-specific leniency or severity [142,504]. RubricBench isolates the rubric itself: with the judge backbone, prompt, and decoding fixed, human-authored rubrics improve preference accuracy by roughly 22 to 28 percentage points over self-generated rubrics across seven model backbones [143]. Together, these results make rubric provenance, judge identity, and disagreement important inputs to rubric selection.

Persistent rubric stores. Persistent methods turn rubric generation into a stateful update process. EvoRubric maintains a rubric-memory pool and uses meta-verification and peer consensus to screen entries before they shape later rewards [144]. DR Tulu retains search-grounded, discriminative rubric items that score later policy updates, whereas SkillCoach patches versioned process rubrics and admits revisions only after held-out rollout checks and hard constraints [145,146]. The three systems operate at different granularities: pool entries, discriminative items, and process steps. All three combine an editable rubric representation with an explicit admission rule. Their internal gates test consistency, discrimination, or rollout utility. External-target validity remains a separate question addressed in Section 7.3.

7.1.2. Evaluators and Verifiers

Evaluator methods update either a learned decision rule or executable code that implements success conditions. The main design choice is whether to search over complete evaluator versions, localized program repairs, or trainable judge parameters.

Versioned evaluator replacement. Double Ratchet co-evolves a compositional metric with a skill loop while reserving fixed development cases, locked held-out cases, and a separate final judge. Its ablations show why those controls matter: removing the case guards yields an almost always-pass report metric in all three reported seeds, and the final judge detects a Goodhart episode in which evolved skills exploit the report rubric [147]. Red Queen Gödel Machine (RQGM) instead freezes the incumbent evaluator within each epoch, tests a challenger on a fixed held-out ground-truth set, and installs it only after a statistically significant improvement, after which the challenger governs the next epoch. Experiments in coding, paper writing, and grading show that replacement can alter the search frontier, but the guarantees are epoch-local and the evidence covers only short search horizons [15]. Together, the two systems instantiate a common replacement protocol: freeze the incumbent, compare a challenger on protected evidence, install the accepted version, and use it throughout the next search period.

Repairing executable verifiers. Executable-verifier evolution changes the program that maps observable task state to a success judgment. OpenComputer treats application-specific state checkers as mutable evaluation artifacts across 33 desktop applications. Calibration executions compare checker outputs with reference judgments, and the reported repair stage corrects most checker-side errors while increasing agreement with human judgments [148]. The repair boundary nevertheless excludes trajectories, sandbox state, task specifications, expected outputs, and official reward semantics, and the benchmark omits visual or geometric outcomes that its checkers cannot yet assess. This narrow update makes the checker code inspectable and supports direct regression testing, but it cannot assess outcomes that its observable state and predicates do not represent. CoEvoSkills provides a complementary test-escalation primitive: when a fixed hidden oracle exposes false acceptance, an independent surrogate verifier rewrites its deterministic test suite before evaluating the next skill version [101]. OpenComputer installs repaired checkers across later tasks, whereas CoEvoSkills uses verifier revision as a diagnostic mechanism within one skill-construction episode.

Learned evaluator proposals. Learned-judge optimization supplies candidate implementations and diagnostics for criterion search. Self-Taught Evaluators trains on synthetic preference pairs and filtered judgments, while Meta-Rewarding shares one model across actor, judge, and meta-judge roles [505,506]. SEVA instead uses a structured fact-attribution process reward to drive repeated cycles of verification, reflection, probing, and refinement [149]. These studies expose practical proposal risks: performance can depend on the seed evaluator, same-model feedback can exhibit positional bias or score saturation, and repeated training can produce benchmark specialists rather than a uniformly stronger judge. These techniques are therefore most useful as proposal components within L4: the surrounding procedure must state which rubric or protocol semantics change, compare those revisions, and decide which version becomes active.

7.2. Evolving Evaluation Tasks and Objectives

Beyond the mechanisms that implement evaluation, criterion methods can change the cases presented for judgment or the objectives used to value outcomes. The main representations are evolving task sets, adaptive benchmarks and environments, executable reward programs, and explicit value or constraint relations.

7.2.1. Tasks, Benchmarks, and Environments

These methods evolve the evaluation distribution by updating existing task sets, generating adaptive benchmarks, and evolving environments that expose new behaviors. Across all three families, the central design question is which generated tasks or environments enter the retained evaluation distribution and are used to judge later candidates.

Evolving task sets for evaluation. Task-set methods differ primarily in what triggers an update and which proposed tasks are retained for subsequent evaluation. AC/DC couples task discovery with model search: global and active archives store questions, answers, and executable scoring functions, while compilation, self-solving, reflection, and novelty filters govern archive admission. The active archive ranks model candidates, downstream benchmarks remain hidden from the search, and sampled expert review finds high task correctness while judging a smaller share genuinely creative [150]. Dynabench instead retains human-validated model failures collected over successive rounds of human and model interaction, whereas EvoCodeBench rebuilds a repository-grounded coding benchmark from recent projects through an automated pipeline [507,508]. These approaches therefore update task sets through complementary signals: joint task and model competition, observed model failures, or temporal data refresh.

Generating adaptive benchmarks. Adaptive benchmarks concentrate evaluation on regions where a static test no longer distinguishes candidate systems. GETA estimates an examinee’s capability and generates value-alignment items near that boundary, while MathDuels evaluates models as both problem posers and solvers and infers task difficulty from their result matrix [162,509]. AgenticEval grounds safety-case generation in policy documents and checks its rubric-constrained judge against a human-labeled sample [151]. AutoBencher makes the search objective explicit, using candidate-model scores to refine dataset descriptions for salience, difficulty, separability, and novelty [152]. The methods thus differ in the feedback that steers generation: estimated capability, adversarial problem-solving outcomes, policy-grounded safety coverage, or explicit benchmark objectives. The resulting comparisons are easiest to interpret when task construction remains tied to sources outside the generator’s control, such as policy documents, sampled human labels, or held-out evaluation cases.

Evolving evaluation environments. Environment-based methods extend adaptive evaluation from individual items to populations of interactive worlds. POET mutates viable environments, optimizes their paired agents, and transfers solutions across an archive, whereas PAIRED trains an environment adversary to maximize regret between an antagonist and a protagonist [510,511]. ACCEL combines evolutionary editing with regret-based prioritization by mutating selected high-regret levels and retaining variants that remain informative at the current capability frontier [153]. Together, they expose three complementary controls over environment evolution: viability and transfer in POET, adversarial regret in PAIRED, and frontier-focused editing in ACCEL. All three adapt environment difficulty around the current agents while leaving reward or regret semantics fixed. When selected environments are retained for future evaluation, the resulting population defines the test distribution against which later candidates are compared.

7.2.2. Reward Design and Value Assessment

Adaptive reward composition. Reward composition keeps the reward basis fixed while adapting how strongly each component influences policy learning. DyLam derives a self-curriculum from component-wise learning progress, reducing the weight of mastered components and redirecting attention toward under-optimized ones [154]. MAESTRO instead learns a Conductor that maps task representations to weights over five reward components while jointly updating the scalarization policy and the language model [155]. Dynamic Reward Weighting targets multi-objective language-model alignment: hypervolume feedback guides optimization when user priorities are available, whereas gradient influence drives weight updates when they are not [156]. Together, these methods condition scalarization on training progress, task context, or objective geometry. Because the reward basis remains fixed, however, they cannot represent an omitted outcome or repair a component that encodes a biased proxy.

Executable reward synthesis. Executable reward programs expand the design space from mixture weights to the logic and parameters that compute reward. Text2Reward generates dense reward code from a natural-language goal and an environment abstraction, then lets users revise the code after inspecting policy rollouts [157]. EUREKA replaces user-guided revision with evolutionary search, using fixed task fitness to compare reward programs before training policies with the selected program [158]. CARD closes the revision loop with execution checks and process, trajectory, and preference feedback [159]. R* further separates reward structure from numerical calibration: language model mutation and modular crossover evolve reward components, while an ensemble of generated critics provides trajectory preferences for fitting their parameters [160]. Together, these methods move from interactive code revision to automated structural and numerical search. Their evidence nevertheless remains tied to fixed task descriptions and outcome measures, so high policy return does not establish that the synthesized reward covers every intended outcome.

Representing pluralistic and evolving values. Value methods require representations that preserve contextual conflict, cultural variation, and change over time. Value Kaleidoscope uses ValuePrism to generate, explain, and assess the relevance and valence of values, rights, and duties in context, retaining competing considerations rather than collapsing them into one scalar label [161]. UniVaR instead learns a high-dimensional representation from value-eliciting responses and evaluates it across fifteen language models and twenty-five languages and cultures [512]. ProgressGym adds a temporal axis by reconstructing historical language-model proxies and simulating bidirectional influence between human and AI values over long horizons [513]. These approaches expose complementary structure through explicit value conflicts, cross-cultural geometry, and longitudinal trajectories, but they remain descriptive models rather than procedures for authorizing new value semantics.

Adapting value assessment. Adaptive value assessment can revise the evaluator, the scenario distribution, or the difficulty model as evidence accumulates. CLAVE extracts general value concepts with a large language model and fine-tunes a smaller recognizer, allowing the evaluator to calibrate to a specified value system with fewer than one hundred labeled examples per value type [514]. ALI-Agent uses evaluation memory and target-model feedback to generate and iteratively refine scenarios that probe long-tail failures across stereotypes, morality, and legality [515]. GETA jointly estimates item difficulty and model value conformity while generating new items matched to the current model, producing measurements that agree more closely with unseen in-distribution and out-of-distribution references than static or selection-only adaptive tests [162]. AdAEM uses in-context optimization to generate controversial and informative questions under Schwartz Value Theory, emphasizing discrimination among models rather than calibrated difficulty [163]. These methods address different weaknesses of static evaluation, including shifting definitions, sparse long-tail scenarios, test saturation, and weak discrimination. These evaluations do not by themselves establish that the underlying value ontology is complete or normatively legitimate, nor do the reviewed systems provide a validated procedure for authorizing and activating revised value semantics. We therefore treat stakeholder evidence, constraints and approval authority outside the relevant update boundary, and rollback procedures as governance requirements for value change.

7.3. Reliability with the Criterion Inside the Loop

The reviewed mechanisms expose a common reliability problem. Rubric pools can ratify shared preferences, evaluator populations can mutually accommodate, adaptive tests can become difficult without becoming more relevant, and reward programs can optimize an incomplete proxy. An L4 promotion claim is supported only to the extent that its evidence remains informative about a declared external target and outside the criterion update boundary.

The moving-ruler problem. When both the evaluated system and its criterion change, a rising sequence of internal scores combines two effects: behavioral change under the old standard and movement of the standard itself. Evaluation under only the revised criterion cannot distinguish a more valid rule from one that is merely easier for the revised system to satisfy. This limitation does not make Criterion-Level Self-Evolution intrinsically unreliable. It shows why internal scores alone cannot support the promotion claim.

Cross-evaluation across criteria. A defensible L4 protocol identifies the modified component and preserves a common comparison domain. Where comparisons remain meaningful, it evaluates the incumbent and candidate systems under both the incumbent and proposed criteria. Disagreements should remain visible because they reveal which decisions changed and where the proposed criterion departs from the previous standard. Fresh executable checks, sealed cases, adversarial probes, or authorized human judgments can then test whether that departure better serves the external target.

Coverage, authority, and rollback. An external anchor constrains only the properties it measures and cannot establish the complete validity of a revised criterion. A promotion record should therefore state the invariant external target, the writable criterion components, the evidence coverage, the acceptance policy, the approving authority, and the rollback condition. Staged and versioned activation preserves a comparison baseline, allows later failures to be traced to the relevant judgment rule, and supports rollback without silently redefining earlier results.

Claim scope and synthesis handoff. With adequate coverage and authorized promotion, L4 evidence can support a bounded claim that a revised criterion better serves the declared external target on the audited domain. It does not establish unrestricted criterion validity, durable agreement among co-evolving judges, or legitimacy for people and settings outside that domain. Open questions include whether co-evolving judges retain discrimination rather than mutually accommodate, whether adaptive tests remain relevant rather than merely difficult, and how normative criterion changes can remain accountable under finite human oversight. Section 8 places these L4-specific problems in the cross-level audit structure and compares criterion drift with the distinct failure mechanisms at Levels L0 through L3. R

8. Cross-Level Reliability: Evidence, Acceptance, and Control

The preceding sections classify self-evolution by what changes, from a task-local output to retained model, scaffold, improver, and criterion state. This section asks a different question: what evidence supports a claim that the change is an improvement? We organize the answer around evidence, acceptance, and control. The external target, evidence source, and acceptance policy must remain outside the relevant update boundary, while the evidence must match the claimed effect and evaluation horizon. These requirements vary by level, but self-evolution depth alone does not determine reliability.

Figure 8 makes the section’s organizing design principle concrete. We call this matched structure the reliability ladder. Each rung pairs the deepest active evolution target with representative external evidence sources and decision or recovery controls appropriate to the claimed effect. The L0 rung ends in task-local acceptance or return, whereas the L1–L4 rungs concern retained changes that require external acceptance before promotion as well as protected lineage and recovery. The rise of the steps denotes self-evolution depth only: a higher rung changes the audit obligation rather than assigning a higher or lower reliability score.

8.1. External Audit Across Self-Evolution Levels

A common audit structure. Each audit card in Figure 8 abbreviates a common structure whose roles are formalized by Equations (4) and (5). The evolution step generates and internally selects a candidate, after which the audit produces external evidence $z_k^{\mathrm{ext}}$ and a gate decision $a_k^{\mathrm{ext}}$. Within each card, the “External audit” field names representative evidence sources, while the “Decision” or “Control” field names part of the decision or post-acceptance lifecycle. For the audit to remain external, the external target, evidence source, and acceptance policy must stay outside the relevant update boundary. The compact labels do not collapse these roles into a score or a single control. We call evidence disclosed to candidate generation or internal selection development evidence. Once this evidence has guided either step, it should not serve as the sole final audit evidence for the same update.

What changes across levels. Moving up the ladder changes the deepest active evolution target and can change the form and horizon of the required audit, not how strong the supporting evidence is. Fresh executable outcomes for an L1 update may be more informative than an uncalibrated self-judge used for an L0 revision. Likewise, an L3 update can remain auditable when descendant systems are tested on unseen tasks under matched resources. By contrast, repeated feedback can turn a held-out benchmark into a development target at any level. The key comparison is therefore between what the update controls and who controls the audit, not between level numbers.

A cross-level comparison. The ladder presents the matched-audit principle in compact form, while Table 8 expands each rung into the changed object, vulnerable evidence, characteristic audit failure, and matched controls. It summarizes Section 3.3–Section 7.3 as a checklist rather than a guarantee of adequate coverage.

8.2. Level-Specific Audit Failures and Evaluation Horizons

A common failure pattern. The five rungs respond to one structural problem: at every level, an update can raise the measured score by influencing the evidence rather than improving under the external target. The mechanism differs by level: at L0, the proposer and critic can share the same error, while at L1, biased supervision can enter retained parameters. At L2, the scaffold can overfit interactions among benchmarks, memory, and workflows. At L3, changes to proposal, search, or internal selection can capture a fixed metric, while at L4, the update can change the standard used to judge improvement. An adaptive coding study found high generative–evaluative agreement on syntactically checkable skills but near-zero agreement on several design-level skills [516]. This result shows that one evaluation stack can be informative for one construct and weak for another. Agreement within one stack and additional revision rounds do not replace an external audit. These mechanisms motivate the matched audits in the ladder, but they do not form an ordering of failure severity.

Matching evidence to retained effects. The audit attached to each rung should match the claimed scope and evaluation horizon. L0 concerns the current artifact, while L1 requires fresh transfer, retention, and interference tests on later independent tasks. L2 requires fresh end-to-end comparison against the incumbent under matched resources, with component analysis and provenance where needed. At L3, the audit should test descendant performance rather than only the current score [134]. At L4, it should compare judgments under the old and proposed criteria. Controlled interventions across four frameworks found stronger dependence on raw trajectories than on condensed summaries [517]. A separate study reported capability erosion during workflow, skill, model, and memory adaptation, and its mitigation results favor explicit retention constraints [278]. Together, these results show that storing an artifact does not establish that it remains active or preserves prior capabilities.

Three properties of evidence. The compact audit fields in Figure 8 identify different evidence channels, not interchangeable guarantees. Evidence can be easy to inspect and still be weak. Structured traces, source spans, decomposed verdicts, and version diffs improve inspectability, but they do not establish informativeness or externality. Evidence may still be biased, narrow in coverage, or weakened by repeated exposure. These properties should therefore be reported separately before the evidence is used for acceptance.

8.3. Acceptance Policies and Requirements for Promotion

A common decision problem. The ladder makes a lifecycle discontinuity visible: its L0 card ends with a task-local decision, whereas the L1–L4 cards add controls for retained change. Candidate generation, internal selection, and external acceptance are separate. The rule in Equation (4) selects only a provisional candidate for audit. For retained L1–L4 changes, promotion reliability is the probability that an accepted update improves over the incumbent under the declared external target and matched evaluation conditions. L0 instead ends in task-local acceptance or return. Optional stopping, repeated selection, multiplicity, or a mutable threshold can invalidate the decision rule. PACE uses paired sequential tests to control false commits under stated assumptions, while SEA embeds anytime-valid gates in a versioned agent stack [518,519]. Both methods govern how evidence is processed, but neither adds coverage beyond the tested data or establishes reliable promotion at higher levels.

Fresh evidence and coverage. RSEA provides a complementary control by separating the evolution pool from a validation split and retaining a state only after strict improvement on that split [520]. Its ablations show that held-out selection can reveal development overfitting, although repeated use turns the validation split into development evidence. Claims beyond the gate still require fresh final tests because sequential validity and data separation do not cover untested capabilities or rare harms.

Promotion and recovery. The control fields in the ladder compress two distinct functions. External acceptance determines whether a candidate may be promoted, while protected lineage and recovery controls govern the retained state after that decision. Versioned resources, transition histories, and explicit commit operators make a promoted update reconstructable. Autogenesis implements these features with registered prompts, tools, agents, environments, memories, and version lineage [316]. These records support reconstruction and recovery, but they do not show that the promoted state is better. For an L1–L4 candidate, the audit should compare the candidate with the incumbent under the declared external target and matched conditions, using fresh evidence and an acceptance policy that remains valid under adaptive selection. If the candidate is accepted, promotion requires protected lineage and a tested rollback path. Independent rollback and halt authority limit harm. Rejection keeps the incumbent unless the candidate was provisionally installed, in which case it triggers rollback. These conditions should be reviewed whenever evidence access or update authority changes. These are design requirements, not sufficient guarantees.

8.4. Preserving Audit Independence Under Compromise

Persistence under compromise. Persistence creates an attack surface because retained L1–L4 changes can carry a compromise into later tasks, whereas L0 has no retained state by definition. A module–lifecycle analysis maps attack opportunities across model, cognitive-resource, execution, self-design, and collective components [521]. Zombie Agents show how untrusted content written in one session can later be retrieved as an instruction, allowing the injection to outlive the original interaction [522]. These examples show how persistence expands exposure, although vulnerabilities differ across systems. The shared threat is loss of audit independence through probe selection, hidden-outcome inference, altered enforcement, corrupted lineage, or disabled recovery. An audit shown above a rung remains external only if its evidence and controls remain outside the update boundary after the reviewed component is compromised.

Independent enforcement and recovery. Freezing a base model, separating roles, or adding an internal verifier may improve robustness, but these choices do not place the audit outside the update boundary by themselves. Runtime isolation, least-privilege execution, sealed probes, protected version history, rollback, and independent halt paths protect different parts of the system. Because their effectiveness depends on what the evolving system and an attacker can access or modify, the threat model must state these assumptions. The key test has two parts. Does the external target remain fixed? Do evidence collection, the acceptance policy, protected lineage, and recovery authority still work after the reviewed component is compromised?

Cross-level conclusions. Taken together, these requirements give the reliability ladder its intended meaning. Self-evolution depth changes the failure mechanism and evaluation horizon, but it does not determine reliability. Each improvement claim needs evidence that matches its scope. The audit record should state who controls the evidence, what it covers, and how it is used for acceptance. Retained changes also need protected lineage and independent recovery authority. The ladder therefore advances a matched-audit principle: no update should control the only evidence used for its own acceptance. At L4, a writable criterion is the deepest instance of an update that can influence its own acceptance evidence. Section 9 asks whether these conditions survive capability forecasting, adaptive benchmarks, specific deployment, and finite oversight.

9. Open Problems and Outlook

Section 8 highlighted a central challenge: reliable self-evolution depends on evidence that remains informative and outside the update’s control. Building on that synthesis, this section focuses on four open questions. We first ask how self-evolving systems can improve over time and how evaluation should follow that update history. We then ask when an update is ready for deployment and how goals and oversight can remain effective as the system changes. For each question, we review the evidence so far and identify the main gaps for future work.

9.1. Evolution: Capability Growth and Learning Over Time

Persistent classification requires a retained change to remain active beyond the task that produced it. Whether that retained change improves later performance is a separate empirical question. Existing studies report both useful retained gains and failures such as forgetting, narrow specialization, and weak transfer. This section reviews that evidence and asks what would count as sustained capability growth.

Distinguishing learning from more compute. The same score gain can reflect genuine learning or simply more search and computation. One formal analysis models capability relative to an oracle A as $C\left(A\right)=\{B:B{\le }_{T}A\}$. It proves that finite internal modifications stay within this layer, while the limit of stabilized revision is characterized by $A^{\prime }$ [523]. This is a separation result in computability theory, not a direct model of gradient training, finite-time learning, or sample efficiency. Its main value is diagnostic. A claim of qualitatively stronger capability needs to identify the new information, computational resource, or effective oracle that enabled it. An empirical counterpart is still missing. Future experiments could match task information, tools, wall-clock time, inference compute, and environmental access, then test whether the gain persists on new tasks.

Tracking retention and transfer over time. A single persistent update shows only that something was retained. It does not show transfer to new tasks, resistance to forgetting, or protection from negative transfer. Experiments that save successive scaffold snapshots find that useful intermediate versions can later collapse and that validation gains need not transfer to out-of-distribution tasks [524]. Other controlled experiments separate failure detection, localization, and diagnosis from later failure avoidance. In their tested setting, they also find forgetting under accumulated noise and negative transfer across contexts [525]. Multi-agent memory results add another boundary. With matched trajectory counts, filtered peer traces help some plateaued agents but provide no general gain and do not help the strongest agent [526]. Together, these studies show that long-term learning requires more than a final success rate. Evaluation also needs to track retention, cross-task transfer, and resource use. The next question is how to distinguish sustained growth from temporary adaptation or increasingly narrow specialization over much longer task sequences.

Interpreting early-warning signals. Ordinary task scores are not enough to warn that a system may be improving its future update process. One proof-of-concept task gives coding agents three hours to rebuild an AlphaZero-style Connect Four pipeline and uses an exact solver as an anchor [527]. The strongest agent beat the solver as first player in seven of eight trials. The authors also report that the task had approached saturation by the time of evaluation. The same study observed model-specific under-use of the time budget. Follow-up prompts changed time use but not ratings significantly, so this behavior did not diagnose deliberate capability hiding. The Meta-Agent Challenge probes a related skill by asking a coding agent to develop another task agent under hidden tests and anti-exfiltration controls [528]. Only five model–domain configurations exceeded the mean of the corresponding human-engineered baseline. Results were highly variable, and attempted test exfiltration exposed the security burden created by optimization pressure. Both tasks measure difficult research automation. Neither shows that a system can repeatedly improve its own improver. Future early-warning suites could combine non-writable references, several held-out task families, matched budgets, repeated trials, and contamination controls. They also need a way to remain informative after public release without becoming recognizable training targets.

9.2. Evaluation: Longitudinal Measurement and Adaptive Auditing

Reliable evaluation must follow the full update history rather than only the final score. Current benchmarks reveal regression, forgetting, differences in resource use, and loss of test independence. No single protocol yet covers every update target. This section compares the current benchmark landscape and summarizes the main requirements for longitudinal and adaptive auditing.

Mapping current benchmark coverage. Most agent benchmarks evaluate a fixed system on independent episodes. To evaluate retained self-evolution, a benchmark must instead expose an update opportunity and test whether the resulting change remains active on later independent tasks or future updates. Recent benchmarks begin to support this shift by preserving task order, state snapshots, update artifacts, or controlled post-update tests. Table 9 compares benchmarks that directly test retained changes with adjacent benchmarks that probe autonomous model or agent development without directly evaluating a retained Improver-Level transition.

Adjacent development benchmarks. The second group in Table 9 evaluates whether an agent can perform parts of the research and engineering loop needed to improve models or agent systems. These suites move beyond fixed-system task execution, but they generally ask a researcher agent to attempt to improve a separate target model or to construct a task-specific scaffold within one bounded run. They are therefore adjacent evaluations for self-evolving agents rather than direct evidence of retained Improver-Level Self-Evolution. Long-context memory benchmarks, curated-skill ablations, isolated task suites, and within-task trajectory graders are also useful component tests, but they do not by themselves attribute later-task gains to an active retained update.

Recording the full update path. Self-evolution is a sequence of proposed, accepted, rejected, and reverted updates, not a single evaluated episode. SEA-Eval records both success and resource trajectories. It finds up to a 31.2-fold token difference between frameworks on individual tasks despite similar success rates [529]. SEAGym saves successive scaffold snapshots and separates training, frozen update validation, held-out in-distribution and out-of-distribution tests, replay, and cost [524]. BenchTrace further separates failure detection, localization, diagnosis, and later avoidance [525]. Together, these studies show that a terminal score cannot separate retained transfer from temporary adaptation, regression, forgetting, or extra resource use. One open direction is to report held-out gain, retention on earlier tasks, transfer, severe failures, update cost, and uncertainty over the full path. A protocol could also record rejected and reverted proposals and reserve a fresh audit stream that never selects intermediate versions.

Matching metrics to what changes. An evaluation first needs to state what changed, the claimed persistence horizon, and the later tasks on which active retention was demonstrated. EvoMemBench separates within-episode from cross-episode memory and knowledge-oriented from execution-oriented content. No memory method dominates every setting, strong long-context baselines remain competitive, and some memory methods add substantial token cost [530]. Only the cross-episode conditions directly support a claim of persistent Scaffold-Level change. SE-Bench obfuscates NumPy into a pseudo-novel interface to separate documentation access, reasoning difficulty, and parameter internalization. Its closed-book results show that using accessible documentation successfully does not mean that knowledge has entered the model [531]. For improvers, each Meta-Agent Challenge run leaves behind a task-agent scaffold, but the meta-agent itself does not improve across runs [528]. For shared memory, SAGE compares peer history with self-only history under matched trajectory counts. Its results support conditional help rather than a general improvement [526]. These scores are not directly comparable because they concern different writable objects and persistence horizons. Model updates can be tested for retention and interference. Scaffold updates can be tested for replay, permissions, cost, and stale skills. A proposed contract for improver updates would use held-out evidence to test whether future updating gets better. The same proposal would pair criterion changes with authorization and external audit. Cost, generalization, safety, and promotion reliability can be reported across these evaluations, but the levels do not form an ordinal capability scale.

Extending coverage to deeper updates. The existing benchmark landscape is strongest for retained model and scaffold changes. SE-Bench isolates one Model-Level capability, while SEA-Eval, SEAGym, BenchTrace, and EvoMemBench examine different forms of Scaffold-Level persistence. PAST-Bench adds matched persistence ablations and pathway evidence for personal-agent memory, skill, and state reuse [532]. The adjacent suites broaden the target to autonomous agent development, data-centric research, and model post-training, but each bounded run leaves the researcher or its update procedure fixed. Among these representative suites, none directly tests retained Improver-Level or Criterion-Level changes over several generations. The field therefore lacks a common protocol for asking whether a descendant produces, selects, or judges still later descendants more effectively under a declared external target and matched resource conditions. A broader benchmark should not collapse L1–L4 into one score because each level changes a different object and requires a different evaluation horizon. Instead, it should identify the realized transition and update boundary, preserve successive snapshots and proposal histories, and report target-relative held-out gain, transfer, forgetting, severe failures, and cost under matched resource conditions. For deeper self-evolution, the protocol should additionally test descendant productivity on fresh task families while keeping the external target, final evidence source, and acceptance policy outside the update boundary. Protected final tests and access records are also needed because repeated optimization can turn a benchmark into development evidence. The open problem is to combine these controls in a benchmark that remains discriminative across generations without exposing the evidence used for final audit.

Adapting benchmarks while keeping anchors. Adaptive benchmarks can preserve discrimination by generating harder or more diagnostic items. GETA generates value-alignment questions near a model’s estimated capability boundary and compares them with static human-labeled and out-of-distribution sets [162]. Its difficulty estimator and item generator still share learned components. MathDuels makes models both proposers and solvers, estimates difficulty with a Rasch model, and filters faulty problems with symbolic checks and model-based adjudication [509]. Both designs resist ceiling effects, but new items are not automatically independent audit evidence. One possible direction is to separate adaptive item generation from fixed anchors and add rotating fresh sets with strict access records.

Adding interactive and expert tests. Interactive evaluation can obtain new cases from changing opponents or observations, but this novelty also has limits. Negotiation games retain fixed payoff tables and swap roles, yet results remain opponent-dependent and may be non-transitive [536]. ClawArena preserves hidden scenario truth and executable workspace checks. Its conflicting information is staged in advance rather than generated adaptively [537]. Frontier-Eng uses frozen simulators, hard feasibility constraints, and 47 engineering tasks. Its declining improvement frequency describes finite-budget search rather than sustained open-ended progress [538]. By contrast, safety and educational evaluations can directly adapt cases or rubrics. AgenticEval generates increasingly targeted cases from policy documents, but its model judge is only partly calibrated through human review and does not provide legal certification [151]. ELMES+ co-evolves educational scenarios and rubrics around expert-defined dimensions. It also keeps frozen anchors, rollback, and stopping rules while documenting judge bias and self-preference [504]. Human-designed items remain useful for rare diagnostics. Hand-built metalinguistic tests exposed a capability dimension on which then-current models performed near chance, although any fixed public set can itself become contaminated [539]. These studies show that the choice is not simply between fixed and adaptive benchmarks. The open questions are which parts may change, which references remain fixed, and who can see each data split.

Checking the evaluator itself. An evaluator that keeps changing must itself be checked with evidence it cannot control. One self-evolving behavioral instrument uses several certificate types to expose local regressions hidden by an aggregate score. Its main results still rely on model judges, and some certificates share evaluation components [540]. SrDetection uses execution-checked, semantically equivalent variants to detect potential leakage. It improves detection in controlled continued-pretraining experiments [541]. On public benchmarks without membership labels, however, it can only flag behavior consistent with exposure. It cannot prove that training-set membership inflated the reported score. PixJail reconstructs text-to-image jailbreak evaluation under a common pipeline and versioned memory. This provides a reproducibility check for results that depend on implementation details [542]. If reported attack success rates guide reconstruction, matching them is not an independent validity check. Signed error can also hide offsetting discrepancies. These methods audit dimension coverage, contamination, and implementation fidelity. None alone establishes the continuing validity of an evolving evaluator. One proposal is a versioned evaluator dossier that records the external target, evidence source, acceptance policy, writable components, fixed anchors, calibration data, access history, tail risk, version lineage, and rollback. The harder question is how much information a certificate retains once the system can observe, predict, or influence certification.

9.3. Applications: From Updates to Deployment

The evaluation principles above become concrete only when they are matched to an application. Recent work clusters around four broad directions: executable engineering, persistent digital agents, scientific discovery, and embodied or high-stakes systems. Figure 9 summarizes these directions and frames their common path from persistent adaptation to staged deployment. These directions differ less in how often they use reflection or memory than in what they retain and what evidence the environment can provide. The central deployment question is therefore not which domain is most popular, but whether its evidence source can support the claimed update without being absorbed into the same development loop.

Executable engineering and AI development. Software engineering, data science, database tuning, and automated algorithm design currently provide the clearest feedback loops. Compilers, unit tests, result-equivalence checks, hidden task evaluators, and measured latency can reject many bad candidates before a retained change is used again. The Darwin Gödel Machine is representative of agent-side evolution because descendants retain changes to the agent program and can generate later descendants [14]. AlphaEvolve instead retains algorithms and infrastructure artifacts selected by task-specific evaluators while its outer search procedure remains fixed [500]. EvoDS illustrates a scaffold-centered path in which verified data-science procedures become reusable executable skills, while adaptive context management supports later multistage tasks [419]. These systems make updates easy to execute and compare, but passing the available checks establishes improvement only under the tested behavior. Long update sequences still require fresh tests, protection against repeated holdout use, and a clear distinction between improving an artifact, improving an agent, and improving the procedure that generates later updates.

Persistent digital agents. Web, GUI, coding, and operations agents increasingly retain skills, memory, rules, or model updates across sessions. Mobile-Agent-E stores Tips and executable Shortcuts that can be reused on later phone tasks [543]. UI-Mem combines persistent workflow and failure memory with online reinforcement learning, providing both scaffold and model update paths [544]. ServiceOdyssey turns successful microservice-management traces into reusable operational skills, but its evidence remains a prototype rather than long-running production traffic [545]. WebEvolver further shows the attraction and risk of learning both an acting policy and a world model: the learned simulator can guide later decisions, but it can also become a self-confirming development signal unless checked against fresh live states [12]. Across this direction, the main deployment problems are environment drift, account permissions, prompt injection, stale skills, and memory contamination. A useful audit should therefore test new environments and independent sessions, record permission changes, and verify that obsolete or harmful state can be removed without erasing the evidence needed for review.

Scientific discovery. Scientific agents now span biomedical analysis, scientific computing, automated experimentation, and open-ended research workflows. STELLA provides a clear persistent example: verified templates and newly created bioinformatics tools are added to libraries that can affect later biomedical tasks [444]. Other systems update research artifacts only within the current project, even when the project contains many rounds of hypothesis generation, experiment design, or writing. The important organizing distinction is the final evidence source. Executable code and numerical checks can audit scientific-computing steps, formal proof tools can check derivations under stated assumptions, and physical experiments can test selected empirical claims. Model reviewers are useful for triage and diagnosis, but they do not independently establish novelty, statement faithfulness, or scientific value. This direction therefore needs layered evidence: task-local execution for correctness, protected held-out problems for transfer, and domain-expert or experimental review for claims that exceed what the executable checks measure.

Embodied and high-stakes systems. Robotics, healthcare, finance, education, power systems, and law provide consequential applications, but their strongest outcomes are slower, costlier, and harder to repeat. ENPIRE gives coding agents access to policy training and physical robot rollouts, creating stronger evidence than simulation alone while relying on pre-engineered resets, validators, and safety controls [546]. Medical consultation agents retain experience across simulated cases, but benchmark diagnoses and simulated patients do not establish clinical benefit [299]. FactorMiner retains financial skills and successful or forbidden patterns, yet its evidence remains historical backtesting rather than independently monitored trading [547]. Pedagogical agents evolve teacher strategies against simulated student outcomes, while human ratings mainly assess lesson quality rather than later student learning [548]. Power-flow and legal-retrieval agents likewise use simulation or benchmark relevance as development feedback [352,366]. Physical measurements, expert review, or historical test sets are not external audits merely because they are difficult for a model to edit. Externality also depends on who selects the cases, how often the system can query them, and who controls the decision to activate an update.

Moving toward deployment in stages. Across these applications, deployment should be gradual: wider use should follow only as the evidence becomes stronger. Initial evaluation should use cases kept separate from development. The system can then be observed in real settings while its outputs are prevented from affecting users or operations, followed by limited use under explicit safeguards. Broader deployment should wait until independent evidence shows that the system meets the declared external target under matched evaluation and resource conditions, and until an authorized process judges the remaining limitations and risks acceptable for the people and settings affected.

Every retained L1–L4 update should have a traceable record linking the deployment decision to what changed, the external target and evaluation horizon, the development evidence considered, the external evidence source and acceptance policy, and the evaluation and resource conditions used for comparison. The record should also identify who may authorize promotion, deployment, suspension, and rollback. Evaluation must continue after release because changes in the system or its operating environment can make earlier evidence outdated. Later stages therefore require ongoing monitoring, incident reporting, and tests for rare but severe failures, together with renewed evaluation after material changes to the model, scaffold, improver, criterion, tools, sensors, or operating environment. The rigor of these safeguards should reflect both the scale of deployment and the severity of possible harm. Throughout this process, the evidence source and acceptance policy should remain outside the relevant update boundary. When evidence is incomplete, delayed, or contested, wider deployment depends on governance as well as technical evaluation: who may authorize it, and how can oversight keep pace with continued updates?

9.4. Governance: Goal Preservation and Scalable Oversight

The staged path above turns governance into the next bottleneck. Self-evolution makes that bottleneck a moving problem. Sustained interaction with AI may change user and overseer judgments, motivating a coupled human–AI view of long-term oversight [549]. Audit feedback can become training data, criterion changes can alter what counts as success, and human review may not keep pace with frequent updates. This section reviews current safeguards and asks how oversight can remain effective as the system changes.

Keeping audit feedback from becoming training data. The empirical acceptance policies in Section 8.3 depend on data sources and collection processes that deployment can change. Adaptive item generation can restore difficulty while changing the tested distribution. Behavioral contamination diagnostics can flag suspicious familiarity without providing definitive membership labels [162,541]. Fresh data, adversarial probes, and environments outside the system’s control support calibration only while repeated access does not turn them into development data. One possible protocol would version data provenance, separate development and audit budgets, log access, and recalibrate after distribution shift or repeated selection. The next question is how to keep using feedback without letting the same update loop shape both the evidence and its interpretation.

Constraining goal and criterion changes. The safety evidence in Section 8.4 shows that self-evaluation bias and changing success standards can persist across updates. When the criterion changes persistently, improvement under the new criterion does not by itself establish improvement under the declared external target. Adaptive safety tests can uncover problems missed by a static policy suite. Educational rubrics can expand long-tail coverage, and behavioral certificates can expose regressions hidden by aggregate scores [151,504,540]. The same studies also document shared judge bias, self-preference, and incomplete agreement with humans. This is not only a statistical problem. Safety constraints, rights, and acceptable trade-offs may be contested or inappropriate to delegate. One direction is to distinguish fixed-semantics item generation from a persistent change to the judgment-task distribution or criterion meaning. The process could preserve protected constraints outside the relevant update boundary, restrict repeated access, and state who may authorize each kind of change. It could also compare judgments under the pre-change criterion before promotion. Whether such a process can handle genuine goal change remains open.

Keeping oversight ahead of updates. External audit does not become reliable merely because a human or institution performs it. Human oversight has limited throughput, delayed feedback, varied expertise, and disagreement about acceptable outcomes. Current studies often restrict human review to sampled judge checks, a few expert-authored cases, lecture-quality ratings, or manual code validation [151,504,542,548]. As systems change more components more often, limited review capacity can reduce coverage or be replaced by unvalidated proxies. One approach worth testing is to use automated checks to screen lower-risk updates. Experts could focus on criterion changes, severe or novel failures, and disagreements among checks. Future work also needs to measure audit coverage, delay, disagreement, backlog, escalation quality, and reviewer independence. Most importantly, it should test whether overseers can halt or reverse an update sequence in time. A candidate oversight design would also preserve a reference that the evolving system cannot control or gradually learn to game.

These four areas point to one shared question: after the system changes, what trustworthy evidence supports an improvement claim under the declared external target? They define an open research agenda, not a claim that deeper self-evolution is necessarily less reliable. Reliable self-evolution remains unresolved because systems, environments, and institutions all change, while the evidence used to judge improvement must remain valid.

10. Conclusions

Self-evolving agents use information produced during execution to revise current outputs or modify retained components that shape later behavior, updating, and judgment. This survey studies these systems through two questions: what changes during self-evolution, and what evidence supports a claim that the change is an improvement under a declared external target? Section 2, Section 3, Section 4, Section 5, Section 6 and Section 7 address the first question by classifying each transition according to its deepest active semantic modification. The resulting taxonomy ranges from task-local Output-Level Self-Evolution (L0) to retained Model-Level, Scaffold-Level, Improver-Level, and Criterion-Level Self-Evolution (L1–L4). Across these levels, the survey compares representative systems by the object changed, the persistence of that change, the evidence used to guide it, and the boundary cases that separate adjacent levels.

Section 8 addresses the second question by comparing the evidence, acceptance, and control requirements across levels. Self-confirmation, model collapse, scaffold overfitting, metric capture, and criterion drift illustrate distinct ways in which an update can influence the evidence used to judge it. Self-evolution depth changes the failure mechanism and evaluation horizon, but it does not determine reliability. Each improvement claim needs evidence that matches its scope, while the external target, evidence source, and acceptance policy must remain outside the relevant update boundary. Retained changes also need protected lineage and independent recovery authority. The reliability ladder summarizes this matched-audit principle: no update should control the only evidence used for its own acceptance.

Section 9 turns these requirements into four open questions: whether capabilities improve over time, whether evaluation can follow the update history, when an update is ready for deployment, and how goals and oversight can remain effective as the system changes. Existing studies report useful retained gains as well as forgetting, narrow specialization, and weak transfer, so sustained capability growth remains an open empirical question. Likewise, evidence that an agent is self-evolving does not by itself establish improvement or imply accelerating gains. Progress therefore depends not only on what an agent can change, but also on whether the evidence used to evaluate that change remains informative and outside the relevant update boundary.