Agent Self-Evolution: From Experience to Verifiable Capability Growth

Introduction

Agent self-evolution is often misunderstood. The article identifies three misconceptions: task-internal reflection and retry do not equal self-evolution; generating new Memory, Skill, or Harness does not equal capability improvement; and evaluation score increases do not equal acquiring transferable, reliable new capabilities. The author frames three core questions for practice: whether experience forms cross-task persistent updates, whether updates yield attributable net gains on unseen tasks, and whether gains satisfy regression, safety, cost, audit, and recovery constraints.

Key Insights

Self-evolution is a three-layer problem: persistent update of facts, capability judgment, and reliability judgment. Only attributable net gains on unseen tasks constitute effective evolution; passing regression, safety, cost, and recovery constraints approaches reliable evolution.

The complete evolution space is defined by updatable objects and learning signals. Updates can enter model parameters, Prompt, Memory, Tool, Workflow, and Harness. Agent-generated examples, execution traces, internal evaluations, and external feedback can drive evolution at any layer.

Self-evolution must form a closed Learning Loop: experience must undergo attribution, routing, candidate generation, independent verification, release, and continuous observation to become capability. Missing write-back leaves only analysis; missing observation makes optimization one-off; missing independent selection risks polluting the system with erroneous updates.

Modifiable space determines potential gain space; verifiable space determines reliable evolution boundaries. Gains may come from more sampling, selection bias, environment recovery, or human intervention. Only under comparable compute, sampling, time, and human investment, with independent testing, transfer, and regression control, can gains be attributed to persistent updates.

Trustworthy self-evolution is limited, verifiable, and retractable improvement under protected premises. Agents may modify Harness or even the Meta-Optimizer, but improvement targets are set by business goals, final evaluation by independent evaluators, and release/audit/recovery by independent governance mechanisms.

1. What Is Agent Self-Evolution

1.1 Agent Behavior Is Not Only From the Model

Viewing an Agent solely as a base model ignores that Prompt, Memory, Tool, Skill, Workflow, and Harness continuously change Agent behavior. Self-evolution can occur in these parts, not just model parameters. Agent behavior is jointly determined by model parameters θ_t and scaffolding S_t (Prompt, Context, Memory, Tool, Skill, Workflow, Routing, Scheduling, Harness code, safety constraints). The survey "Self-Improvements in Modern Agentic Systems: A Survey" summarizes scaffolding as π (Prompt), μ (Memory and read/write mechanisms), τ (tools and interfaces), ρ (routing, scheduling, orchestration, safety control). A single task also produces transient execution state (KV cache, intermediate plans, working memory, uncommitted files, local environment state) that improves current task performance but does not automatically change future tasks.

First principle of Agent self-evolution: Experience must be written into model parameters, Memory, Skill, Workflow, or Harness—parts that persist across tasks—otherwise it is merely one-off experience.

Reflection, retry, and replanning within a task only generate learning signals; they do not prove learning is complete. Only when experience is persistently written into θ or S and continuously influences behavior in subsequent tasks does it count as self-evolution.

1.2 Self-Evolution Event, Effective Self-Evolution, and Reliable Self-Evolution

The premise that any Agent update makes the system better is false. Wrong rules can be persistently written into memory; fragile workflows can stably reproduce; techniques targeting a fixed benchmark can raise scores. All involve cross-task updates but do not constitute capability growth. The article defines three levels:

Self-evolution event: Experience indeed caused an update, the update persists across tasks, and it has already influenced subsequent task behavior.

Effective self-evolution: A self-evolution event occurred, the improvement transfers to unseen similar tasks, and after excluding more sampling, human intervention, etc., task performance shows a net gain.

Reliable self-evolution: Net gains are not at the cost of unacceptable regression, safety risks, cost, latency, or long-term instability, and the update has versioning, audit, and recovery mechanisms.

Three basic requirements for these levels:

Persistent update: If experience does not change cross-task persistent θ or S, no self-evolution event occurred; task-internal reflection only generates learning signals.

Verification constraints: Expanding update scope only directly increases candidate space; reliable gains still require equal-budget independent evaluation, transfer on tasks not involved in search, and regression testing.

Control plane separation: If the same candidate generator can change and approve objectives, final evaluation, critical tests, audit, and highest privileges—acting as both referee and player—the system cannot stably distinguish capability growth from changed evaluation standards. Agents may propose changes, but final approval must be independent.

1.3 What Counts as Agent Self-Evolution and What Does Not

