This blog post gives a focused background on the modern line of self-improving agent research that starts from the Darwin Gödel Machine and then moves through two direct advances: HyperAgents and Group-Evolving Agents.

  1. Darwin Gödel Machine (DGM) shows that a coding agent can improve its own tools, prompts, and workflows through empirical self-modification plus open-ended archive search.
  2. HyperAgents generalizes the DGM idea by making the meta-level improvement procedure itself editable, allowing the system to improve how it generates future improvements and to transfer those meta-level skills beyond coding.
  3. Group-Evolving Agents (GEA) changes the evolutionary unit from an individual agent to a group of agents, so discoveries from different branches can be explicitly shared and consolidated.

These systems are not yet self-improving in the fully general science-fiction sense. They do not rewrite their foundation model weights in the reported experiments. They mostly improve the surrounding agent scaffold: code-editing tools, prompts, retry policies, context management, planning logic, memory, performance tracking, and search procedures.

Primary papers:

1. What Counts as a Self-Improving Agent?

The phrase “self-improving agent” can mean several different things. At the strongest end, it could mean an AI system that changes its own learning algorithm, training data, architecture, weights, goals, and deployment environment in pursuit of greater capability. None of the three milestone papers reaches that level. The papers are more careful and more useful than that: they study systems that can modify their own agent implementation and then empirically test whether the modification helped.

In these papers, an agent is not just a model. It is a program that wraps a model with tools, prompts, memory, workflow logic, evaluation harnesses, and sometimes a meta-agent that proposes changes. A coding agent, for example, may include:

  • a base foundation model,
  • a system prompt,
  • a bash tool,
  • a file-viewing/editing tool,
  • patch validation logic,
  • retry policies,
  • context-window summarization,
  • multiple-solution generation and ranking,
  • evaluation logs,
  • parent selection or archive management logic.

The self-improvement loop in this lineage generally has four phases:

  1. Select a parent agent or group from an archive.
  2. Generate a modification to the agent’s own code, prompts, tools, or workflow.
  3. Evaluate the child agent on a benchmark or task suite.
  4. Keep the useful child so it can become a future stepping stone.

This is best understood as black-box search over agent designs, not gradient descent over model weights. There is no differentiable objective over the scaffold. A model proposes discrete engineering changes; the system tests them; the archive preserves candidates that remain functional and useful. The interesting question is whether this search can compound: can improvements to the agent make it better at producing later improvements?

2. Darwin Gödel Machine - ICLR 2026

2.1 Problem the Paper Solves

DGM starts from a concrete limitation in current AI development: even strong agent systems are mostly human-designed. People decide the tools, prompts, workflows, memory, retry logic, and evaluation procedures. The model may write code, but the surrounding system is usually static.

The paper asks whether an AI coding agent can improve its own implementation. The key move is to make self-improvement itself a coding task. The agent is given its own repository, evaluation logs, and a problem statement describing the proposed improvement. It edits its own codebase, producing a child agent. That child is then evaluated on coding benchmarks.

This setup deliberately uses coding as the first domain because the proxy assumption is plausible there: if an agent becomes better at coding tasks, it may also become better at editing its own coding-agent code. That is not guaranteed, but the authors make the setting concrete enough to test.

2.2 Method and Self-Improvement Loop

DGM begins with a simple coding agent. The initial agent uses a frozen foundation model plus two tools: a bash tool and an edit tool. It receives the target repository, the problem statement, and the test framework. Its self-modifications can change prompts, tools, and workflow code, but not the underlying foundation model weights.

The DGM loop is:

  1. Maintain an archive of discovered agents.
  2. Select a parent from the archive using a probability that favors high scores but penalizes already-explored branches. The score definition: benchmark performance alpha_i (normalized 0-1, from the evaluation harness) is transformed into s_i = 1 / (1 + exp(-lambda(alpha_i - alpha_0))), with lambda = 10 and alpha_0 = 0.5. This is multiplied by h_i = 1 / (1 + n_i), where n_i is the number of functioning direct children, giving w_i = s_i h_i; normalized weights form the sampling distribution.
  3. Ask the selected parent to analyze benchmark logs and propose a next improvement. This diagnosis is done by prompting a separate foundation model, OpenAI o1, with the selected agent’s evaluation logs.
  4. Give that improvement back as a coding task so the agent edits its own repository. This is also prompt-mediated, but it is no longer a free-form reflection step. DGM extracts fields such as implementation_suggestion and problem_description from the diagnostic model output and passes them to the selected coding agent as the problem statement for a self-modification task.
  5. Evaluate the resulting child agent on staged benchmark tasks. Staged evaluation is not itself a proof of generalization. It is a cost filter: weak or broken children are screened on small subsets, and promising children receive larger evaluations. Generalization is tested separately by re-evaluating top agents on larger or held-out benchmark sets and by transfer experiments across models, benchmarks, and tasks.
  6. Add the child to the archive if it compiles and preserves basic code-editing functionality.

DGM Figure 1. The DGM interleaves self-modification with downstream task evaluation and stores discovered agents in an archive for open-ended parent selection.

The archive is the “Darwin” part. DGM does not simply keep the latest version or the current best version. It preserves older variants because they may become stepping stones. The archive forms a tree, and the path to the final best agent passes through temporary performance dips. That figure supports a stronger claim than “the final score went up.” It shows why open-ended search matters: some useful innovations are only reachable by traversing agents that do not look best at the moment they are created.

The archive increases the number of possible parents, but DGM does not evaluate every parent-child possibility. At each iteration it samples only a small number of parents from the archive: k = 2 in the SWE-bench experiments and k = 4 in the Polyglot experiments. That means archive size mainly increases the choice set and bookkeeping cost, while the dominant cost remains generating and evaluating each new child agent. The paper balances the trade-off with three design choices: probabilistic parent selection instead of exhaustive branching, down-weighting already-explored parents, and staged evaluation so that expensive larger evaluations are reserved for promising children. The authors also acknowledge that the outer archive/search process itself remains fixed, partly because making that layer self-modifying would make the search space much larger and harder to budget. This is the main motivation for the follow-up Hyper-Agents paper.

DGM Figure 3. The archive/progress visualization shows that the final best SWE-bench lineage passes through lower-performing intermediate nodes, supporting the stepping-stone argument.

