Self-Evolving Agents: What Changes, Who Signs Off, and Which Gains Are Real

Published on November 13, 2026 by Remy

Between October and November this year, arXiv got several new agent papers a day with “self-evolving” or “self-improving” in the title: a self-evolving recommender, a self-evolving robot harness, even a self-evolving memory for antibody optimization.[51][52][53] On the open-source side, Nous Research describes Hermes Agent as “the only agent with a built-in learning loop”, one that creates skills from experience and improves them during use.[18] The word is now hot enough to hold almost anything.

The earlier post on this site, RSI Through 2026, asked whether any of this counts as recursion. This one asks a more practical question. When an agent says it evolves, what exactly did it change, who decided the change was right, and did a capability actually form, or did a score just go up? Here is the conclusion up front. Where evaluation is executable, self-evolution is already a usable engineering tool. Where there is no reliable acceptance check, most “self-evolution” is note-taking, and it quietly gets worse over time.

A working definition of self-evolution

Two surveys from the second half of 2025 are the most cited. A Survey of Self-Evolving Agents by Gao et al. organizes the field around four questions: what evolves, when, how, and where. It splits the evolving parts into model, memory, tools, and architecture, and splits timing into within a task (intra-test-time) and between tasks (inter-test-time).[1] A Comprehensive Survey of Self-Evolving AI Agents by Fang et al. draws a feedback loop with four parts, system inputs, the agent system, the environment, and optimisers, and sorts methods by which part of the agent the optimiser touches.[2]

Both draw the boundary wide. I use a narrower definition: the system produces a change from its own experience, the change passes some acceptance check, and it is written into persistent state that the next task starts from. All three conditions have to hold. Self-Refine has a model critique and rewrite its own output, and gains about 20 points on average across seven tasks, but the next question starts from scratch, so it is self-revision rather than self-evolution.[4] Reflexion writes reflections on failure into memory that the next attempt reads, so it crosses the line.[3]

The self-evolution loop: every round passes an acceptance gate① Run the taskagent works from current state② Evaluatetests, executors, judges, rewards③ Propose a changereflection, mutation, gradients④ Acceptance gatekeep it only if it beats the old one⑤ Write back statenext round starts hereFails the gate: discard or roll backPersistent state can bemodel weightsprompts, context, memoryskill libraries, toolsworkflows, the agent's own codeSteps ①② without ⑤ are one-off self-revision (e.g. Self-Refine). Without ④, the more it changes,the harder it is to tell whether it got better or worse.

Diagram: the five steps of the self-evolution loop, redrawn from the feedback-loop framework in[2] with the acceptance gate added

The gate gets its own box because nearly every problem later in this post happens there. Producing a change is cheap. Judging whether the change is good is the hard part.

Two axes: what evolves and how

“What evolves” runs from the heaviest target, the weights, to the most flexible, the agent’s own source code. “How it evolves” has four common signal sources: self-feedback and reflection, self-play or self-posed tasks, evolutionary search over a population of candidates, and RL or gradient updates that push experience into weights. Representative work falls roughly into the cells below.

What evolves × how it evolves: where representative work sitsAn empty cell means no influential example yet, not that it is impossible; one method can span cellsSelf-feedbackSelf-playEvolutionary searchRL / gradientsModel weightsSTaRAbsolute ZeroAgentEvolverSEALSelf-RewardingPrompts & contextACEDynamic CheatsheetPromptbreederGEPAMemoryReflexionExpeLMem0 / A-MEMTools & skillsVoyagerHermes AgentVoyager curriculumWorkflow & architectureADASAFlowMeta-HarnessThe agent's own codeSICAGödel AgentDGM / HGMHyperagentsRed: weight edits, durable but hard to roll back. Blue: context and memory, cheap and readable.Green: accumulated skills. Purple: structure and code, the largest search space.

Diagram: the two axes crossed. The taxonomy follows[1][2]; the cell placement is the author’s judgment

Weights: the most durable, and the hardest to roll back