Memory enhancement and RAG themselves are not self-evolution. Saving preferences, facts, history, or adding documents to a knowledge base only changes information the Agent can call; only when these experiences further change the Agent's subsequent way of acting can they constitute self-evolution. Three cases:

Only saving and recalling information → information persistence or knowledge enhancement.

Changing memory read/write, retrieval decisions, tool calls, or result verification, and persisting in subsequent tasks → scaffolding-level self-evolution.

Training stably generalized experience into model parameters → parameter-level self-evolution.

Products with Memory, Skill, or Workflow write-back capabilities often call this "self-evolution." But writing back experience only proves persistent update occurred, not capability improvement; one must verify transfer to unseen tasks and exclude memorizing evaluation samples, increasing retrieval rounds, or relying on human intervention.

Persistence ≠ generalization, recall success ≠ policy evolution, policy change ≠ reliable evolution. Similarly, long tasks, multi-Agent collaboration, more tool calls, and complex Workflows describe execution structure first. If experience is not written into cross-task effective model or scaffolding, it is not Agent self-evolution. An Agent repeatedly improving code, algorithms, or external Artifacts does not equal the Agent itself becoming stronger; it belongs to Artifact iterative optimization. The former cares whether the Agent gained transferable, verifiable capability affecting future tasks; the latter cares whether this task's artifact improved. The same Agent can improve Artifacts without improving itself.

To judge if a system is self-evolving, ask three questions:

What is changing? Agent's model, Memory, Skill, Workflow, Harness, or external Artifact?

What drives the change? Execution experience, environment feedback, user correction, or pure complex search and more sampling?

Is the change written back and persistently effective? Does it persist in subsequent tasks not involved in this optimization?

These questions respectively judge what changes, what learning signal drives change, and whether the change is persistently written back and continuously effective on future unseen tasks.

2. Technical Means of Agent Self-Evolution

2.1 Two Update Paths

Path 1: Update model parameters — θ_{t+1} = θ_t + Δ(ε), where ε is learning signal from execution. Parameter updates via SFT, LoRA, distillation, RL, or continuous post-training change the model's default capability distribution. Suitable for compressing stable, repetitive, dense experience. Costs: training cost, credit assignment difficulty, catastrophic forgetting, goal drift, and broader regression/safety verification when scope expands.

Path 2: Update scaffolding — S_{t+1} = S_t + Δ(ε). Can change Prompt, Context, Memory, Tool, Skill, Workflow, routing, scheduling, Harness code, even Meta-Optimizer. Peripheral updates are faster, more interpretable, easier to version and roll back, and currently the most common. Main risks: rule conflicts, Context/Memory pollution, tool semantic drift, workflow brittleness, code-level reward hacking.

The two paths are not "real learning" vs. "fake learning." As long as experience drives persistent updates that change behavior across tasks, both can constitute self-evolution. They differ in update object, scope, effective mechanism, verification cost, and recoverability.

2.2 Three Types of Learning Signals

Update paths answer "where experience is finally written"; learning signals answer "what experience the system uses to improve." Three categories:

Intrinsic generated demonstrations: Agent's own generated training samples, task traces, programs, candidate solutions. Reduces external data dependency but may repeat or amplify Agent's own errors and blind spots; requires expert cleaning.

Intrinsic evaluation feedback: Agent's self-evaluation of its performance, including self-critique, preference judgment, confidence, consistency checks, Judge model feedback. Helps discover problems but if executor and evaluator share blind spots, may form erroneous self-consistency.

External exploration experience: Results from environment and real interaction: sandbox/simulator run results, test feedback, tool returns, user corrections, human evaluations. Closer to true task completion but may suffer from sim-to-real gaps, feedback latency, business factor confounding, environment noise.

Learning signals and update objects are relatively independent dimensions. The same user correction can be written into Memory, organized into Skill, used to modify Workflow or Harness, or enter model training data. The system must decide: which experience goes to which layer, with what scope, and what evidence is needed to accept the update.

2.3 Main Update Objects

Update objects include not only model parameters but also Prompt, Context, Memory, Tool, Skill, Workflow, Harness, and Meta-Optimizer. Different objects change behavior differently, suit different problems, carry different risks, and require different verification. The following table summarizes them (converted to list for readability):

Prompt / Context : Changes visible information and constraints at decision time. Suits local knowledge and strategy guidance. Risks: evaluation rule leakage, rule conflicts, attention dilution. Core verification: unseen tasks, rule conflict and switch ablation experiments.