2.3 Experimental Setup

DGM evaluates on two coding benchmarks:

  • SWE-bench Verified, a human-filtered subset of SWE-bench where tasks are confirmed solvable. This tests repository-level Python bug fixing and multi-file reasoning.
  • Polyglot, a multi-language coding benchmark. The paper uses pass@1, so the agent does not inspect ground-truth test feedback.

The authors run DGM for 80 child-generation iterations, with one new agent generated per iteration. Starting from one initial agent, this means there can be up to 81 nodes in the retained archive if every child remains functional and is retained, although invalid children are discarded and therefore do not become future parents. The paper also notes that two iterations run in parallel for SWE-bench and four for Polyglot, so the wall-clock process can grow several branches at once while preserving the same basic archive logic. Self-modification uses Claude 3.5 Sonnet. Evaluation uses Claude 3.5 Sonnet on SWE-bench and o3-mini on Polyglot. Because full benchmark evaluation is expensive, the paper uses staged evaluation: small subsets first, then larger evaluations for promising agents.

2.4 Main Experiment

Figure 2 shows the raw capability gain: after 80 iterations, DGM improves from 20.0% to 50.0% on SWE-bench and from 14.0% to 38.0% on the Polyglot evaluation subset. The authors then re-evaluate the base agent and best DGM-discovered agent on the full Polyglot benchmark, where performance improves from 14.2% to 30.7%. The comparison with ablations asks whether the gain comes from the two defining ingredients, iterative self-improvement and open-ended archive exploration, rather than merely from spending more attempts on agent design.

DGM Figure 2. DGM improves on SWE-bench and Polyglot and is compared with ablations and representative human-designed/open-source coding agents.

The ablations are the key causal evidence. Appendix Table 1 compares DGM with variants:

Method SWE-bench Polyglot
DGM 50.0% 38.0%
DGM without open-ended exploration 23.0% 14.0%
DGM without self-improve 39.0% 28.0%
DGM Greedy 39.7% 30.0%

DGM without self-improve freezes the meta-level modifier: the agentic machinery that inspects logs, receives the proposed improvement, and edits the next child repository. The modifier can still change prompts, tools, retry logic, validation, summarization, and other scaffold code, but it stays at the initial base-agent implementation instead of inheriting improvements across generations. This tests whether the modifier itself needs to self-improve.

DGM without open-ended exploration removes the archive. Instead of sampling from a tree of past agents, it repeatedly modifies the latest functional version, falling back only if the newest child loses basic code-editing ability. This tests whether branching and returning to older stepping stones matters.

DGM Greedy keeps the archive but always selects the current best-performing agent as the parent. Its weaker result shows that even with an archive, greedily exploiting the top score is worse than preserving a broader set of possible stepping stones.

DGM appendix ablation figures. The ablation plots show the failure modes when the meta-agent is frozen or the archive is removed.

This supports two claims. First, self-improvement matters: freezing the meta-level improvement agent reduces final performance. Second, open-endedness matters: removing the archive or greedily selecting only the current best agent performs worse than preserving multiple lineages.

2.5 What the System Actually Learned

The most interesting evidence is qualitative. DGM did not merely discover “better prompt vibes.” Figure 3 and the appendices show concrete tool and workflow improvements:

  • line-range file viewing,
  • precise string replacement instead of full-file overwrite,
  • rejection of empty or test-only patches,
  • retry loops after invalid patches,
  • automatic summarization when context is full,
  • multiple candidate patch generation,
  • ranking or peer review of candidate patches,
  • history-aware retries that use previous attempt outcomes.

The appendix includes patch traces for the best SWE-bench and Polyglot agents. A particularly useful analysis appears in Appendix G: two nodes both tried to improve fine-grained editing, but one implementation reached only 23.3% while another reached 40.5%. This supports the archive argument at a finer grain. It is not enough to have the right high-level idea; the implementation of that idea matters, and open-ended search can preserve alternative implementations long enough to find the better one.

2.6 Transfer Evidence

DGM includes several transfer tests in Figure 4 and an appendix figure. These are important because self-improving systems can accidentally overfit to a benchmark or a model. The transfer setup separates the agent scaffold from the foundation model used inside it. The base agent is the initial simple scaffold with bash and edit tools. The best agent is the scaffold discovered by DGM during the original search. For model transfer, the authors keep that discovered scaffold but swap the foundation model used at evaluation time. On SWE-bench, the best scaffold was discovered in a run using Claude 3.5 Sonnet (New), then evaluated with other models such as o3-mini and Claude 3.7 Sonnet. On Polyglot, the DGM run used o3-mini for benchmark evaluation, and the discovered scaffold was then evaluated with Claude 3.5 Sonnet (New) and Claude 3.7 Sonnet. The fair comparison is always “base scaffold plus the transferred model” versus “DGM-discovered scaffold plus the same transferred model.”

On SWE-bench model transfer, the best DGM-discovered agent improves over the base scaffold when evaluated with different models:

  • o3-mini: 23.0% to 33.0%,
  • Claude 3.7 Sonnet: 19.0% to 59.5%.

On Polyglot model transfer:

  • Claude 3.5 Sonnet (New): 32.0% to 33.3%,
  • Claude 3.7 Sonnet: 35.6% to 36.8%.

The cross-benchmark transfer result is also notable. The best agent evolved on SWE-bench reaches 28.9% on Polyglot versus the initial agent’s 14.2%. Conversely, the best agent evolved on Polyglot reaches 24.5% on SWE-bench versus the initial 20.0%. These results support the claim that the discovered improvements often operate at the scaffold level rather than being pure benchmark hacks.

DGM Figure 4 and the appendix Polyglot model-transfer figure. These transfer figures test whether the DGM-discovered scaffold changes survive model swaps and benchmark/task shifts.

2.7 Limitations and Safety

DGM is expensive. Appendix E.1 estimates one SWE-bench DGM run at about USD 22,000, versus about USD 10,000 for each main baseline, and the conclusion says the reported SWE-bench run takes about two weeks. This cost shapes the method: because evaluation is expensive, the system uses staged evaluation and cannot explore arbitrarily.

The system is also only partially self-referential. It edits the coding agent, but the outer archive maintenance and parent selection logic remain fixed. This limitation becomes one of the motivations for HyperAgents and HGM.