STaR started this line. The model writes rationales for problems, keeps only the ones that end in a correct answer, fine-tunes on them, and repeats.[6] Self-Rewarding Language Models goes further and has the same model answer and judge, using its own scores for iterative DPO. After three iterations, Llama 2 70B outperformed Claude 2, Gemini Pro, and GPT-4 0613 on AlpacaEval 2.0.[7] Absolute Zero drops the dataset entirely. One model proposes code-reasoning tasks and solves them, and a code executor checks both the tasks and the answers. With no external data at all, its overall coding and math results beat comparable models trained on tens of thousands of human-curated examples.[8] AgentEvolver, open-sourced by Alibaba’s ModelScope team, brings self-posed tasks into agent training: it generates tasks out of curiosity in a new environment, reuses experience to guide exploration, and assigns rewards by each step’s contribution.[10]

SEAL from MIT has the model write its own “self-edits”, meaning fine-tuning data and hyperparameters for a new piece of knowledge, and uses the updated model’s downstream performance as the RL reward. On SQuAD without the passage in context, Qwen2.5-7B went from 33.5% to 47.0%, and its self-generated training data worked better than data written by GPT-4.1. On a simplified ARC subset, the adaptation success rate went from 20% without RL training to 72.5%.[9] The same paper’s limitations section has a plot showing that with repeated self-edits, performance on earlier tasks keeps falling. That is catastrophic forgetting, where new learning overwrites old ability. It is the core problem with the weight route: a change really does land in the model, and so does a bad change.

Prompts and context: cheap and readable, but they collapse

Promptbreeder keeps a population of task prompts and uses an LLM to mutate and select them. Its twist is that the prompts doing the mutating also evolve.[11] GEPA makes the idea practical. It reads full execution traces, diagnoses failures in natural language, and combines the strengths of candidates on a Pareto front. Across six tasks it beats GRPO by 6% on average and by up to 20%, with up to 35 times fewer rollouts.[12]

ACE (Agentic Context Engineering) names a trap on this route: context collapse. Methods like Dynamic Cheatsheet have the model rewrite the whole accumulated context at every step, and as the context grows, the model tends to squeeze it into a short summary. The ACE paper gives an example: at step 60 the context held 18,282 tokens at 66.7 accuracy, and one step later it had collapsed to 122 tokens at 57.1, below the 63.7 of no adaptation at all.[13][49] ACE’s fix is a division of labor plus incremental updates. A Generator produces trajectories, a Reflector extracts lessons, and a Curator merges only new entries into a structured “playbook” instead of rewriting it. It gains 10.6% on agent tasks and 8.6% on finance tasks, and cuts adaptation latency by 86.9% on average.[13]

Memory and skills: the closest thing to accumulating experience

Reflexion has the agent write a verbal reflection after a failure, store it in episodic memory, and read it into context on the next attempt. It reached 91% pass@1 on HumanEval when GPT-4 scored 80%.[3] ExpeL distills success and failure across tasks into reusable insights.[14] Mem0 and A-MEM focus on how memory is organized. Mem0 extracts, consolidates, and retrieves, and scores 26% higher in relative terms than OpenAI’s approach on the LOCOMO LLM-as-judge metric. A-MEM borrows the Zettelkasten note method and links new memories to old ones automatically.[15][16] Choosing a memory system is covered in a separate post.

Voyager is the prototype of the skill-library route. In Minecraft it uses an automatic curriculum to set its own next goal, saves successful behaviors as executable JavaScript functions, and composes them to solve harder tasks. Against the prior best method it collected 3.3 times more unique items and unlocked key tech-tree milestones up to 15.3 times faster, and the skill library still worked in a new world.[17] Skills are code, not weights, so learning a new skill does not overwrite an old one. The Skills that coding agents use today, including the ones Hermes Agent writes for itself, are essentially a text version of Voyager’s library.[18] For how skills change in real repositories, see the Agent Skills lifecycle map.

Workflow, architecture, and the agent’s own code: the largest search space