Memory : Changes cross-task retrieval and call content. Suits facts, events, strategy experience. Risks: sample memorization, polluted recall, stale knowledge. Core verification: version switches, misuse rate, time validity.

Tool / Skill : Adds or revises executable actions and operation methods. Suits interfaces, procedural experience, tool combinations. Risks: solidifying accidental paths, dependency drift, permission expansion. Core verification: unit tests, dependency failure, permission checks.

Workflow / Orchestration : Changes task decomposition, state transitions, recovery paths. Suits orchestration, retry, wait, recovery. Risks: more calls, bypassing constraints, path speculation. Core verification: equal-condition single-pass rate, path audit, state recovery.

Harness : Changes runtime mechanisms for context, tools, state, control flow. Suits context, tools, state, control flow. Risks: rewriting evaluation, hiding failures, expanding editable scope. Core verification: isolated execution, external evaluator, lineage, permission checks.

Meta-Optimizer : Changes candidate generation, verification, selection mechanisms. Suits improvement routes and update strategies. Risks: modifying evaluation, amplifying search bias, expanding editable scope. Core verification: external evaluator, search/test isolation, lineage, permission checks.

Model : Changes model's default capability distribution. Suits stable, repetitive, widespread capability gaps. Risks: local gains accompanied by forgetting or goal drift. Core verification: held-out transfer, cross-capability regression, data deletion verification.

These objects nest: Skill encapsulates Tool, Workflow executed by Harness, Meta-Optimizer can modify Harness. Larger scope, closer to full runtime or model defaults → higher potential gain and risk, higher requirements for independent evidence, permission control, recovery. All technical routes cannot be discussed without corresponding verification methods.

2.4 Hybrid Evolution: Model and Scaffolding Joint Updates

Model parameters and scaffolding need not be mutually exclusive. Scaffolding updates are fast, observable, rollback-friendly, suitable for first verifying new knowledge and strategies; when experience consistently holds on tasks and regression tests not involved in update, consider writing high-frequency, general parts into model parameters. After new model deployment, Prompt, Tool, Workflow, Harness also need re-adaptation.

The SIA (Self Improving AI with Harness & Weight Updates) paper proposes and open-sources a framework simultaneously updating Harness and model weights. A Feedback-Agent selects between the two update modes based on full execution traces. Experiments show that after Harness-only gains plateau, continuing weight updates brings additional improvement. This confirms complementarity: scaffolding mainly changes how Agent acts; model parameters mainly change what it defaults to know and how it tends to judge. But both may jointly cater to a fixed Verifier, causing reward hacking and overfitting; gains cannot be simply added.

2.5 Recursive Evolution: When Improvement Mechanism Itself Becomes Update Object

Ordinary self-evolution modifies Agent's task-completion capability; recursive evolution further modifies "how to produce improvements"—e.g., how to collect evidence, generate candidates, arrange verification, select updates, decide stop. The Meta-Optimizer organizing these processes becomes an update object itself.

The paper "Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation" explores letting the "mechanism responsible for improving programs" continue improving itself. Starting from a Seed Improver, the model generates new improvement strategies, selected by external meta-utility to continue optimizing the improver itself and downstream programs. This proves improvement mechanisms can be modified, but tasks, base model, and evaluation standards remain externally fixed—thus not full Recursive Self-Improvement (RSI). Stronger Meta-Optimizers can online organize evidence, modify order, candidate selection, stop; weaker ones still need predefined processes.

Note: recursion does not guarantee progress; it amplifies effective signals, erroneous judgments, and evaluation loopholes simultaneously. Agents can organize improvement routes, but goals, final evaluation, highest privileges, release, and recovery must remain controlled by independent mechanisms.

3. Mechanisms of Agent Self-Evolution

Experience written into different objects changes subsequent information Agent sees, actions it can execute, and decision flows it adopts.

3.1 Prompt and Context: Changing What Agent Sees Now

Prompt and Context do not directly add new capability components; they change what Agent sees at decision time, what to prioritize, and what requirements to follow. They modify fast with short feedback cycles, suitable for supplementing local knowledge, examples, strategies from failure traces, and quickly verifying if a fix works. But constraints still rely on model's own understanding and instruction following. Rules may conflict; long Context dilutes focus; answer patterns summarized for fixed evaluation sets may only work on test data. Therefore, Prompt and Context suit rapid verification of knowledge and strategy, not irreversible actions, highest privileges, or hard safety boundaries. Constraints enforceable by code should not rely solely on model's probabilistic instruction following.

3.2 Memory: Changing What Agent Can Recall Later

