This paper formalizes harness self-evolution: agents that revise their own prompts, memory, workflows, and code (but not model weights) across runs, with a taxonomy of what gets edited and conditional PAC learning bounds for when accepted revisions should generalize.
You’ve deployed an LLM agent. Tasks drift, tools break, new file formats appear. You have two ways to adapt: retrain the model, or let the agent rewrite the scaffolding around a fixed model. That scaffolding, the harness, is the prompts, stored memory, workflow graph, tool code, and runtime glue that turn a frozen model into a working agent.
Harness editing is attractive because it reuses your existing model deployment, works through proprietary APIs where you can’t touch weights, and leaves a human-readable diff you can review. But the literature here is a tangle: Reflexion, Voyager, ExpeL, AFlow, GEPA, and others each revise something different (a memory entry, a skill function, a workflow DAG) using different proposal and acceptance rules. There’s no shared vocabulary for what counts as self-evolution versus just logging, and no clear story about when a revision that helped yesterday will still help tomorrow. This paper is a 66-page survey and framework attempting both.
The core move is a definition plus a taxonomy. A harness H wraps a fixed model M running in environment E. Each round, the current harness produces a batch of rollouts; an Update operator diagnoses them, proposes revisions, assesses candidates, and either admits one (persisted for future runs) or keeps the incumbent. Two requirements make this self-evolution rather than ordinary logging: the system must algorithmically construct revisions from its own execution feedback, and accepted revisions must persist across runs. Appending logs under fixed rules doesn’t count; learning a reusable procedure does.
The taxonomy sorts methods by what gets edited:
•
Interpreted-state updates: prompts, stored experiences, workflow routing over fixed operators. The executor is unchanged; only the content it reads changes.
•
Executable revisions: new or rewritten tool code, repository-level control logic (orchestration loops, recovery, context construction), or plugin bindings that swap which implementation provides a runtime service like memory or tool dispatch.
The plugin view, which the authors call Everything Is a Plugin (Everything Is a Plugin), is the most permissive: capabilities can be generated, validated, and mounted during operation through declared interfaces.
On the theory side, they map candidate generation to evolutionary search and borrow classical stability and concentration results to state three conditional guarantees: an expected generalization bound, a retention bound (how much accumulated regression you can tolerate before cumulative drift kicks in), and a high-probability admission rule using fresh, independent validation data. These are conditional on explicit assumptions and don’t automatically hold for any given system.
The lifecycle, as pseudo-code:
H = H_initial
for k in rounds:
batch = [run(M, H, E_i) for E_i in sample_tasks(k)]
candidates = propose(H, batch, archive, history)
scored = assess(candidates, fresh_validation_data)
if admit(scored): # high-prob rule, independent data
H = scored.best
archive.append(H)
# else: keep incumbent H
This is a survey and framework paper, so “findings” means claims about the landscape plus illustrative numbers pulled from cited systems. Treat these as examples of the taxonomy, not head-to-head benchmarks the authors ran.
•
On SpreadsheetBench, the cited HarnessOpt + skill configuration with GPT-5.4-Nano reaches 77.58%, slightly above GPT-5.5 with the prior SkillOpt at 76.20%. Across four models, HarnessOpt with skill improves on SkillOpt-Lite by 5.69 to 11.39 percentage points. The authors flag this as illustrating model-harness pairing, not a matched-cost superiority claim.
•
An Everything Is a Plugin case study using Codex-generated tools on simulated multi-region spreadsheets shows tool calls dropping from 13 to 3 on the first task, but wall time rising 54.9% and tokens 15.7% because the agent spends effort synthesizing tools. Cumulative savings appear from the second task onward, reaching 110,351 tokens and 22.97 s saved after five tasks.
•
The authors explicitly note an inconsistency between the first-task cost totals and the cumulative series in the cited source, and refuse to treat them as a single trajectory. That kind of flagging is the main editorial posture of the paper.
The conceptual finding: empirical selection alone (pick the candidate that scored best on recent rollouts) doesn’t give you generalization or retention. You need the admission rule to use fresh, independent validation, and you need a budget for how much historical regression you’ll accept before rolling back.
•
If you’re building a self-improving agent, use the interpreted-vs-executable split to decide your blast radius. Editing a prompt or a stored skill entry is local; editing the orchestration loop or a plugin binding can silently change inputs to unchanged components. The paper’s recommendation to add edit constraints, transfer-oriented admission tests, and deployment checks follows directly from this coupling, and is worth adopting even without the formal bounds.
•
If you’re evaluating a published “self-evolving agent”, the two-requirement test (algorithmic revision from own feedback, persistence across runs) is a quick filter. Many systems that market themselves this way only satisfy one. The authors also note that an exported evolved program only continues to qualify if its deployment keeps the update mechanism attached.
•
If you want the theoretical guarantees to bind, you need an independent validation set for admission, not the rollouts that produced the candidate. This is the practical teeth of the high-probability admission rule. Reusing the same trajectories for proposal and acceptance is where the bound breaks.
•
If you want the broader survey, code and the full 66-page discussion are at GitHub. This is a framework and survey, not a benchmark paper. The numbers cited (SpreadsheetBench, the EIP case study) come from other works and are reproduced to illustrate categories, not to rank methods. The theoretical bounds are conditional on explicit assumptions (stability of the learner, independence of validation data, bounded regression budget) that real systems rarely verify. The authors are careful about this; a reader skimming for “does harness self-evolution work” will not find a clean yes. Finally, the paper repeatedly flags safety: persistent harness revisions propagate across runs and users, so independent safeguards for learning, runtime privileges, and consequential actions are treated as prerequisites, not add-ons.