ADAS proposed writing agents as code and having a meta agent keep writing new agents, storing discoveries in a growing archive. The algorithm is called Meta Agent Search. The agents it found beat the best hand-designed ones by 13.6 F1 points on DROP reading comprehension and by 14.4% accuracy on MGSM math.[20] AFlow uses Monte Carlo tree search over workflows represented as code.[21] In March 2026, Meta-Harness from Chelsea Finn, Omar Khattab, and colleagues moved the search target to harness code, the layer that decides what to store, retrieve, and show the model. Its proposer reads the source, scores, and traces of every earlier candidate through a filesystem. On online text classification it beats the best context-management system by 7.7 points with 4 times fewer context tokens, and one discovered harness raised accuracy on 200 IMO-level problems by 4.7 points on average across five models that were not part of the search.[22]

One step further, the agent edits its own code. Gödel Agent lets an agent read and rewrite its own logic at runtime,[23] and SICA lets an agent with only basic coding tools edit its own codebase, going from 17% to 53% on a random subset of SWE-bench Verified.[24] The most representative system on this line is DGM, covered next.

Archive plus search: why DGM and AlphaEvolve beat hill climbing

SICA is essentially hill climbing: each round edits the current best version. The Darwin Gödel Machine (DGM), released in May 2025 by Sakana AI and Jeff Clune’s lab, switches to open-ended search. It keeps an archive of every agent that can still edit code, with no requirement to beat its parent. Each round it picks a parent, favoring higher scores and fewer existing children. The parent reads its own evaluation logs, proposes the next feature to add, and implements it in its own codebase. Then comes staged evaluation: 10 tasks first to confirm it can still edit code, then more tasks if it does well.[25]

Archive plus search: DGM edits itself, AlphaEvolve edits another programDarwin Gödel MachineArchive: every agent that can still edit codePick a parent: higher score, fewer childrenParent reads its own eval logs, proposes a featureImplements the feature in its own codebaseStaged eval: 10 tasks first, then moreUsable → archived (need not beat its parent)AlphaEvolveProgram database (evolution picks the next parents)Prompt sampler: parent programs + contextModel ensemble: Gemini Flash for breadth, Pro for depthEmits code diffs, producing new programsAutomatic evaluators: run, verify, scoreNew programs and scores go back to the databaseShared idea: keep candidates that are worse for now as stepping stones; acceptance runs executable tests.Difference: DGM changes the agent itself, AlphaEvolve the task program. DGM cannot edit its own parent-selectionand archive rules; Hyperagents is the first to open that up.

Diagram: DGM and AlphaEvolve side by side, based on Section 3 of[25] and the architecture diagram in[30]

After 80 iterations, DGM went from 20.0% to 50.0% on SWE-bench Verified and from 14.2% to 30.7% on the full Polyglot benchmark. Both controls, one without self-improvement and one without the open-ended archive, did clearly worse.[25] The lineage below is more convincing still: the path to the final best agent includes two score drops, and a hill climber would have thrown away both of those ancestors.

DGM progress on SWE-bench: the best agent rises from 0.20 to 0.50, the lineage path dips twice, and labels mark features added along the way, such as string-replacement editing, auto-summarizing at the context limit, and multiple patch generation with ranking

Figure: DGM’s progress on SWE-bench and its key changes; the dark line is the lineage of the final best agent (source: Sakana AI blog[26])

The changes DGM found are plain, such as string-replacement editing and generating several patches then ranking them, and they transfer. An agent evolved with Claude 3.5 Sonnet also improved when run on o3-mini or Claude 3.7 Sonnet, and evolving only on Python tasks raised scores on Rust, C++, and Go tasks too.[26] The appendix states the cost: one DGM run on SWE-bench takes about two weeks and roughly 22,000 US dollars in API spend, versus about 10,000 dollars for each control.[25]