Memory update is not just saving more documents; it decides which experiences get recalled in future tasks. Episodic Memory records what happened; Semantic Memory saves distilled facts and regularities; Procedural Memory records how to act next time—directly influencing tool selection, operation order, verification methods, thus closest to policy capability update. When experience precipitates from single event to long-term rule, source, time, applicability, conflicts, and failure conditions must be recorded simultaneously. Otherwise system cannot distinguish stable regularities, personal preferences, and expired states. Memory can preserve reusable experience but also continuously propagate errors. Without conflict handling and deprecation mechanisms, more accurate retrieval makes erroneous memories called more stably.

3.3 Tool and Skill: Changing What Agent Can Do and How

Tool-layer updates can continuously adjust tool selection strategy, revise existing tools, create new tools per experience. Temporary tool selection in a single task is not self-evolution; only when selection strategy or tool itself is persistently modified and continues effective in subsequent tasks does it constitute Tool-layer update. Tool expands executable actions; Skill encapsulates operation steps, tool combinations, failure recovery, domain rules into reusable methods. After successful traces are organized into Skills, Agent need not explore from scratch each time, but accidental success paths may be solidified as default behavior. Reliable Tools and Skills need explicit I/O, preconditions, dependencies, versions, applicability, permissions, verification methods. Skills only the model can "read" but runtime cannot verify are unsuitable for high-risk scenarios.

3.4 Workflow: Changing How Tasks Are Decomposed and Advanced

Workflow does not necessarily make the model smarter, but through better task decomposition, step ordering, state management, retry, recovery, lets the same model complete long tasks more stably. The paper "AFlow: Automating Agentic Workflow Generation" represents Workflow as a graph of nodes and connections, automatically searching combinations of task steps, execution order, and Prompts, showing execution structure itself has representational capacity. Workflow suits fixing task decomposition, tool衔接, state transition, search strategy problems. If failure stems from knowledge or reasoning capabilities the base model lacks, adding steps usually only increases calls and cost. Fitness metrics must cover tool budget, state recovery, permission paths, key step checks, preventing systems from raising scores by increasing calls or bypassing constraints.

3.5 Harness: Changing Agent's Complete Runtime

Harness decides what model sees, what it can call, how state is saved, how failures recover, when to dispatch sub-Agents, how to verify results. It connects model to real environment, so modifying Harness can simultaneously change context, tools, state, control flow—scope usually larger than modifying Prompt, Skill, or Workflow alone. Production-grade Harness has two responsibilities: capability layer (context organization, compression strategy, tool descriptions, task orchestration, recovery flows) optimizable under constraints; control layer (sandbox boundaries, approvals, highest privileges, audit, release control) should not be freely rewritten by the same self-modification mechanism.

OpenAI's open-source Codex Harness shows that even with unchanged model, Harness's handling of reasoning state and context can significantly change task performance and token cost—proving Harness is an important capability lever. But engineers optimizing Harness ≠ Agent self-evolution; only experience-driven modifications, persistently written back, and independently verified belong to self-evolution discussed here.

Paper "Meta-Harness: End-to-End Optimization of Model Harnesses" uses external strong Coding Agent to read candidate code, scores, raw traces, propose new Harness. Paper "Self-Harness: Harnesses That Improve Themselves" lets target Agent propose minimal modifications within predefined scope based on failure traces. Former has stronger diagnosis but higher cost and external dependency; latter more autonomous but more limited by own blind spots. Whether either reliably improves depends not on "self-modifying self" but on restricting editable scope, preserving full version lineage, and using independent tests to check regression.

OpenAI Codex Harness splits interaction into Item, Turn, Thread, with external app approving sensitive ops. This design makes actions, session state, human intervention more traceable, and implements "Agent can propose actions but cannot self-approve" as runtime constraint. For self-evolution systems, experience base should record not only text traces but also task/session IDs, config versions, approval results, state changes to support later attribution and replay.

Reliable Harness updates need transaction-like execution: save snapshot first, then isolate modifications, parse dependencies, complete verification, finally decide commit or rollback.

DeepSeek Harness's Cordis provides runtime foundation for component replacement and dependency management. Rolling back code does not mean system state restored; generated side effects (listeners, caches, timers, service references) must also be revoked. Transactional modification solves "how to safely execute and rollback a single Harness modification" but only covers single-update execution safety. How experience forms candidate modifications, how candidates are selected and released, how results continue influencing next Agent round—still need a complete self-evolution loop.

3.6 Model: Changing Agent's Default Capabilities and Behavioral Tendencies