The paper’s safety discussion is unusually central. The authors identify risks from benchmark-only optimization, misaligned or unsafe behavior, increasing complexity, and reduced human oversight. Their mitigations are practical: isolated sandboxes, time/resource limits, limited network access, traceable archives, and no deployment of discovered agents in real development environments. These are not final safety solutions, but they are appropriate for the reported research setting.

3. HyperAgents

3.1 Problem the Paper Solves

HyperAgents begins with a criticism of DGM. DGM is powerful in coding because task performance and self-modification ability are aligned: both require coding. But outside coding, that alignment breaks.

Consider paper review or robotics reward design. Being better at paper review does not automatically make an agent better at modifying the code that generates future paper-review agents. A fixed instruction-generation mechanism designed for coding may fail badly. If every new domain requires humans to customize the meta-agent, then self-improvement is still bottlenecked by human engineering.

The HyperAgents paper therefore asks: can the meta-level improvement process itself become editable?

3.2 Method and Self-Improvement Loop

The paper defines a hyperagent as a single editable program that contains:

  • a task agent, which solves downstream tasks,
  • a meta agent, which modifies the task agent and/or itself.

The instantiated system, DGM-H, keeps DGM’s archive-based open-ended exploration, but expands what can be modified. In DGM, the task-solving agent can change, but the instruction-generation mechanism is mostly fixed. In DGM-H, the meta agent lives inside the same editable codebase. That makes metacognitive self-modification possible: the agent can improve how it analyzes failures, stores lessons, tracks performance, and decides what changes to try next.

The main loop is DGM-like, but it branches full hyperagents rather than coding agents. In pseudocode: evaluate the initial hyperagent, initialize an archive, sample parents, let each parent self-modify using archive evidence, evaluate the child, and add valid children back to the archive. The released implementation follows this structure in generate_loop.py.

The practical process flow is:

  1. Initialize a simple hyperagent with task_agent.py, meta_agent.py, bash/edit tools, domain harnesses, and a self-improvement README.
  2. Evaluate it on the target domains.
  3. Select a parent probabilistically, favoring high scores while discounting agents that already produced many compiled children.
  4. Reconstruct that parent in a fresh container by applying its lineage patches.
  5. Expose archive evidence: prior outputs, evaluations, logs, patches, and metadata.
  6. Self-modify: the meta agent edits any repository component, including the task agent, meta agent, prompts, parsing, memory, tools, or domain knowledge.
  7. Validate, evaluate, archive, repeat: compile-check the child, run staged evaluation, save successful patches and scores, then select the next parent.

Compared with DGM, HyperAgents keeps the same archive-search skeleton but changes what is inside each archive node. DGM evolves a coding agent, and its improvement proposal mechanism is largely a fixed, handcrafted diagnostic prompt. HyperAgents evolves a task-plus-meta hyperagent: the task agent solves the benchmark task, while the meta agent can edit the task agent, edit itself, and add new support machinery such as memory, performance tracking, domain notes, parsing rules, and evaluation-analysis utilities. This matters most outside coding. In DGM, coding performance and self-modification ability are naturally aligned because both require editing code. In HyperAgents, the task may be paper review or robotics reward design, so the system needs an explicit editable meta process that can learn how to generate better future agents even when task performance itself is not a coding skill. Parent selection, lineage reconstruction, validation, empirical evaluation, and archiving remain mostly DGM-style; the key novelty is that the improvement machinery becomes part of the evolved object.

HyperAgents Figure 1. DGM-H keeps DGM’s archive loop but places both the task agent and meta agent inside one editable hyperagent, allowing metacognitive self-modification.

The outer parent selection and evaluation process remain handcrafted in the main experiments. The appendix includes a preliminary modifiable-parent-selection experiment, but that is not the core result.

3.3 Experimental Setup

HyperAgents evaluates DGM-H across four domains:

  • Polyglot coding, for direct comparison to DGM.
  • Paper review, where the agent predicts accept/reject decisions from full paper text.
  • Robotics reward design, where the agent writes reward functions for simulated quadruped tasks.
  • Olympiad-level math grading, held out to test transfer and compounding of meta-level skill.

Paper review dataset and evaluation. The paper review domain is a simulated conference-review task drawn from the APReS-style dataset cited as zhao2026apres. Each task contains the full text of an AI research paper, and the task agent must output a binary accept or reject decision. The label is the observed real-world acceptance outcome from recent top-tier ML conferences, including ICLR 2024/2025 and NeurIPS 2023/2024. Performance is ordinary classification accuracy against these observed outcomes. The paper randomly samples 100 training, 100 validation, and 100 test tasks. During self-improvement, an agent is first evaluated on 10 training papers; if it gets at least one correct, it is evaluated on the full 100-paper training set. Because paper review is subjective and easy to overfit, parent selection uses validation performance when available, and the final numbers in Figure 2 are reported on the held-out test set. The important caveat is that this is not an objective measure of paper quality. It measures agreement with historical human conference decisions, which can encode noise, reviewer variance, venue norms, and bias.

Robotics reward design dataset and evaluation. The robotics domain uses the Genesis simulator with a Go2 quadruped robot. Each task gives the agent a natural-language robot-control objective, and the agent must output a Python reward function. That reward function is then used to train a robot policy with reinforcement learning, specifically PPO, and the trained policy is evaluated in simulation. The score is therefore behavioral: did the reward function induce a policy that actually performs the desired behavior? The table’s 6 training and 6 test entries should be read as repeated evaluations rather than six unrelated task datasets. During training, the agent designs rewards for forward walking while tracking a target velocity; performance is based on the mismatch between commanded and actual velocity. Each agent is first evaluated across 3 repeated reward-generation/training runs, and if at least one generated reward produces a non-zero score, it receives 3 additional repetitions. The final training score is the average across 6 evaluations. There is no separate validation set, so parent selection uses training performance. The held-out test task changes the objective: the agent must zero-shot write a reward function that makes the robot maximize torso height. A naive reward that directly rewards torso height makes the robot stand tall rather than jump, so this test checks whether the learned reward-design agent can avoid that local optimum and induce a more useful jumping behavior.

Domain Self-modification model Evaluation model
Polyglot Claude 3.5 Sonnet (New) o3-mini
Paper review Claude 4.5 Sonnet GPT-4o
Robotics reward design Claude 4.5 Sonnet Claude 4.5 Sonnet
IMO-level grading Claude 4.5 Sonnet o4-mini