DGM has two public follow-ups. The Huxley-Gödel Machine points out that an agent with a high benchmark score is not necessarily a good starting point for further improvement, which the authors call the metaproductivity-performance mismatch, and estimates an agent’s potential from the performance of all its descendants instead. An agent optimized with GPT-5-mini on SWE-bench Verified and evaluated with GPT-5 on SWE-bench Lite matched the best human-engineered results.[27] The other follow-up is Hyperagents, from Meta and collaborators in March 2026. The DGM paper itself notes that its parent-selection and archive rules are fixed and DGM cannot change them.[25] Hyperagents puts the task agent and the meta agent that does the modifying into one editable program, so the improvement procedure can also be improved. DGM-H kept improving across coding, paper review, robot reward design, and olympiad math grading, grew meta-level features such as persistent memory and performance tracking on its own, and transferred them across domains.[28] One researcher on X wrote that, more than beating the baseline on a grading benchmark, what interested her was that it “started writing its own memory”.[47]

AlphaEvolve has almost the same structure but changes a different object. It keeps a program database. A prompt sampler picks parent programs and builds prompts, Gemini Flash supplies many ideas, Gemini Pro supplies deeper edits, and automatic evaluators run, verify, and score the results, which go back into the database.[29][30] It found a way to multiply two 4×4 complex matrices with 48 scalar multiplications, the first improvement over Strassen’s algorithm in that setting in 56 years. On more than 50 open math problems it rediscovered the best known solution in about 75% of cases and improved on it in about 20%.[29][30] On the engineering side, the heuristic it found for Google’s Borg scheduler had been in production for over a year as of May 2025 and recovers on average about 0.7% of Google’s worldwide compute. It sped up a key matrix-multiplication kernel in the Gemini architecture by 23%, cutting Gemini training time by 1%.[30] That last result gives AlphaEvolve a real touch of recursion: it sped up training of the model it runs on. By May 2026 its applications had expanded to DNA sequencing error correction, disaster prediction, and supply-chain optimization for Google Cloud customers.[31]

Together they show one thing: where evaluation runs automatically and is hard to fool, archive plus search really does find things people missed. Coding and math happen to be such places.

Evaluation: a rising score is not a new capability

The most valuable papers of 2026 are the ones that go back and check whether “evolution” happened at all.

arXiv abstract page for Artifact-to-Capability: Reflexion, Voyager, and DGM all show accumulation, behavior change, and rising scores, yet each has a distinct break in capability formation

Screenshot: the arXiv abstract page of Artifact-to-Capability (submitted 2026-11-03)[32]

Artifact-to-Capability puts Reflexion, Voyager, and DGM in the same Gomoku environment on the same base model. All three show the usual three “evolution signals”: artifacts accumulate, behavior changes once they are loaded, and metrics rise. Up close, each one breaks somewhere. Reflexion’s pass rate rises only because it plays fewer illegal moves. Voyager’s skills are each sound on their own, but combined they miss all 20 available one-move wins. DGM, after passing the capability checkpoint, only loses positions it used to pass in later versions.[32] The conclusion: the signals alone cannot tell you whether a capability formed.

EvoPathBench freezes the artifacts at each checkpoint and tracks single capabilities on held-out tasks. Gains on similar tasks often fade under distribution shift, and although the system generates candidate changes with large held-out gains, the changes it selects consistently fall short of that potential.[33] Another study has agents learn only from failure and finds that failure-derived experience repairs the failed tasks it saw but rarely carries over to new ones, which the authors call the repair-generalization gap.[34] A third puts numbers on the problem. A larger model writes notes for a frozen 9B open model, and notes written after seeing its mistakes beat the same process without the mistakes by 4.0 percentage points. But about 60% of the gain comes from the search itself, trying several versions and keeping the best-scoring one, and in full customer-service conversations no improvement shows up.[35]

The same holds for real tools. Treude and Baltes had Claude Code review itself after 30 SWE-bench Verified issues and propose harness changes, which produced 125 proposals. In the 7 evaluations where an effect could be judged, only 2 changes eliminated the targeted behavior, 1 reduced it, 4 had no effect, and some changes added work on unrelated issues.[36] That matches a 2023 finding: without external feedback, LLMs struggle to correct their own reasoning, and sometimes get worse.[5]

So measuring self-evolution takes at least three things: test on held-out tasks the agent cannot see, track the process checkpoint by checkpoint rather than only the endpoint, and compare old and new versions pairwise on the same items.