Model parameter updates change what Agent defaults to know and how it tends to judge without extra prompting—largest scope, hardest to locally explain and rollback. Suits scenarios with highly repetitive, structured task patterns, sufficient learning signal quantity/quality, and team capability for training, evaluation, safety re-verification, version governance. Constantly changing local rules, personal preferences, tenant exceptions should not be directly written into model parameters.

Execution experience can be organized into training samples, written into new model versions via continuous post-training, experience replay, or lightweight parameter updates like LoRA, then held-out tasks and Held-out Gate decide adoption. But "ability to periodically train new versions" ≠ model stably gets stronger with use; catastrophic forgetting, goal drift, data deletion, global regression still need separate verification. Even when finally updating model parameters, the experience base saving execution traces, feedback, correction records, plus training pipeline, evaluation, version release, rollback mechanisms, remain outside the model. Parameter-level reliable self-evolution still depends on scaffolding providing complete control loop.

3.7 How to Choose Which Layer to Modify

After a failure appears, don't directly ask model to "be smarter." Instead, first judge root cause: knowledge, interface, execution flow, base capability, or governance constraint; then choose update object with smallest scope, lowest cost, easiest verification and rollback.

Fact or local rule missing → prioritize Context or Memory.

Interface, parameters, preconditions wrong → prioritize Tool or Skill.

Task decomposition, state transition, retry, recovery problematic → prioritize Workflow or Harness.

Only when stable, widespread capability gaps cannot be improved on unseen tasks via shallower modifications → consider updating Model.

Identity, permissions, audit, highest safety constraints are governance issues; should not be given to the same self-modification loop. Different objects update at different speeds: Context and partial Memory fastest; Tool, Skill, Workflow, Harness middle; model parameters slowest. Principle is not "deeper is better" but using minimal sufficient modification to hit root cause. Otherwise system may amplify a local problem via model training, or hand safety constraints meant for code enforcement to Prompt.

4. How Execution Experience Becomes Capability

Previous sections explained why behavior changes after experience written into different objects. But determining which layer to modify requires complete traces, credit assignment, predefined acceptance criteria, and scope constraints. How do these conditions transform execution experience into verifiable, auditable candidate updates in the Learning Loop?

4.1 A Complete Self-Evolution Loop

Traces don't automatically become capabilities. Self-evolution needs a closed Learning Loop: system discovers problems from execution results, proposes candidate modifications, after independent verification releases to next version, then decides retain, rollback, or continue improving based on real runtime results. New version's execution traces, environment feedback, user corrections re-enter experience base as basis for next round. No write-back → only analysis; no continuous observation → one-off optimization; no independent selection → erroneous updates repeatedly written back, forming pollution loop.

From experience to acceptable update, must sequentially complete: save execution scene, distill stable problems, predefine acceptance criteria, select update object, generate candidate modifications, independent verification, phased release, continuous observation, final rollback or consolidate. Corresponding full chain: Task → Run → Trace → Thread → Experience Base → Failure Pattern Mining → Credit Assignment → Optimization Contract → Candidate Generation → Independent Validation → Canary Release → Production Observation → Consolidate/Rollback.

This chain must do three things: locate failure cause, generate and write candidate updates, decide retain/rollback/continue based on independent evidence. Before candidate generation, optimization contract must clarify objectives, modifiable scope, budget, data boundaries, non-regressable capabilities, release conditions. Specific improvement methods can dynamically adjust within these boundaries; all human interventions enter lineage.

4.2 Where the Learning Loop Is Truly Hard

System's observed experience is incomplete. Current policy determines what it encounters/avoids; collected experience not independent fixed-distribution samples. Filtered, human-taken-over, actively abandoned, never-explored tasks don't naturally enter experience base; success may be due to avoiding hard problems. System must record gaps and supplement via controlled exploration or counterfactual evaluation, else may mistake task scope narrowing for capability improvement.

Single failure often cannot be directly attributed to a component. Credit assignment spans multiple execution steps and Memory, Tool, Workflow, Harness levels. Final failure may originate from early retrieval, permission, tool, state, or multiple components jointly. Correlation alone cannot judge which layer to modify; need versioned traces, minimal intervention, component switches, counterfactual replay to verify.

Truly important results often come late. Fast process feedback can filter obvious failures but may not reflect final goals, even induce reward hacking. Only slower real results support consolidating updates or expanding scope. Before long-term results appear, candidate updates can only be temporarily retained, not directly expanded or written deeper.