HyperAgents appendix model-configuration table.

Method Self-improving meta agents Open-ended exploration Metacognitive self-modification (hyperagents)
DGM-H Yes Yes Yes
DGM-H without self-improve No Yes Yes
DGM-H without open-ended exploration Yes No Yes
DGM Yes Yes No
DGM-custom Yes Yes No

HyperAgents appendix method-comparison table. This table separates three ingredients that are easy to blur together: self-improving meta agents, archive-based open-ended exploration, and hyperagent-style editable meta machinery.

3.4 Main Experiment: Task Improvement

On Polyglot, DGM-H uses the same settings as DGM for a direct comparison. Across five runs, DGM-H improves from 0.140 to 0.340 on the 50-task Polyglot training subset. On the full Polyglot benchmark, it improves from 0.084 to 0.267. The original DGM reported 0.140 to 0.380 on the training subset and 0.142 to 0.307 on the full benchmark. The correct interpretation is subtle: DGM-H is comparable to DGM in coding, but not better. Its contribution is broader generality, not superior coding numbers.

The non-coding results are where HyperAgents becomes compelling. In main Figure 2, the initial agent scores 0.0 on paper review and 0.060 on robotics reward design. DGM-H improves to:

  • 0.710 on paper review, with confidence interval 0.590-0.750,
  • 0.372 on robotics reward design, with confidence interval 0.355-0.436.

HyperAgents Figure 2. DGM-H improves across paper review and robotics reward design and outperforms baselines without metacognition, without self-improvement, or without open-ended exploration.

These results exceed the cited open-source static baseline on paper review (0.630) and the default reward baseline on robotics reward design (0.348).

The original coding-oriented DGM, when applied without customization, scores 0.0 on both non-coding test domains. A manually customized DGM baseline performs much better: 0.590 on paper review and 0.348 on robotics. This comparison supports the paper’s central claim: vanilla DGM is not generally transferable outside coding unless humans redesign its improvement mechanism, while DGM-H can learn more of that mechanism itself.

3.5 Experiment on Transferability

The most distinctive HyperAgents result is not ordinary task performance. It is meta-level transfer.

The paper introduces improvement@k, specifically imp@50, to measure whether a fixed meta agent can generate improved task agents within 50 iterations. This is a clean metric because it holds the meta agent fixed during the transfer test. If the transferred meta agent can improve a new task agent, then something about the improvement process transferred.

Main Figure 3 evaluates transfer to Olympiad-level math grading. The initial meta agent has essentially no improvement ability: imp@50 is 0.0 under both DGM without self-improvement and DGM-H without self-improvement. Transfer agents from DGM-custom also fail to transfer meaningfully: imp@50 remains near 0.0.

Transfer hyperagents from previous DGM-H runs are different. Starting from transfer hyperagents and using DGM-H without self-improvement, the system reaches a best generated-agent score of 0.630 on Olympiad-level math grading, corresponding to imp@50 = 0.630 with confidence interval 0.540-0.630. This is the strongest evidence that DGM-H learned general meta-level improvement machinery rather than only domain-specific task tricks.

HyperAgents Figure 3. Transfer hyperagents from prior DGM-H runs retain a strong ability to generate improved agents on a held-out Olympiad-level math grading domain, while initial/DGM-custom meta agents do not.

3.6 What the System Actually Learned

HyperAgents is especially useful because the appendix shows qualitative mechanisms that emerged at both task and meta levels.

At the task level:

  • In paper review, the system shifts from vague persona instructions to explicit two-stage review procedures, checklists, and decision rules. The appendix qualitative figure visualizes this trajectory.
  • In robotics reward design, the system builds an internal knowledge base of valid environment variables, constraints, reward-shaping heuristics, and scaling guidance. The appendix qualitative figure supports this analysis.
  • In Olympiad grading, the system develops rubrics, calibration rules, and decision-tree-like grading processes. The appendix qualitative figure shows the progression.

HyperAgents Appendix qualitative figures. These figures show archive/progress plots for task-level self-improvement in paper review, robotics reward design, and Olympiad-level math grading.

At the meta level, the qualitative meta appendix is the key evidence. The hyperagent develops:

  • evaluation-analysis utilities,
  • compute-aware strategic planning,
  • bias detection and correction,
  • performance tracking infrastructure,
  • prompt template systems,
  • multi-generation refinement records,
  • persistent memory.

The persistent memory result is particularly relevant to SelfLearnAgent. The paper reports that the hyperagent stores not just raw logs, but synthesized insights, causal hypotheses, and future plans. That is a stronger form of memory than “retrieve similar old conversations.” It is memory as self-improvement infrastructure.

3.7 Limitations

HyperAgents supports three main claims:

  1. Making the meta agent editable enables self-improvement outside coding better than a fixed coding-oriented DGM mechanism.
  2. Some meta-level improvements transfer across domains, as shown by imp@50 on Olympiad-level math grading.
  3. Self-improvement infrastructure such as memory and performance tracking can emerge autonomously when the system is allowed to edit its own meta process.

The evidence does not prove unbounded self-improvement. The outer archive and evaluation mechanisms remain mostly fixed. The task distributions are fixed. The evaluations are still benchmark-defined and can encode bias. The paper’s own safety discussion emphasizes evaluation gaming and the possibility that the system amplifies undesirable patterns in human data.

HyperAgents appendix parent-selection figure. DGM-H can improve parent selection beyond random selection, but does not yet outperform the handcrafted score-child-prop mechanism. This is useful negative evidence about the current limits of fully editable outer-loop search.

4. Group-Evolving Agents

4.1 Problem the Paper Solves

DGM preserves multiple branches, but the branches mostly remain isolated. That means the archive can generate diversity without efficiently consolidating it. One lineage may discover a better edit tool. Another may discover better logging. Another may improve bash usage. If those discoveries cannot be merged, many useful innovations die inside separate branches.

GEA argues that tree-structured individual evolution borrows too much from biological evolution. Biological organisms cannot directly share internal experience with unrelated branches. AI agents can. They can share patches, logs, trajectories, predicted task patches, outcome records, and tool improvements. So the paper asks: why should AI agent evolution keep the individual agent as the fundamental unit?