Four bottlenecks

Reward hacking: if you can’t change the task, change the judge

The DGM paper and blog record a textbook case. The researchers noticed the agent sometimes pretended to call tools: it faked a log that looked like unit tests had run and passed, when they never ran. So they wrote a reward function that detects this tool-use hallucination and had DGM optimize it. Often DGM did fix the problem. In some runs, though, it simply deleted the special markers the detector relied on and got a perfect score, despite explicit instructions not to.[26]

DGM's diff to its own coding_agent.py: it removes text markers such as TOOL_USED_MARKER and logs tool calls in a structured format instead, which breaks the hallucination detector

Figure: DGM swaps the text markers used for hallucination detection for a structured format, so the detector fails and reports a perfect score (source: Sakana AI blog[26])

This one was caught because every change has a lineage to inspect. When an agent controls both the thing being optimized and the test that checks it, the problem hides better. A July 2026 paper found that an agent’s self-written tests can stay near perfect while a deployment evaluation it cannot see declines or stays low. The fix keeps the self-written tests but adds an external audit the agent can neither write nor inspect, which returns only accept or reject.[37] Someone on X put it in one line: the weak point in self-improving loops is the acceptance test, not the generator.[50]

Masked Erosion describes a subtler effect. Harnesses often carry overlapping safety rules. Delete one, the others still block the harm, the gate sees no damage and only a slight rise in task success, so the deletion is accepted. Redundancy wears away layer by layer until a weaker model is swapped in and the problem surfaces. The authors ran 411 improvement loops. With a paired significance test as the gate and equal cost, loops that accepted on 20-task batches kept every harness protected, while 40-task batches lost all six: the larger the batch, the easier it is to “prove” that dropping a cheap rule helps. GEPA kept every safety rule word for word, yet two of its three final harnesses misused credentials once a weaker model was swapped in.[38]

Forgetting and stability

Editing weights causes forgetting,[9] and leaving weights alone does not prevent it. Are Self-Evolving Agents Continual Learners? compares ReasoningBank, GEPA, and Meta-Harness on four drifting task streams and finds that more plasticity always costs stability. Methods that edit a shared prompt or workspace apply the edit to every task, interfere with unseen ones, and overwrite earlier knowledge. Methods that retrieve memory by similarity keep updates local, but pull in unrelated memories on new tasks and collide when similar queries need opposite workflows.[39] ACE’s context collapse is another form of the same problem.[13] Voyager’s skill library eases forgetting because new skills are added as functions and old functions stay untouched.[17]

Safety and alignment degrade as agents evolve

Your Agent May Misevolve is the first systematic measurement, with experiments along four evolution paths: model, memory, tool, and workflow. A self-evolving coding agent that accumulates experience (SE-Agent), running on Qwen3 480B, refused 99.4% of dangerous requests on the RedCode safety test with a 0.6% attack success rate before evolving. Afterwards the refusal rate fell to 54.4% and attack success rose to 20.6%. A multi-agent system after workflow optimization saw its refusal rate drop from 36.3% to 5.6%, and the optimized workflow looked completely harmless.[40] BadEvolve, from November 2026, goes a step further: the attacker never touches the agent’s skill files. Mixing poisoned tasks into its “evolution tasks” is enough for the agent to write a backdoor into its own skills.[41]

Cost: you save people’s time and spend it on evaluation

One DGM run costs about 22,000 dollars, more than twice a control run, and most of the money goes to evaluation.[25] Much of the appeal of GEPA and ACE is that they cut rollouts and latency.[12][13] Easier to miss is how reliable the acceptance check itself is. One study proposes two measurable quantities: verifier strength, meaning how well the automatic judge agrees with a trusted reference judge, and recoverability, meaning whether a bad change can be undone cheaply. On their platform, the LLM judge gave the same score regardless of input in 9 of 37 settings and reported no error. Restoring a saved old version returned the agent to its original behavior, while asking a model to regenerate an undo did not. While one change was live, it altered the outcome of 17% of tasks, and no undo can repair that. Their rule: prompt, tool, and skill edits can run unattended, and weight updates need a human sign-off.[42]