Every update changes next round's experience. After Workflow, Memory, or model parameters change, Agent behavior and error types change; old evaluation sets and thresholds may gradually lose representativeness. Each version should record corresponding data distribution, evaluator, capability coverage, expand tests per new failures, while retaining stable test sets for long-term comparison.

Exploring new strategies may impact production safety. Replay and simulation suit wider exploration; sandbox verifies real tools; canary provides limited production evidence; high-privilege actions still need human approval. Exploration budget, impact scope, stop conditions must be pre-written in optimization contract.

Multiple update loops may interfere. When Context, Memory, Harness, model, evaluator chase short-term metrics at different speeds, system may oscillate, accumulate rules, or jointly cater to wrong metrics (Coupled Goodhart). Shallow updates should be fast and narrow; deep updates slower with higher evidence thresholds; avoid multiple major variables changing together.

Thus learning loop must focus not only on iteration speed but also candidate count, independent test pass rate, retained gains on unseen tasks, regression rate, extra cost. Otherwise faster loop only solidifies spurious correlations into long-term errors faster.

4.3 How to Form a Complete Learning Loop

Complete loop compresses to four phases: save and distill experience, predefine evidence, select and generate updates, verify/release/consolidate. Each phase must leave traceable inputs, judgments, results.

Capture & Mine: Save complete decision scene: Task, Run, Trace, Thread, component versions, actions, states, environment feedback, human interventions, termination reasons. Identify stable, reproducible, actionable failure patterns from traces; distinguish whether problem from model, tool, data, environment. Clustering only finds similarity, not causation; environment noise, irreproducible samples, user edits, retries, takeovers need further attribution. DeepSeek Harness uses append-only session logs supporting recovery, branching, search, replay—providing runtime foundation for reconstructing execution, but not equal to completed experience distillation. Replaying external ops: reads can truly replay; non-deterministic calls need recording or simulation; writes need dry-run, mock, or compensation to avoid duplicate side effects.

Pre-Evaluate: Before candidate generation, system must define how original failure should disappear, which capabilities must not regress, allowed budget, safety/cost boundaries not to breach. Programmable evidence prioritized over free-text evaluation; open tasks can use expert rubrics or Judge Models, but Evaluator, candidate generator, releaser should not fully overlap; evaluation set must retain parts invisible to candidate generator.

Route & Repair: After attribution, select primary update object, decide if update applies to individual, team, or org. Simultaneously modifying multiple layers weakens attribution and increases rollback difficulty. Generated Context, Memory, Tool, Skill, Workflow, Harness patches, or parameter training data are only candidate updates; must record source, applicability, dependencies, version, expected changes, rollback method. Closer to full runtime or model parameters → more restrict edit scope, keep minimal changes.

Post-Validate, Release, Observe & Consolidate: Each candidate must pass four checks: original failure fixed (held-in), unseen similar tasks improved (held-out), existing capabilities not regressed (regression), cost/safety/external side effects acceptable. After sandbox tests, updates enter canary, human approval, or formal version per scope, continuously observing performance drift and new failure types. Experiences stable across multiple verifications are suitable for distillation from single event into facts, action methods, even model parameters: Local, volatile, need-anytime-revocable knowledge stays in Context; only stable, general, thoroughly verified patterns suit model parameters. Loop must also allow subtraction: delete no-gain components, clear polluted Memory, retire outdated Harness, avoiding continuous learning degrading into component/rule accumulation.

Learning loop doesn't automatically turn experience into capability; it only turns experience into traceable, verifiable, retractable candidate updates. Only when failure cause locatable, modification scope constrained, candidate passes independent verification, and post-release continuously yields net gains, can experience precipitate into capability. Even passing release gate only proves limited-scope deployability, not that Agent evolved. More sampling, human intervention, or search set leakage can also raise scores. How to judge if observed gains truly attributable to self-evolution?

5. How to Prove Agent Really Evolved

5.1 Why Score Increase ≠ Capability Increase

A performance rise may come from persistent updates, but also from more compute/sampling, candidate screening, environment changes, human intervention. These factors interact; cannot infer new capability from score rise alone. Reliable experimental conclusions must align compute, tokens, actual runtime, human investment, and strictly separate candidate search, validation, final test. Most effective method: not accept score first, but find other explanations for score, then eliminate via targeted experiments. The following table (converted) lists observed phenomena, alternative explanations, and necessary experiments:

Benchmark score increase → search samples written into update object → independent unseen task test (Held-out Test).

Pass@K increase → increased sampling, not single-run capability → Pass@1 under equal budget with cost alignment.