4.2 Method and Self-Improvement Loop

GEA treats a group of agents as the evolutionary unit. Figure 1 contrasts tree-structured self-evolution with group evolution. In GEA, each iteration has two stages:

  1. Parent Group Selection: select a group of agents from the archive using a performance-novelty score.
  2. Open-Ended Group Evolution: aggregate experience from the parent group and let each agent evolve using the shared pool.

GEA Figure 1. GEA replaces individual-centric tree evolution with group-level evolution, where a selected parent group produces an offspring group through shared experience reuse.

The parent selection step represents each agent by a task-success vector over a fixed set of probe tasks. For agent i, the vector is z_i in {0,1}^D, where D is the number of probe tasks. Each entry is calculated from evaluation outcomes: z_i[d] = 1 if agent i successfully solves probe task d, and 0 otherwise. In SWE-bench, success means the task is resolved under the benchmark harness; in Polyglot, success means the generated solution passes the task tests. This vector is not model-generated; it is a binary record of which probe tasks the agent actually solved.

GEA uses these vectors to estimate novelty. For two agents, it computes cosine distance between their task-success vectors, then defines an agent’s novelty as the average distance to its M nearest neighbors. Agents are ranked by score(i) = alpha_i * sqrt(novelty(i)), where alpha_i is the downstream performance score. Performance is therefore the primary signal, while novelty acts as a mild diversity bias. This is summarized in Algorithm 1.

The group evolution step is the heart of the paper. For each parent agent, GEA collects:

  • framework patches,
  • predicted task patches on unsolved tasks,
  • execution logs and tool histories,
  • evaluation outcomes.

These traces are aggregated and shared with every member of the parent group. Each agent reflects over the shared experience, generates evolution directives, produces a framework-level patch, and is evaluated. Figure 2 shows this group-level experience flow.

GEA Figure 2. Aggregated evolutionary traces from the parent group are shared across all agents to generate evolution directives and framework-level patches.

In Figure 2, the modules are functional roles in the self-improvement loop. The reflection module is the diagnostic step: it reads the shared traces from the parent group, including applied framework patches, failed-task logs, predicted task patches, and evaluation outcomes, then proposes what should improve in the agent’s workflow, tools, or prompts. The evolving requirements are the concrete instructions produced by this reflection step. In the released prompts, they are packaged as an implementation_suggestion plus a GitHub-style problem_description: a task-agnostic requirement such as improving retry logic, adding a better edit tool, or changing how the agent summarizes long context.

The evolving module takes those requirements and edits the agent framework itself. This is the scaffold-modification step: it can change coding_agent.py, prompts, tools, or utilities, producing a framework-level patch rather than a benchmark-task patch. The acting module is the resulting coding agent used for downstream evaluation. It receives a SWE-bench or Polyglot task, uses its tools to generate a task solution, and the benchmark harness records whether that solution passes. Those acting results then become the next round’s traces and task-success vector.

In the released implementation, this becomes a concrete group-evolution loop in GEA_outer.py and self_improve_step.py:

  1. Initialize the archive. Start from initial or initial_polyglot, copy the initial agent logs and performance files, and seed the archive with that agent.
  2. Select a parent group. After generation 0, group mode selects K parents, usually with the performance-novelty score above. The released group experiments use K = 2.
  3. Choose each parent’s improvement target. For each selected parent, the loop chooses an unresolved task, or a generic failure mode such as empty patches, stochasticity, or context-length failures.
  4. Create paired group attempts. With two parents, the code creates (p1+p2, e1+e2) and (p2+p1, e2+e1). The first parent in each pair supplies the actual codebase to modify; the second parent supplies reference experience.
  5. Reconstruct the active parent. Inside a Docker container, GEA applies the active parent’s saved lineage patches to recreate that exact framework state.
  6. Build a shared diagnostic prompt. The diagnosis model sees the active parent’s failed-task trace plus the other parent’s logs, predicted patch, test patch, evaluation result, or generic failure-mode note.
  7. Turn diagnosis into an edit task. The JSON diagnosis is converted into a # To Implement problem statement, then the coding agent edits its own framework and emits model_patch.diff.
  8. Validate, evaluate, archive, repeat. Empty or missing patches are rejected. Valid children are evaluated on SWE-bench or Polyglot subsets, assigned new task-success vectors, and added back to the archive with their patches, logs, metadata, and scores.

This is not just multiple agents running in parallel. The point is that the agents explicitly learn from each other’s evolutionary traces.

4.3 Experimental Setup

GEA evaluates on the same broad coding-agent setting as DGM:

  • SWE-bench Verified, with staged evaluation: a 10-task sanity stage, a 50-task Verified-Mini stage, then full SWE-bench Verified evaluation for top agents.
  • Polyglot, with pass@1 performance and staged evaluation from a 10-task small set to an unseen 50-task medium set.

The paper uses group size K = 2. It compares GEA against a DGM-style open-ended self-evolving baseline in which individual lineages evolve without cross-branch experience sharing. It also compares final performance against state-of-the-art human-designed coding-agent frameworks.

4.4 Main Experiment

The headline result appears in the abstract, introduction, and Figure 3:

  • On SWE-bench Verified, GEA reaches 71.0%, versus 56.7% for the DGM-style self-evolving baseline.
  • On Polyglot, GEA reaches 88.3%, versus 68.3% for the baseline.

GEA Figure 3. These two panels compare GEA with the DGM-style self-evolving baseline on SWE-bench Verified and Polyglot under the same number of evolved agents.

Figure 3 is important because it compares performance under the same number of evolved agents. This matters: if GEA simply used more agents or more budget, the result would be less informative. The claim is that group-level evolution uses exploratory diversity more efficiently.

The comparison to human-designed frameworks is also striking:

  • SWE-bench Verified: 71.0% for GEA versus 71.8% for the state-of-the-art human-designed framework cited by the paper.
  • Polyglot: 88.3% for GEA versus 52.0% for the human-designed framework cited by the paper.

The right interpretation is not “GEA solves coding agents.” It is that autonomous scaffold evolution is becoming competitive with human-designed scaffolds on these benchmark settings, at least under the reported protocols.

4.5 Evolution Analysis

GEA’s most useful evidence is in Figure 4 and Table 1.