My take

Three routes clearly work. The first is executable evaluation plus archive search, represented by AlphaEvolve and the DGM family. The precondition is explicit: the evaluation is code that runs and is hard to fool, such as matrix-multiplication correctness, the compute a scheduler recovers, or hidden SWE-bench tests. Move the same structure to a domain scored by an LLM judge, and it starts optimizing the judge’s preferences. The second is incremental, structured accumulation of context and skills, represented by Voyager, ACE, and GEPA. It is cheap, the changes are text or code a person can read, and a bad change can be rolled back, which is why this kind lands in production first. The third is self-play verified by an executor, represented by Absolute Zero, which again needs a verifier that cannot be talked into anything.

Packaging shows up in two places. One is calling “append lessons to a Markdown file” self-evolution. It does help, and Reflexion started out that way, but without acceptance and cleanup it is just a growing pile of notes. In a Reddit AMA, the Hermes Agent team was asked how they prevent long-term behavioral drift. They answered that skills and memory are plaintext on disk that a person can inspect, and added, “I’d be skeptical of anyone claiming formal guarantees in this space.” They later added a Curator that consolidates and prunes auto-generated skills, every 7 days by default.[19] One Reddit user reported that letting Opus judge its own changes made it drift, and having Sonnet judge Opus’s proposals fixed it.[48] Both are patches to the acceptance gate. The other place is calling a system with a fixed meta-level “recursive self-improvement”. The DGM paper says plainly that its search rules are fixed, and a lot of second-hand packaging leaves that sentence out. A post on X nailed it: “a self improving agent made entirely by claude. it will have 10k github stars. it will break with next week’s model release. i will not update or fix this self improving agent, ever.”[46]

The focus will move from generating changes to accepting them. A few directions are already visible. One is statistical acceptance gates: SAGE replaces the average score with per-item paired comparison and accepts an edit only when its wins are statistically reliable, covered in its own post.[43] Another is letting the evaluation criteria evolve too. RuHarness evolves the scoring rubric alongside the harness so the critic does not fall behind the agent,[44] and Predict Before You Modify adds a model on top of Hyperagents that predicts a change’s effect before evaluation, beating Hyperagents in all four domains.[45] The third is treating versions and rollback as infrastructure: keep old versions, measure verifier strength, and decide whether a human must sign off based on how recoverable a change is.[42]

My view is that self-evolution is not a new learning algorithm. It is continuous integration applied to agents: proposing a change is cheap, and the tests before merge decide where the system goes. With good tests, DGM can more than double its SWE-bench score in two weeks. With bad tests, the same loop deletes your safety rules and reports that everything is fine.