Original failure fixed → only patching single case → transfer test on unseen tasks with same mechanism.

New Skill generated → file exists but behavior not improved → Skill switch ablation and dependency failure test.

Harness self-modification score increase → rewriting evaluation, skipping tests, hiding failures → protected external evaluator and execution audit.

Parameter update local performance increase → local gains accompanied by other capability regression → cross-capability regression test.

Online success rate increase → environment, tools, human intervention changed → version control, environment control, human budget alignment.

This table forms minimum evidence chain for judging effective and reliable self-evolution. Only proving original failure disappears at most shows candidate fixed current problem. Only after excluding other explanations can gains be attributed to persistent capability updates.

5.2 What Evidence Can Prove Capability Growth

Verification scale must match update's persistent effective scope: Single-step scale (Run-level) checks one decision; Task scale (Trace-level) checks one end-to-end task; Cross-task scale (Thread-level) checks memory, state, behavior changes across multiple tasks. First two give fast feedback but miss cross-session pollution; parameter updates and long-term Memory cannot rely only on short-term benchmarks. A credible experiment needs deeper analysis: complete performance trajectories, multiple random seeds, result variance; compute, tokens, actual runtime, human investment; unseen task transfer and regression rate; safety violations, cost, latency; metric-based vs. Judge-model-based evaluators; Judge model's model, Prompt, rubric, Context, budget. Same Judge model should not provide both main learning signal and final referee. Separating candidate generator and verifier reduces shared blind spot risk but doesn't fully solve open-task reliable judgment standard lack (Oracle Problem). Ultimately must combine environment evidence, expert judgment, real usage results.

5.3 Why Different Research Reaches Opposite Conclusions

Harness self-evolution research shows same technical route can yield opposite conclusions due to different evaluation methods. "Rethinking the Evaluation of Harness Evolution for Agents" under unified budget found: without reliable external signals, Harness self-evolution may underperform simple sampling; gains may mainly reflect Pass@K (at least one success in multiple samples) not Pass@1 (single-run capability); after strict separation of candidate search, validation, unseen task test, average transfer gain near zero. This means Harness self-evolution score gains may only expand search and sampling, not reflect true single-run transferable capability improvement; only gains retained after budget alignment and strict data isolation can be attributed to self-evolution. Meanwhile, Self-Harness, Meta-Harness report improvements on unseen, OOD, cross-model tests. Results not necessarily contradictory because they differ in editable scope, feedback method, data isolation, budget protocol, evaluation metrics. Different methods only comparable under unified budget and test protocol. Harness modified only proves update occurred; outperforming equal-budget baseline on unseen tasks suggests update may be effective; maintaining cost, safety, permission stability across versions approaches reliable evolution.

5.4 Evaluator Determines Evolution Direction and May Be Exploited

Evaluator decides which modifications are retained, so system may learn to raise scores not truly improve capability. Common exploitations: Reward Hacking (shortcuts in reward definition), Benchmark Overfitting (memorizing fixed test distribution), Coupled Goodhart (multiple update loops jointly catering to metric), Agent Hacking (modifying runtime to skip tests, hide failures, expand permissions). When candidate generation capability exceeds evaluation capability, system finds evaluation loopholes faster. When evaluation capability stronger, progress slower but erroneous updates harder to retain. Therefore, modifiable space only determines how much change system can produce; verifiable space determines how much can be reliably accepted. Verifiable space depends on optimization contract, verification budget, data isolation, risk tolerance, feedback quality—not fixed component attribute. Replayable, test-executable Harness modifications easier to verify; long-term open tasks lacking timely feedback harder. Evaluator both directs evolution and may be target of candidate exploitation. How modification rights, evaluation rights, release rights are allocated ultimately decides if system can distinguish capability growth from metric gaming.

6. Boundaries and Open Problems of Agent Self-Evolution

6.1 Current Capability Boundaries

Existing Agent self-evolution mechanisms' boundaries summarized in four points:

Limited applicable tasks. Most reliable: clear goals, verifiable results, replayable environments (e.g., code, terminal ops); open knowledge work, long-term collaboration, high-risk production tasks lack reliable feedback/verification.

Limited improvement scope. Prompt, Memory, Skill, Workflow, Harness, model parameters all updatable per experience, but most results remain local improvements in specific tasks and controlled environments, not proven long-term cross-domain stable transfer.

Limited recursion depth. STOP, DGM show improvement-responsible mechanisms modifiable, but goals, tasks, evaluation standards, version selection still externally defined/supervised. Constrained recursive improvement experimental; open-ended RSI not achieved.