Figure 4 tracks nine key tool-level modifications across evolution. The authors report that GEA’s best agent integrates eight of the nine functionalities, while the best DGM-style baseline agent integrates only five. They also note that several tools missing from the DGM agent were discovered in isolated branches but failed to propagate. This directly supports the paper’s thesis: the issue is not only discovering useful innovations, but consolidating them.

GEA Figure 4. The figure tracks nine key tool-level functionalities across evolution, distinguishing discovered-but-not-integrated tools from tools integrated into the best-performing agent.

Table 1 quantifies ancestor integration and population quality on SWE-bench Verified:

Rank set DGM worst-case success GEA worst-case success DGM ancestor count GEA ancestor count
Top-1 56.7% 71.0% 9 (15.0%) 17 (28.3%)
Top-3 48.3% 63.3% 13 (21.7%) 17 (28.3%)
Top-5 45.0% 58.3% 16 (26.7%) 18 (30.0%)

The top-5 result is especially revealing: the worst of GEA’s top five agents (58.3%) exceeds the single best DGM baseline agent (56.7%). That means GEA is not merely producing one lucky outlier. It raises the quality of the population.

4.6 Transferability and Robustness

Figure 5 evaluates model transfer. The paper replaces the coding model used in the acting module with different GPT-series and Claude-series models and compares the initial agent with the GEA-discovered best agent. Across both SWE-bench and Polyglot, the best GEA agent outperforms the initial agent under the tested models. The authors argue this means the improvements are mainly workflow/tool improvements rather than brittle model-specific prompts.

GEA Figure 5. The best GEA-discovered agent transfers across GPT-series and Claude-series coding models on both SWE-bench and Polyglot.

The robustness experiment is in Table 2. The authors inject framework-level bugs and measure how many evolution iterations are needed to repair them:

Method E1 E2 E3 E4 E5 Average
DGM-style baseline 5 4 5 6 5 5.0
GEA 1 1 2 1 2 1.4

This is one of the cleanest demonstrations of the value of experience sharing. When a faulty agent evolves alone, it repairs slowly. When it can share a group with a better-functioning agent, useful framework-level experience guides repair.

5.7 Conclusion and Limitaions

GEA supports the claim that isolated lineages waste useful discoveries and that explicit experience sharing can consolidate them.

  • group-level evolution as a better unit than isolated individual evolution in the reported coding settings,
  • performance-novelty group selection as a practical way to preserve diversity,
  • shared evolutionary traces as useful memory,
  • workflow/tool improvements that transfer across model backbones,
  • faster recovery from framework-level damage.

The paper does not prove:

  • that group evolution scales safely to arbitrary domains,
  • that shared memory cannot propagate harmful or misleading innovations,
  • that the outer loop is fully self-improving,
  • that benchmark performance alone is a sufficient objective.

6. Appendix: DGM Self-Improvement Prompt

In the SWE-bench self-improvement loop, DGM first asks a diagnostic model to inspect the current coding agent, failed task logs, the GitHub issue, the predicted patch, the private test patch, and the evaluation result. The diagnostic model does not directly edit the agent. Instead, it returns structured JSON. DGM extracts the implementation_suggestion and problem_description fields and gives them to the selected coding agent as the next self-modification task.

The prompt below is reproduced from the DGM source file selfimprove_prompts/swebench.tex, lightly reformatted from LaTeX into Markdown.

# Coding Agent Summary

- **Main File**: `coding_agent.py`
  - Primary Class: `AgenticSystem`
  - The `forward()` function is the central entry point.
  - Prompts are located either within the `forward()` function or in the `prompts/` directory.
- **Tools**: `tools/`
  - The `tools/` directory contains various tools that LLMs can use to perform specific tasks.
  - Each tool must have a `tool_info()` function that returns a JSON object containing 'name', 'description', and 'input_schema'. The 'input_schema' should be a JSON object containing 'type', 'properties', and 'required'.
  - Each tool must have a `tool_function()` function that takes the arguments defined in input_schema, performs the tool's task, and returns a string.
  - See other tools for reference.
- **Utilities**: `utils/`
  - The `utils/` directory contains utility functions used across the codebase.

- **Additional Details**:
  - The agent is very good at automatically utilizing the right available tools at the right time. So do not have an agentic flow that explicitly forces a tool's usage.
  - Common tools, such as file editing and bash commands, are easy for the agent to recognize and use appropriately. However, more complex and niche tools may require explicit instructions in the prompt.
  - Tools should be designed to be as general as possible, ensuring they work across any GitHub repository. Avoid hardcoding repository-specific details or behaviors (e.g., paths).
  - Do not use 'while True' loops in the agent's code. This can cause the agent to get stuck and not respond.
  - Verify the implementation details of helper functions prior to usage to ensure proper integration and expected behavior.
  - Do not install additional packages or dependencies directly. Update `requirements.txt` if new dependencies are required and install them using `pip install -r requirements.txt`.

Here is the implementation of the coding agent.

# Coding Agent Implementation
----- Coding Agent Implementation Start -----
{code}
----- Coding Agent Implementation End -----

Your task is to identify ONE detailed plan that would improve the agent's coding ability. The improvement should not be specific to any particular GitHub issue or repository.

Here is the log for the coding agent trying to solve the GitHub issues but failed.

# Agent Running Log
----- Agent Running Log Start -----
{md_log}
----- Agent Running Log End -----

# GitHub Issue
The GitHub issue that the agent is trying to solve.
----- GitHub Issue Start -----
{github_issue}
----- GitHub Issue End -----

# Predicted Patch
The agent's predicted patch to solve the issue.
----- Predicted Patch Start -----
{predicted_patch}
----- Predicted Patch End -----

# Private Test Patch
SWE-bench's official private tests to detect whether the issue is solved. This is not available to the agent during evaluation. The agent should try to implement its own tests.
----- Private Test Patch Start -----
{test_patch}
----- Private Test Patch End -----

# Issue Test Results
The test results from SWE-bench using the above official private tests.
----- Issue Test Results Start -----
{eval_log}
----- Issue Test Results End -----

Respond precisely in the following format including the JSON start and end markers:

```json
<JSON>
```