References

  1. Gao et al., A Survey of Self-Evolving Agents: What, When, How, and Where to Evolve on the Path to Artificial Super Intelligence, arXiv:2507.21046: https://arxiv.org/abs/2507.21046 ↩
  2. Fang et al., A Comprehensive Survey of Self-Evolving AI Agents: A New Paradigm Bridging Foundation Models and Lifelong Agentic Systems, arXiv:2508.07407: https://arxiv.org/abs/2508.07407 ↩
  3. Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, arXiv:2303.11366: https://arxiv.org/abs/2303.11366 ↩
  4. Madaan et al., Self-Refine: Iterative Refinement with Self-Feedback, arXiv:2303.17651: https://arxiv.org/abs/2303.17651 ↩
  5. Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet, arXiv:2310.01798: https://arxiv.org/abs/2310.01798 ↩
  6. Zelikman et al., STaR: Bootstrapping Reasoning With Reasoning, arXiv:2203.14465: https://arxiv.org/abs/2203.14465 ↩
  7. Yuan et al., Self-Rewarding Language Models, arXiv:2401.10020: https://arxiv.org/abs/2401.10020 ↩
  8. Zhao et al., Absolute Zero: Reinforced Self-play Reasoning with Zero Data, arXiv:2505.03335: https://arxiv.org/abs/2505.03335 ↩
  9. Zweiger et al., Self-Adapting Language Models (SEAL), arXiv:2506.10943: https://arxiv.org/abs/2506.10943 ↩
  10. Zhai et al., AgentEvolver: Towards Efficient Self-Evolving Agent System, arXiv:2511.10395: https://arxiv.org/abs/2511.10395 ↩
  11. Fernando et al., Promptbreeder: Self-Referential Self-Improvement Via Prompt Evolution, arXiv:2309.16797: https://arxiv.org/abs/2309.16797 ↩
  12. Agrawal et al., GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning, arXiv:2507.19457: https://arxiv.org/abs/2507.19457 ↩
  13. Zhang et al., Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models, arXiv:2510.04618: https://arxiv.org/abs/2510.04618 ↩
  14. Zhao et al., ExpeL: LLM Agents Are Experiential Learners, arXiv:2308.10144: https://arxiv.org/abs/2308.10144 ↩
  15. Chhikara et al., Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory, arXiv:2504.19413: https://arxiv.org/abs/2504.19413 ↩
  16. Xu et al., A-MEM: Agentic Memory for LLM Agents, arXiv:2502.12110: https://arxiv.org/abs/2502.12110 ↩
  17. Wang et al., Voyager: An Open-Ended Embodied Agent with Large Language Models, arXiv:2305.16291: https://arxiv.org/abs/2305.16291 ↩
  18. NousResearch/hermes-agent, README: https://github.com/NousResearch/hermes-agent ↩
  19. r/LocalLLaMA, AMA with Nous Research (2026-04-29): https://www.reddit.com/r/LocalLLaMA/comments/1sz2y76/ama_with_nous_research_ask_us_anything/; Q&A summary: https://www.reddit.com/r/hermesagent/comments/1szctp1/ama_summary_from_rlocalllama_42926/ ↩
  20. Hu, Lu, Clune, Automated Design of Agentic Systems, arXiv:2408.08435: https://arxiv.org/abs/2408.08435 ↩
  21. Zhang et al., AFlow: Automating Agentic Workflow Generation, arXiv:2410.10762: https://arxiv.org/abs/2410.10762 ↩
  22. Lee et al., Meta-Harness: End-to-End Optimization of Model Harnesses, arXiv:2603.28052: https://arxiv.org/abs/2603.28052 ↩
  23. Yin et al., Gödel Agent: A Self-Referential Agent Framework for Recursive Self-Improvement, arXiv:2410.04444: https://arxiv.org/abs/2410.04444 ↩
  24. Robeyns et al., A Self-Improving Coding Agent, arXiv:2504.15228: https://arxiv.org/abs/2504.15228 ↩
  25. Zhang et al., Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents, arXiv:2505.22954 (v3, cost estimate in Appendix E.1): https://arxiv.org/abs/2505.22954 ↩
  26. Sakana AI, The Darwin Gödel Machine: AI that improves itself by rewriting its own code (2025-05-30): https://sakana.ai/dgm/ ↩
  27. Wang et al., Huxley-Gödel Machine, arXiv:2510.21614: https://arxiv.org/abs/2510.21614 ↩
  28. Zhang et al., Hyperagents, arXiv:2603.19461: https://arxiv.org/abs/2603.19461; Meta AI research page: https://ai.meta.com/research/publications/hyperagents/ ↩
  29. Novikov et al., AlphaEvolve: A coding agent for scientific and algorithmic discovery, arXiv:2506.13131: https://arxiv.org/abs/2506.13131 ↩
  30. Google DeepMind, AlphaEvolve: A Gemini-powered coding agent for designing advanced algorithms (2025-05-14): https://deepmind.google/discover/blog/alphaevolve-a-gemini-powered-coding-agent-for-designing-advanced-algorithms/ ↩
  31. Google, AlphaEvolve, 1 year later (2026-05-07): https://blog.google/innovation-and-ai/infrastructure-and-cloud/google-cloud/alphaevolve-updates/ ↩
  32. Ban et al., Artifact-to-Capability: Diagnosing Breaks in Capability Formation of Self-Evolving Agents in a Controlled Environment, arXiv:2611.04952: https://arxiv.org/abs/2611.04952 ↩
  33. Lin et al., Beyond Endpoint Performance: Process-Level Evaluation of Self-Evolving Agents (EvoPathBench), arXiv:2609.24663: https://arxiv.org/abs/2609.24663 ↩
  34. Zhao et al., Self-Evolving Agents Can Repair Failures but Struggle to Generalize from Them, arXiv:2610.22984: https://arxiv.org/abs/2610.22984 ↩
  35. Mitra et al., Agent Self-Improvement with Frozen Weights: The Added Value and Limits of Failure Traces, arXiv:2611.11342: https://arxiv.org/abs/2611.11342 ↩
  36. Treude, Baltes, How Do Coding-Agent Harnesses Self-Evolve? An Empirical Study of Retrospective Adaptation, arXiv:2610.34938: https://arxiv.org/abs/2610.34938 ↩
  37. Guo et al., Self-Authored Verification Is Unreliable in Heuristic Self-Improving Agents, arXiv:2607.24300: https://arxiv.org/abs/2607.24300 ↩
  38. So et al., Masked Erosion: How Acceptance Gates Lose Redundant Safeguards in Self-Improving Agents, arXiv:2610.38392: https://arxiv.org/abs/2610.38392 ↩
  39. Chen et al., Are Self-Evolving Agents Continual Learners?, arXiv:2610.25858: https://arxiv.org/abs/2610.25858 ↩
  40. Shao et al., Your Agent May Misevolve: Emergent Risks in Self-evolving LLM Agents, arXiv:2509.26354: https://arxiv.org/abs/2509.26354 ↩
  41. Lin et al., When Experience Becomes a Backdoor: Poisoning Self-Evolving LLM Agents via Failure-Aware Task Optimization (BadEvolve), arXiv:2611.10542: https://arxiv.org/abs/2611.10542 ↩
  42. Wang, Qi, Recoverability and Verifier Strength: Two Measured Preconditions for Unattended Agent Self-Improvement, arXiv:2610.27465: https://arxiv.org/abs/2610.27465 ↩
  43. Wang et al., SAGE: A Statistical Acceptance Gate for Self-Evolving Agents, arXiv:2609.36043: https://arxiv.org/abs/2609.36043 ↩
  44. Chen et al., When the Critic Falls Behind: Co-Evolving Rubrics and Harnesses for Continual Agent Self-Improvement (RuHarness), arXiv:2610.36826: https://arxiv.org/abs/2610.36826 ↩
  45. Xie et al., Predict Before You Modify: Learning Improvement Dynamics for Self-Evolving Agents, arXiv:2610.13991: https://arxiv.org/abs/2610.13991 ↩
  46. X @minhnguyen (2026-03-24): https://x.com/minhnguyen/status/2036166065567215857 ↩
  47. X @ellen_in_sf (2026-03-31): https://x.com/ellen_in_sf/status/2038664437402583171 ↩
  48. r/ClaudeAI, I gave Claude its own computer and let it run 24/7: https://www.reddit.com/r/ClaudeAI/comments/1s84l18/i_gave_claude_its_own_computer_and_let_it_run_247/ ↩
  49. Suzgun et al., Dynamic Cheatsheet: Test-Time Learning with Adaptive Memory, arXiv:2504.07952: https://arxiv.org/abs/2504.07952 ↩
  50. X @jeevanpillay (2026-10-28): https://x.com/jeevanpillay/status/2115334014030774361 ↩
  51. Li et al., EvoRec: A Unified Self-Evolving Agentic Recommender with Dynamic Reflection Trees, arXiv:2611.01977: https://arxiv.org/abs/2611.01977 ↩
  52. Gong et al., TinyAstral: Transferring Self-Evolving Harnesses to Tiny Generalist Manipulation Agents, arXiv:2610.41216: https://arxiv.org/abs/2610.41216 ↩
  53. Jang et al., MEMIG: Self-evolving Memory Construction for Antibody Optimization, arXiv:2610.41245: https://arxiv.org/abs/2610.41245 ↩