Limited autonomy. Agents can propose and execute candidate modifications, but cannot simultaneously hold goal definition, final evaluation, highest privileges, release approval, recovery mechanisms—else system cannot distinguish capability growth from evaluation standard rewrite.

Thus current Agent self-evolution's accurate boundary: System can already modify itself within controlled scope based on experience, accumulate local capabilities via external verification; but cannot long-term autonomously set goals, modify evaluation standards, and prove continuous improvement in open environments.

6.2 Research Frontiers and Unsolved Problems

Research focus shifting from expanding modifiable scope to improving candidate update selection and verification reliability. Four key problems remain:

Long-term stability and forgetting. Gains on few tasks/limited rounds don't prove long-term effectiveness. Self-evolution may gradually cause capability degradation, behavior drift, knowledge pollution; once erroneous experience written into model parameters, hard to precisely delete.

Open tasks lack reliable evaluation standards. Code can be judged by compiler/tests; but research analysis, business decisions, legal opinions, strategic planning often have no single correct answer—quality depends on factual basis, context, risk trade-offs, long-term outcomes. Fixed evaluators become stale; co-evolving evaluator with candidate generator risks joint metric gaming. How to continuously reliably judge "which version is better" is core difficulty of recursive self-evolution.

Multi-Agent co-evolution hard to attribute. One Agent's update may change team division, communication, other Agents' data; system performance changes hard to attribute to specific Agent or update; unit tests cannot cover new problems from collaboration changes.

Short-term gains may harm long-term quality. One task success doesn't mean new version more maintainable, backward-compatible, suitable for long-term use. Self-evolution may trade higher complexity, migration cost, organizational dependency for short-term scores.

Thus next phase of Agent self-evolution lies not in generating more modifications, but in reliably judging which modifications bring real, sustainable capability growth in long-term, open, multi-Agent environments.

Conclusion

Three misconceptions to avoid: task-internal reflection/retry ≠ self-evolution; generating new Memory/Skill/Harness ≠ capability improvement; evaluation score increase ≠ acquiring transferable, reliable new capability. In practice, choose update method per speed, expected gain, implementation difficulty. For local knowledge, rules, retrieval issues → prioritize Prompt, Context, Memory (fastest, lowest cost, easiest verify/rollback). For recurring tool usage, task decomposition, execution flow issues → consider Tool, Skill, Workflow, Harness (higher investment/risk but more stable reusable gains). Only when capability gap long-term, wide impact, training data and evaluation mature, expected gain covers training/global regression cost → update model parameters. Regardless of layer, first small-scale verify, then decide expansion per actual net gain. Judgment standard not score increase, but whether update improves unseen tasks at comparable cost without unacceptable regression, safety risk, maintenance burden.

References

"Self-Improvements in Modern Agentic Systems: A Survey", arXiv, 2026. https://arxiv.org/abs/2607.13104

"SIA: Self Improving AI with Harness & Weight Updates", arXiv, 2026. https://arxiv.org/abs/2605.27276

"Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation", arXiv / COLM, 2024. https://arxiv.org/abs/2310.02304

"AFlow: Automating Agentic Workflow Generation", arXiv, 2024; ICLR, 2025. https://arxiv.org/abs/2410.10762

"Meta-Harness: End-to-End Optimization of Model Harnesses", arXiv, 2026. https://arxiv.org/abs/2603.28052

"Self-Harness: Harnesses That Improve Themselves", arXiv, 2026. https://arxiv.org/abs/2606.09498

"DeepSeek Harness developer preview: Everything is a plugin", DeepSeek, 2026. https://deepseek.com/harness/en/

"Rethinking the Evaluation of Harness Evolution for Agents", arXiv, 2026. https://arxiv.org/abs/2607.12227

"Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents", arXiv, 2025; revised 2026. https://arxiv.org/abs/2505.22954

"Rethinking Self-Evolving Agents: Do We Still Need Prescribed Optimization Pipelines?", arXiv, 2026. https://arxiv.org/abs/2608.09629

"Codex as a platform: build on the open agent harness", OpenAI, 2026. https://developers.openai.com/blog/codex-as-a-platform

"Unlocking the Codex harness: how we built the App Server", OpenAI, 2026. https://openai.com/index/unlocking-the-codex-harness/

"How enabling two settings tripled our scores on ARC-AGI-3", OpenAI, 2026. https://openai.com/index/how-two-settings-tripled-our-arc-agi-3-scores/

"openai/codex", GitHub, 2026. https://github.com/openai/codex