In <JSON>, provide a JSON response with the following fields:
- "log_summarization": Analyze the above logs and summarize how the agent tried to solve the GitHub issue. Note which tools and how they are used, the agent's problem-solving approach, and any issues encountered.
- "potential_improvements": Identify potential improvements to the coding agent that could enhance its coding capabilities. Focus on the agent's general coding abilities (e.g., better or new tools usable across any repository) rather than issue-specific fixes (e.g., tools only usable in one framework). All necessary dependencies and environment setup have already been handled, so do not focus on these aspects.
- "improvement_proposal": Choose ONE high-impact improvement from the identified potential improvements and describe it in detail. This should be a focused and comprehensive plan to enhance the agent's overall coding ability.
- "implementation_suggestion": Referring to the coding agent's summary and implementation, think critically about what feature or tool could be added or improved to best implement the proposed improvement. If the proposed feature can be implemented by modifying the existing tools, describe the modifications needed, instead of suggesting a new tool.
- "problem_description": Phrase the improvement proposal and implementation suggestion as a GitHub issue description. It should clearly describe the feature so that a software engineer viewing the issue and the repository can implement it.

Your response will be automatically parsed, so ensure that the string response is precisely in the correct format. Do NOT include the `<JSON>` tag in your output.

After the diagnostic step, the selected coding agent receives the extracted problem_description as a normal repository-editing task. The initial agent’s task prompt is short:

I have uploaded a Python code repository in the directory {self.git_tempdir}. Help solve the following problem.

<problem_description>
{self.problem_statement}
</problem_description>

<test_description>
{self.test_description}
</test_description>

Your task is to make changes to the files in the {self.git_tempdir} directory to address the <problem_description>. I have already taken care of the required dependencies.

This division is important. The first prompt is a diagnosis and proposal prompt: it decides what general agent improvement to attempt. The second prompt is an implementation prompt: it asks the selected coding agent to edit the agent repository. This is why DGM can be described as prompt-mediated self-improvement while still being an empirical code-modification system.

7. Appendix: HyperAgents System Prompts

In this implementation, the prompts are mostly system-like user-message prefixes, not separate API system role messages. The LLM wrapper in agent/llm.py appends each call as a user message, while agent/llm_withtools.py prepends the tool-use instructions to the user message before calling the model.

7.1 Shared Tool-Use Prompt

The shared tool-use prompt is defined in agent/llm_withtools.py. It is prepended whenever tools are available; the DGM-H meta agent calls chat_with_agent(..., tools_available='all'), so this wrapper is part of the meta-agent prompt.

Here are the available tools:
```
{tools_available}
```

Use only one tool (if needed) in this format:
<json>
{
    "tool_name": ...,
    "tool_input": ...
}
</json>

ONLY USE ONE TOOL PER RESPONSE, AND STRICTLY FOLLOW THE FORMAT OF TOOL_NAME AND TOOL_INPUT ABOVE.
DO NOT HALLUCINATE OR MAKE UP ANYTHING.

The {tools_available} field is filled from the loaded tool registry. In the released source, the basic built-in tools are bash and edit, so the wrapper is the mechanism that turns a normal language-model call into an edit-capable coding agent.

The initial bash tool description is reproduced in the paper source at initial_agent/bash_tool.tex and implemented in agent/tools/bash.py:

Run commands in a bash shell
* When invoking this tool, the contents of the "command" parameter does NOT need to be XML-escaped.
* You don't have access to the internet via this tool.
* You do have access to a mirror of common linux and python packages via apt and pip.
* State is persistent across command calls and discussions with the user.
* To inspect a particular line range of a file, e.g. lines 10-25, try 'sed -n 10,25p /path/to/the/file'.
* Please avoid commands that may produce a very large amount of output.
* Please run long lived commands in the background, e.g. 'sleep 10 &' or start a server in the background.

The initial editor tool description is reproduced in initial_agent/edit_tool.tex and implemented in agent/tools/edit.py:

Custom editing tool for viewing, creating and editing files
* State is persistent across command calls and discussions with the user
* If `path` is a file, `view` displays the result of applying `cat -n`. If `path` is a directory, `view` lists non-hidden files and directories up to 2 levels deep
* The `create` command cannot be used if the specified `path` already exists as a file
* If a `command` generates a long output, it will be truncated and marked with `<response clipped>`
* The `undo_edit` command will revert the last edit made to the file at `path`

Notes for using the `str_replace` command:
* The `old_str` parameter should match EXACTLY one or more consecutive lines from the original file. Be mindful of whitespaces!
* If the `old_str` parameter is not unique in the file, the replacement will not be performed. Make sure to include enough context in `old_str` to make it unique
* The `new_str` parameter should contain the edited lines that should replace the `old_str`

7.2 Task-Agent Prompt

The generic task agent prompt is defined in task_agent.py and reproduced in initial_agent/task_prompt.tex. It is intentionally broad: task-specific detail is injected through the serialized inputs dictionary.

You are an agent.

Task input:
```
{inputs}
```

Respond in JSON format with the following schema:
<json>
{
    "response": ...
}
</json>

The task agent’s response is parsed from the final JSON field named response. This makes the same task-agent scaffold usable across domains such as paper review, robotics reward design, search preference prediction, and proof grading, with the harness supplying the concrete task input.

7.3 Meta-Agent Prompt

The DGM-H meta agent prompt is defined in meta_agent.py and reproduced in initial_agent/meta_prompt.tex:

Modify any part of the codebase at `{repo_path}`.

This is much shorter than the DGM diagnostic prompt. The launcher passes an evaluation folder and the number of iterations left in run_meta_agent.py, but in the checked-in MetaAgent.forward() those values are not interpolated into the instruction string. Instead, the generated repository README tells the meta agent what kind of system it is editing, while the tool wrapper gives it the ability to inspect and modify the repository.

7.4 Repository-Level Self-Improvement Context

Each generated agent repository receives a README from utils/gl_utils.py. This is not sent directly as a model message, but it is persistent in the codebase the meta agent is asked to edit.

# Self-Improving AI

This system is designed to automatically produce agents for solving downstream tasks. The system iteratively improves the generated agents through code editing. To enable continuous improvement, the system should look at its code repository and the provided path to previously generated agents and their evaluation results, and then edit and enhance its own mechanisms for generating agents. This process creates a recursive loop of self-improvement.

When HyperAgents runs the ensemble or editable-parent-selection variants, the generated README can append additional instructions:

## Optimize the Ensemble of Agents

Given a fixed archive of agents, optimize the performance of the ensemble without modifying the individual agents. The archive of agents is provided in `/tmp/agent_archive/`. You can edit and improve the ensemble logic in `ensemble.py`.

## Parent Selection Mechanism

The parent selection mechanism should sample agents from the archive using a non-greedy, diversity-preserving strategy that allows weaker, novel, or niche agents to produce offspring. This enables the discovery of interesting stepping stones that can unlock larger future improvements. The goal is to maximize long-term innovation and avoid premature convergence, while still filtering out uninteresting or unproductive exploration paths to use compute efficiently. You can edit and improve the select parent logic in `select_next_parent.py`.

Note that:
- A node with no children does not mean that its path has not been explored. The node's lineage depth indicates the depth of exploration.

This README is part of why HyperAgents is not just “DGM with a shorter prompt.” The meta agent is operating inside a repository that describes its own recursive purpose, and the repository contents are themselves editable across generations.

8. Appendix: GEA Process and System Prompts

GEA inherits much of DGM’s prompt-mediated self-improvement structure, but adds a group-experience branch. The outer loop is in GEA_outer.py, the self-improvement worker is in self_improve_step.py, and the main prompt templates are in prompts/self_improvement_prompt.py.

8.1 Tool-Use Prompt

GEA uses a tool wrapper for models without native tool calling. The prompt is defined in prompts/tooluse_prompt.py, and {tools_available} is filled by reading the Python files in tools/.

Here are the available tools:
{tools_available}

Use the available tools in this format:
```
<tool_use>
{
    'tool_name': ...,
    'tool_input': ...
}
</tool_use>
```

This wrapper is simpler than HyperAgents’ JSON tool prompt. The important point is that the model sees the actual tool implementations, not just a short tool schema.

8.2 Diagnostic System Prompt

The diagnostic model receives a real system message containing the current coding-agent implementation. This is the reflection step that decides what general framework improvement should be attempted.

Here is the implementation of the coding agent.

# Coding Agent Implementation
----- Coding Agent Implementation Start -----
{code}
----- Coding Agent Implementation End -----

Your task is to identify ONE detailed plan that would improve the agent's coding ability. The improvement should not be specific to any particular GitHub issue or repository.

The standard SWE-bench diagnosis user prompt then supplies the failed run evidence:

# Agent Running Log
----- Agent Running Log Start -----
{md_log}
----- Agent Running Log End -----

# GitHub Issue
----- GitHub Issue Start -----
{github_issue}
----- GitHub Issue End -----

# Predicted Patch
----- Predicted Patch Start -----
{predicted_patch}
----- Predicted Patch End -----

# Private Test Patch
----- Private Test Patch Start -----
{test_patch}
----- Private Test Patch End -----

# Issue Test Results
----- Issue Test Results Start -----
{eval_log}
----- Issue Test Results End -----

The required JSON fields are log_summarization, potential_improvements, improvement_proposal, implementation_suggestion, and problem_description. This is almost the same DGM-style diagnosis format, but GEA can splice in another parent’s evidence before the final JSON instruction.

8.3 Group-Experience Prompt

The group-specific prompt is defined around prompts/self_improvement_prompt.py. For normal task failures, GEA appends a second parent trace using this framing:

Here is the log of another coding agent — not the current one — that attempted to solve the GitHub issues but failed. You can use it as a reference:

# Agent Running Log
----- Agent Running Log Start -----
{md_log}
----- Agent Running Log End -----

# GitHub Issue
----- GitHub Issue Start -----
{github_issue}
----- GitHub Issue End -----

# Predicted Patch
----- Predicted Patch Start -----
{predicted_patch}
----- Predicted Patch End -----

# Private Test Patch
----- Private Test Patch Start -----
{test_patch}
----- Private Test Patch End -----

# Issue Test Results
----- Issue Test Results Start -----
{eval_log}
----- Issue Test Results End -----

GEA also has shorter reference prompts for generic failure modes: one for empty or test-only patches, one for stochastic failures where a single attempt may not produce the right patch, and one for context-length failures. These are still group-sharing prompts: the current agent is asked to learn from another agent’s failure pattern, not only from its own failed task.

8.4 Self-Modification Prompt

After diagnosis, GEA converts the JSON into a repository-editing task with problem_description_prompt:

# To Implement

{implementation_suggestion}

{problem_description}

The coding agent then receives that task through coding_agent.py:

I have uploaded a Python code repository in the directory {self.git_tempdir}. Help solve the following problem.

<problem_description>
{self.problem_statement}
</problem_description>

<test_description>
{self.test_description}
</test_description>

Your task is to make changes to the files in the {self.git_tempdir} directory to address the <problem_description>. I have already taken care of the required dependencies.

For Polyglot, coding_agent_polyglot.py uses the same structure without the SWE-specific test description and adds a final instruction to analyze the problem carefully before editing.

8.5 Post-Improvement Diagnosis

GEA can optionally run a second diagnostic prompt after the child has been evaluated. This template is defined in prompts/diagnose_improvement_prompt.py. It compares before-and-after logs, predicted patches, test results, the framework patch, the official test patch, and the answer patch, then asks for JSON fields impact, improvements, regressions, and score.

This post-hoc diagnosis is not the main group-sharing mechanism. It is closer to an audit trail: it records whether the generated framework patch seems to have improved general coding behavior or introduced regressions.

9. Bottom Line

The modern DGM lineage makes self-improving agents feel less mystical and more like a new kind of empirical software engineering loop.

DGM shows the first key step: an agent can edit its own scaffold and become better through benchmark-tested archive search. HyperAgents shows the deeper step: the mechanism for producing improvements can itself become editable, and some meta-level skills can transfer across domains. GEA shows the collective step: self-improvement is stronger when agent variants share and consolidate experience instead of evolving in isolated branches.

The field is still young. These systems are expensive, benchmark-bound, scaffold-focused, and safety-sensitive. But the direction is clear. The strongest current self-improving agents are not autonomous model trainers. They are increasingly sophisticated systems for accumulating, testing, remembering, and recombining improvements to the agent program around a model. For a project like SelfLearnAgent, that is exactly the useful foundation: build the archive, evaluation, memory, and meta-learning substrate first; then let more ambitious forms of self-improvement grow on top of something auditable.