Hyperagents

59.1 Overview & Motivation

Every self-improving AI system surveyed in this book—from FunSearch to AlphaEvolve—shares a structural ceiling: the mechanism that drives improvement is itself fixed and handcrafted. An evolutionary loop can mutate candidate programs, but the mutation operator, the selection strategy, and the fitness function remain outside the mutable zone. This creates an infinite regress: if a meta-agent improves a task agent, who improves the meta-agent? Adding more meta-levels merely shifts the question upward without resolving it. [PAPER]

Hyperagents (Zhang et al., 2026) confronts this regress by collapsing the task agent and meta agent into a single editable program. Published on arXiv as paper 2603.19461 on March 19, 2026, the work extends the Darwin Gödel Machine (DGM; Zhang et al., 2025b, Sakana AI) from a coding-only self-improvement system to a domain-general framework in which the improvement procedure itself is subject to evolution. The authors term the resulting entity a DGM-Hyperagent (DGM-H). [PAPER]

The original DGM exploited a fortunate domain alignment: because both evaluation and self-modification are coding tasks, gains in coding ability translate directly into gains in self-improvement ability. For domains such as paper review, robotics reward design, or mathematical proof grading, no such alignment exists. DGM-H resolves this by making the self-modification instructions, selection strategy, memory infrastructure, and performance analysis code all part of the editable artifact. The system can therefore improve not only what it does (task-solving) but how it decides what to try next (meta-level strategy). [PAPER]

The collaboration spans six institutions across three countries: Meta FAIR, Meta Superintelligence Labs, University of British Columbia, Vector Institute, University of Edinburgh, and NYU. Lead author Jenny Zhang also led the original DGM paper; co-author Jeff Clune is among the most cited researchers in open-ended evolution and AI-generating algorithms. Code is released at github.com/facebookresearch/HyperAgents under CC BY 4.0. [PAPER]

59.2 Architecture

59.2.1 System Overview

The DGM-H architecture consists of four principal components: (1) a generate loop that orchestrates the iterative self-improvement cycle; (2) a meta agent that reads the current agent source and generates code diffs via an LLM; (3) a task agent that solves the target domain problem; and (4) an archive of agent variants that serves as both population and stepping-stone memory. All agent execution occurs inside a Docker sandbox with resource limits and restricted network access. [PAPER]

The decisive architectural property is self-reference: the meta agent and task agent are parts of a single Python program. The meta agent has read/write access to its own source code, enabling it to modify the task-solving logic, its own modification instructions, the selection strategy, and any self-built infrastructure. [PAPER]

59.2.2 Repository Structure

The released repository at github.com/facebookresearch/HyperAgents contains the following top-level layout [README]:

# README-documented repository structure (github.com/facebookresearch/HyperAgents)
HyperAgents/
├── agent/              # Foundation model interaction code
├── analysis/           # Plotting and analysis scripts
├── domains/            # Domain-specific code
│   ├── coding/         # Polyglot coding tasks
│   ├── paper_review/   # AI paper review
│   ├── robotics/       # Reward design
│   └── math/           # Olympiad math grading
├── utils/              # Common utilities
├── meta_agent.py       # Main meta agent implementation
├── task_agent.py       # Main task agent implementation
├── run_meta_agent.py   # Script to run meta agent and get diffs
├── generate_loop.py    # Entry point for running the algorithm
├── requirements.txt    # Python dependencies
├── requirements_dev.txt # Development dependencies
├── Dockerfile          # Container build
└── setup_initial.sh    # Initial agent setup

Key entry points: generate_loop.py is the main execution driver; meta_agent.py implements the self-modification engine; task_agent.py hosts the domain-specific solver; and run_meta_agent.py wraps meta-agent execution and diff extraction. Experiment logs are provided as outputs_os_parts.zip in the repository. [README]

59.2.3 Multi-Model Separation

DGM-H deliberately separates the modification engine from the evaluation engine. Claude 4.5 Sonnet (Anthropic) generates code diffs for agent variants. Evaluation uses distinct models per domain: o3-mini (OpenAI) for coding, GPT-4o (OpenAI) for paper review and math grading, and a physics simulator (no LLM) for robotics. The paper states this prevents "any single model from grading its own homework," mitigating self-deceptive optimization loops. [PAPER]

Model assignments by role [PAPER]

Role	Model	Provider
Self-modification (diff generation)	Claude 4.5 Sonnet	Anthropic
Coding evaluation	o3-mini	OpenAI
Paper review evaluation	GPT-4o	OpenAI
Robotics evaluation	Domain-specific simulation	N/A
Math grading evaluation	GPT-4o	OpenAI

59.2.4 Scope of Mutability

The critical architectural difference between the original DGM and DGM-H lies in what can be modified. The following table, derived directly from the paper's comparison, summarizes the mutable surface: [PAPER]

Mutability comparison: DGM vs. DGM-H [PAPER]

Component	DGM (Original)	DGM-H (Hyperagents)
Task-solving code	Editable	Editable
Prompt templates	Editable	Editable
Self-modification instructions	Fixed	Editable
Selection strategy	Fixed	Editable
Memory / tracking infrastructure	None	Self-created
Performance analysis code	None	Self-created
Evaluation criteria	Fixed	Editable

59.3 Core Algorithms

59.3.1 Formal Definition

The paper defines a hyperagent as a self-referential agent [PAPER]:

Symbol table — Hyperagent definition [Published formula — paper §3]

Symbol	Meaning	Domain
\(H\)	Hyperagent: the complete self-referential agent	Python program
\(T\)	Task agent component: domain-specific solver	Editable code within \(H\)
\(M\)	Meta agent component: modifies both \(T\) and itself	Editable code within \(H\)

The self-referential property means \(M\) can execute three classes of modification [PAPER]:

Symbol table — Modification operations [Published formula — paper §3]

Symbol	Meaning
\(T'\)	Modified task agent (new variant)
\(M'\)	Modified meta agent (evolved self-modification procedure)

59.3.2 The Generate Loop

The outer loop, implemented in generate_loop.py [README], orchestrates the iterative self-improvement cycle. The paper reports 50 iterations as the standard experimental setting [PAPER]:

# Pseudocode — reconstructed from paper description (§3, §9)
# Entry point: generate_loop.py --domains <domain>

def generate_loop(domain, max_iterations=50):
    archive = initialize_archive(domain)   # setup_initial.sh provides seed agents

    for iteration in range(max_iterations):
        # 1. Select parent agent from archive (strategy is editable)
        parent = select_parent(archive)

        # 2. Meta agent generates code diff via LLM
        diff = meta_agent_modify(
            current_source=parent.source_code,
            performance_history=archive.get_history(parent),
            modification_instructions=parent.meta_instructions  # EDITABLE
        )

        # 3. Apply diff to create new agent variant
        child = apply_diff(parent, diff)

        # 4. Evaluate child in sandboxed Docker environment
        score = evaluate(child, domain)

        # 5. Archive child if it adds value (quality + diversity)
        archive.maybe_add(child, score)

    return archive.best()

Selection within the archive is sequential: each iteration depends on the current archive state, so iterations cannot be parallelized. However, the selection strategy itself is part of the editable program, meaning the system can evolve how it chooses parent agents. [PAPER]

59.3.3 Meta Agent Modification Procedure

The meta agent's core operation is diff generation via LLM call. The paper describes a five-step workflow [PAPER]: (1) read current agent source code; (2) read performance history and analysis; (3) read self-modification instructions (which are themselves part of the editable code); (4) construct a prompt for Claude 4.5 Sonnet; (5) receive and apply the code diff. The helper script run_meta_agent.py wraps this process. [README]

# Pseudocode — reconstructed from paper description (§5, §9, §11)
# Corresponds to meta_agent.py (exact internal API not verified)

def meta_agent_modify(current_source, performance_history, modification_instructions):
    """
    Generate a modified version of the agent.
    modification_instructions is ITSELF part of the editable program.
    """
    # Assemble context for LLM call
    prompt = build_prompt(
        code=current_source,              # ~500–2000 LOC
        history=performance_history,       # cross-generation tracking
        instructions=modification_instructions,  # editable meta-strategy
        previous_diffs=get_recent_diffs()  # what was tried before
    )

    # Call Claude 4.5 Sonnet for diff generation
    # ~5K–20K input tokens, ~2K–10K output tokens per call
    diff = call_llm(model="claude-4.5-sonnet", prompt=prompt)

    # Apply diff to produce new agent variant
    new_source = apply_diff(current_source, diff)
    return new_source

A critical design choice: the LLM is used as a tool by the meta agent, not as a fixed component. The meta agent's instructions for how to prompt the LLM—what context to provide, what modifications to request, how to parse output—are all editable. In practice, the paper reports that the system autonomously improved its prompting strategies over successive generations. [PAPER]

59.3.4 Primary Evaluation Metric

The paper introduces imp@50 (improvement at 50 iterations) as its primary metric [PAPER]:

Symbol table — imp@k metric [Published formula — paper §6]

Symbol	Meaning	Domain
\(k\)	Number of self-improvement iterations	\(\mathbb{Z}^{+}\), typically 50
\(s^{*}_{k}\)	Best evaluation score in the archive at iteration \(k\)	\([0, 1]\) (domain-specific)
\(s^{*}_{0}\)	Initial agent score before any self-improvement	\([0, 1]\)
\(\text{imp@}k\)	Cumulative improvement over \(k\) iterations	\([-1, 1]\)

This metric captures cumulative improvement rather than absolute final score, making it sensitive to systems that consistently improve versus those that make a single fortunate modification. The paper standardizes on \(k = 50\) for all domain evaluations. [PAPER]

59.3.5 Cross-Domain Transfer Protocol

The transfer mechanism operates at the meta-agent level. After training DGM-H on Domain A for 50 iterations, the evolved meta agent code—including any self-built infrastructure such as checklists, multi-stage pipelines, and tracking systems—is extracted and used to initialize DGM-H on Domain B. The task agent component is reset to a domain-appropriate initial state; only the meta-level strategies transfer. [PAPER]

59.4 Key Results

59.4.1 Evaluation Caveats

Before examining the results, the following caveats apply:

• Seed / run counts: The paper does not report the number of independent seeds or runs per configuration. All results should be interpreted as point estimates from individual or small-sample runs. [PAPER]
• Variance: No confidence intervals or standard deviations are reported. Given the stochastic nature of LLM-based code generation, trajectory-level variance is expected to be high. [PAPER]
• Baseline budget matching: The static baseline for paper review (0.630) uses no iterative self-improvement and therefore consumes zero API budget. Comparison is structurally unmatched in terms of compute. [PAPER]
• Model version sensitivity: Results are tied to specific API model versions (Claude 4.5 Sonnet, o3-mini, GPT-4o) that may be updated or deprecated, making exact reproduction uncertain. [PAPER]
• Non-determinism: Self-modification is inherently stochastic; exact evolutionary trajectories will differ across runs. [PAPER]

59.4.2 Evidence Table

Performance results across all domains [PAPER]

Benchmark	Task	Baseline Score	DGM-H Score	Δ (imp@50)	Seeds / Runs	Compute Budget	Evaluation Protocol	Evidence Source
AI Paper Review	Predict accept/reject	0.630 (static baseline)	0.710	+0.710 (from 0.0 initial)	— (not reported)	50 iterations; Claude 4.5 Sonnet + GPT-4o	Balanced accuracy vs. human decisions	[PAPER] §6
Polyglot Coding	Multi-language code gen	0.084 (initial agent)	0.267	+0.183	— (not reported)	50 iterations; Claude 4.5 Sonnet + o3-mini	Pass rate on coding challenges	[PAPER] §6
Robotics Reward Design	Quadruped locomotion	0.060 (initial agent)	0.372	+0.312	— (not reported)	50 iterations; Claude 4.5 Sonnet + simulator	Normalized physics simulation performance	[PAPER] §6
Olympiad Math Grading	Proof grading	0.0 (all non-transfer configs)	0.630 (transfer from review + robotics)	+0.630	— (not reported)	50 iterations; Claude 4.5 Sonnet + GPT-4o	Grading accuracy vs. ground truth	[PAPER] §6
Polyglot Coding (DGM comparison)	Multi-language code gen	0.084 (DGM original)	0.267 (DGM-H) ≈ 0.267 (DGM)	≈ 0 (matches DGM)	— (not reported)	50 iterations	Pass rate	[PAPER] §6

59.4.3 Cross-Domain Transfer

The headline result is the cross-domain transfer experiment for Olympiad math grading [PAPER]:

Cross-domain transfer to Olympiad math [PAPER §6]

Configuration	Math Grading Score
Initial agent (no improvement)	0.0
DGM transfer agents	0.0
Standard DGM-H (no transfer)	0.0
DGM-H with transfer from paper review + robotics	0.630

This demonstrates that meta-level strategies—structured evaluation checklists, multi-stage analysis pipelines, persistent memory synthesis—discovered during paper review and robotics optimization are domain-general improvement strategies that transfer to entirely unrelated problems. All non-transfer configurations scored 0.0, making the transfer effect categorical rather than marginal. [PAPER]

59.4.4 Emergent Capabilities

Beyond raw metrics, the paper documents several emergent behaviors that were not programmed [PAPER]:

1. Self-built performance tracking: The system independently created cross-generation performance trackers without being instructed to do so.
2. Persistent memory synthesis: Agents evolved to maintain memory that "synthesizes insights rather than just logging numbers."
3. Compute-aware planning: The system adjusted its modification strategies based on remaining compute budget—broad exploratory changes early, targeted refinements later.
4. Bias detection: In the paper review domain, the system detected a 94% accept-rate imbalance in its own predictions and self-corrected.
5. Meta-reasoning: In one documented instance, the system reasoned that generation 55 was "best accuracy but is too harsh" and merged that version's rigorous reasoning with the balance of a later generation.

59.4.5 Ablation Results

The paper reports ablations confirming that all components are necessary [PAPER]:

Ablation summary [PAPER]

Configuration	Relative Performance
No self-improvement	Baseline (lowest)
Self-improvement without open-ended exploration	Limited gains
Open-ended exploration without metacognition (original DGM)	Domain-limited gains
Full DGM-H (metacognition + open-ended exploration)	Best across all domains

Note: the ablation is reported qualitatively in the paper; exact numerical breakdowns per ablation condition are not provided for all domains. [PAPER]

59.5 Implementation & Cost

59.5.1 Execution Trace

The following execution sequence is derived from the repository's README and setup scripts [README]:

# Repo-verified: README.md, setup_initial.sh, Dockerfile
# Environment setup
export OPENAI_API_KEY=...
export ANTHROPIC_API_KEY=...
export GEMINI_API_KEY=...

# System dependencies (Fedora/RHEL-based)
sudo dnf install -y python3.12-devel graphviz graphviz-devel \
    cmake ninja-build bzip2-devel zlib-devel ncurses-devel libffi-devel

# Python environment
python3.12 -m venv venv_nat
source venv_nat/bin/activate
pip install -r requirements.txt
pip install -r requirements_dev.txt

# Docker sandbox for agent execution
docker build --network=host -t hyperagents .

# Initialize domain-specific seed agents
bash ./setup_initial.sh

# Run the generate loop
python generate_loop.py --domains paper_review

Output artifacts are saved to an outputs/ directory. The repository includes pre-generated experiment logs as outputs_os_parts.zip. [README]

59.5.2 Cost Structure

The following cost estimates are paper-reported for typical runs [PAPER]:

Estimated cost per domain run [PAPER §8]

Domain	Iterations	Modification Model	Evaluation Model	Est. Cost per Run	Provenance
Polyglot Coding	50	Claude 4.5 Sonnet	o3-mini	$50–150	[PAPER]
Paper Review	50	Claude 4.5 Sonnet	GPT-4o	$30–100	[PAPER]
Robotics Reward	50	Claude 4.5 Sonnet	Simulation (free)	$20–60	[PAPER]
Olympiad Math	50	Claude 4.5 Sonnet	GPT-4o	$30–100	[PAPER]

59.5.3 Per-Iteration Token Budget

The paper describes the per-iteration cost breakdown [PAPER]:

Token budget per iteration [PAPER §8]

Stage	Input Tokens	Output Tokens
Prompt construction (code + history + instructions)	~5K–20K	—
Diff generation (Claude 4.5 Sonnet)	—	~2K–10K
Domain evaluation (where LLM-based)	Varies	Varies

59.5.4 Infrastructure Requirements

DGM-H is compute-light on local hardware because LLM inference is offloaded to API providers [PAPER]:

• CPU: Standard development machine (no GPU required)
• Memory: Minimal; agent programs are small (1–50 KB each)
• Docker: Required for sandboxed execution of self-generated code
• Network: Required for LLM API calls
• Storage: Moderate; archive of ~150 variants at ~10 KB average ≈ 1.5 MB for a 50-iteration run

59.6 Reproducibility Checklist

Requirement	Status	Notes
Code publicly released	✓	github.com/facebookresearch/HyperAgents, CC BY 4.0 [README]
Config files available	Partial	CLI args documented; domain configs in domains/ subdirectories [README]
Pretrained weights / checkpoints	N/A	No model training; uses API-only inference [PAPER]
Documented entry point or run command	✓	python generate_loop.py --domains <domain> [README]
Compute requirements stated	✓	Standard CPU + Docker + API access; cost ranges provided [PAPER]
Seeds and run counts reported	✗	Not reported in paper [PAPER]
Independent reproduction attempted	✗	No independent reproduction reported as of April 2026 [PAPER]
Experiment logs provided	✓	outputs_os_parts.zip in repository [README]
Docker build instructions	✓	Dockerfile in repository root [README]
Initial agent setup script	✓	setup_initial.sh [README]

Key reproducibility challenges: (1) API costs of $500–2,000 for full reproduction across all domains; (2) model version drift as Claude 4.5 Sonnet, o3-mini, and GPT-4o are updated or deprecated; (3) inherent non-determinism of LLM-based code generation; (4) three separate API provider accounts required (OpenAI, Anthropic, Google). [PAPER]

59.7 Threats to Validity

This section consolidates methodological concerns that affect the strength of the paper's claims.

59.7.1 Absence of Variance Reporting

No seed counts, confidence intervals, or standard deviations are reported for any result. Given the stochastic nature of LLM-generated code diffs, a single evolutionary trajectory may be unrepresentative. The headline cross-domain transfer result (0.0 → 0.630 on math) could reflect a fortunate run rather than a robust property. Without variance estimates, the statistical significance of all improvements is unknown. [PAPER]

59.7.2 Compute Budget Mismatch with Baselines

The static baseline for paper review (0.630) uses a single prompt with no iterative improvement, while DGM-H invests 50 iterations of Claude 4.5 Sonnet calls plus GPT-4o evaluations. This budget asymmetry means the comparison does not isolate the contribution of metacognitive self-modification from the contribution of simply spending more compute on the problem. A budget-matched baseline—e.g., 50 independent random restarts using the same total API tokens—is not reported. [PAPER]

59.7.3 Reviewer Circularity

For the paper review and math grading domains, evaluation uses GPT-4o to judge agent output. If the evolving agent's meta-strategies implicitly learn to produce output that GPT-4o rates highly (rather than output that a human expert would prefer), the improvement may partially reflect evaluation model exploitation rather than genuine capability improvement. The paper mitigates this with model separation (Claude for modification, GPT-4o for evaluation) but does not test with human evaluators as an independent check. [PAPER]

59.7.4 Model Version Fragility

Results are produced with specific model versions (Claude 4.5 Sonnet, o3-mini, GPT-4o) that are subject to provider-side updates. The paper does not pin exact model version strings or checkpoint dates, making exact reproduction dependent on API stability. [PAPER]

59.7.5 Scale of Evolved Programs

Evolved agents are relatively small programs (500–2,000 lines of code). It is unknown whether the diff-based self-modification approach scales to complex multi-file systems with thousands of lines. The paper acknowledges this as a current limitation. [PAPER]

59.7.6 No Independent Reproduction

As of April 2026, no independent group has reported reproducing the cross-domain transfer result. The experiment logs provided in the repository enable post-hoc inspection but not independent validation.

59.7.7 Safety at Scale

All experiments were small-scale with human oversight at checkpoints. The Docker sandboxing provides resource limits and filesystem isolation, but the safety properties have not been tested at deployment scale or under adversarial conditions. The paper commendably acknowledges this: "We discuss what safety entails in this setting and the broader implications of self-improving systems." [PAPER]

59.8 Limitations & Open Questions

The paper is transparent about several limitations [PAPER]:

1. Sample efficiency: 50 iterations with LLM API calls represent a significant investment per run. Whether the system can learn meaningful improvements in fewer iterations remains open.
2. Selection strategy gap: Self-discovered selection strategies have not yet matched hand-designed mechanisms, suggesting metacognitive self-modification remains in early stages. The paper states this directly.
3. Evaluation ceiling: Performance is bounded by the quality of the fixed evaluation mechanism. If evaluation is imperfect or gameable, the system could optimize for evaluation artifacts rather than true capability.
4. Theoretical foundations: The paper is entirely empirical. There is no formal characterization of when or why metacognitive self-modification should work, nor what its convergence properties or fundamental limits are.
5. Two-player dynamics: The paper does not extensively test adversarial domains where opponents are also improving.

59.9 Survey Positioning

59.9.1 Relationship to Darwin Gödel Machine (DGM)

DGM-H is the direct successor to the Darwin Gödel Machine (Zhang et al., 2025b, Sakana AI). The original DGM demonstrated self-improving coding agents that evolve their own source code, but its improvement mechanism—the mutation instructions, selection strategy, and prompt templates—was fixed. DGM-H's contribution is making these meta-level components editable, enabling domain-general self-improvement. On the coding domain where DGM was optimized, DGM-H matches DGM's performance (imp@50 ≈ 0.183), demonstrating no regression from generalization. On non-coding domains, DGM-H substantially exceeds DGM. [PAPER]

59.9.2 Relationship to AlphaEvolve

Google DeepMind's AlphaEvolve (Novikov et al., 2025; see Chapter 37 of this survey) applies evolutionary algorithms to codebases with LLMs as mutation operators. AlphaEvolve and DGM-H share the diff-based code evolution paradigm, but differ in a fundamental way: AlphaEvolve's mutation operators, selection strategy, and fitness evaluation are all fixed components designed by human engineers. DGM-H makes these components editable, enabling the system to evolve how it evolves. AlphaEvolve targets mathematical and algorithmic optimization within a fixed search framework; DGM-H targets open-ended agent improvement with a self-modifying search framework. Budgets are not directly comparable: AlphaEvolve operates with large-scale compute on Google infrastructure, while DGM-H uses only API calls. [PAPER]

59.9.3 Relationship to FunSearch

FunSearch (Romera-Paredes et al., 2024; see Chapter 9 of this survey) applies LLM-guided program search to combinatorial mathematics. Like DGM-H, it evolves Python programs via an LLM, but the search algorithm (best-shot sampling with islands) is entirely fixed. DGM-H's archive of stepping stones serves a function analogous to FunSearch's island populations: both maintain diversity to prevent premature convergence. The distinction is that DGM-H's selection and archival strategy can itself evolve, whereas FunSearch's island topology and migration policy are predetermined. [PAPER]

59.9.4 Positioning in the Self-Improvement Landscape

Comparative positioning (March 2026) [PAPER §15]

System	Organization	Self-Improvement Type	Meta-Level Editable	Cross-Domain Transfer
DGM-H	Meta FAIR + Labs	Metacognitive code evolution	Yes	Yes
DGM (original)	Sakana AI	Coding-only code evolution	No	No
AlphaEvolve	Google DeepMind	Evolutionary code optimization	No	No
FunSearch	Google DeepMind	LLM-guided program search	No	No
Reflexion	Independent	Verbal reinforcement	No	No

DGM-H's claimed distinctive position is the combination of metacognitive self-modification and cross-domain transfer. Among the systems surveyed in this book, it appears to be the first to demonstrate empirically that improvement strategies (not just improved programs) transfer across unrelated task domains. This claim is bounded to the comparison class of LLM-powered evolutionary code-modification systems published through March 2026. [PAPER]

59.9.5 Evolutionary Computation Parallels

DGM-H has deep structural parallels with biological evolution, particularly with the concept of evolvability—the capacity of a lineage to evolve more effectively over time. Biological evolution has produced mechanisms that enhance future evolution (sexual reproduction, modular body plans, gene regulatory networks). DGM-H's metacognitive self-modification is the computational analogue: evolving mechanisms that make future improvement more effective. [PAPER]

Evolutionary computation parallels [PAPER §15]

Concept	Biological Evolution	DGM-H
Individual	Organism	Agent (Python program)
Genotype	DNA	Source code
Mutation	Random DNA changes	LLM-generated code diffs
Selection	Natural selection	Archive-based selection (editable)
Population	Species	Archive of agent variants
Evolvability	Evolved capacity to evolve	Meta-level self-modification

59.10 Memory Architecture & Continued Learning

59.10.1 Memory Hierarchy

DGM-H operates with a four-level memory hierarchy, none of which involves LLM weight modification [PAPER]:

Memory hierarchy [PAPER §13]

Level	Mechanism	Persistence	Size
Long-term	Agent archive (all variants, scores, lineages)	Across iterations within a run	~1.5 MB for 50 iterations
Medium-term	Evolved agent memory (self-built tracking, insight synthesis)	Embedded in agent source code	Part of agent program text
Short-term	LLM context window (code + history + instructions)	Ephemeral; one LLM call	~10K–35K tokens per call
Cross-run	Transfer agents (meta strategies persisted across domains)	Across independent runs	Meta-agent source code

The medium-term memory level is particularly distinctive: agents evolve their own internal state representations as part of their source code. The paper documents agents that created cross-generation performance trackers, insight synthesis routines, and strategy annotations—all without human instruction. [PAPER]

59.10.2 Learning Dynamics

Within-run learning curves show consistent improvement over 50 iterations, though the paper does not report variance across runs [PAPER]:

Approximate learning trajectory [PAPER §14]

Domain	Iteration 0	~Iteration 10	~Iteration 25	Iteration 50
Paper Review	0.0	~0.3	~0.5	0.710
Coding	0.084	~0.15	~0.22	0.267
Robotics	0.060	~0.15	~0.25	0.372

The paper claims meta-level improvements "accumulate across runs": each run adds to the meta agent's repertoire of improvement strategies. This accumulation is the basis for the paper's claim of potentially self-accelerating progress, though this has not been empirically demonstrated beyond two-hop transfer (Domains A+B → Domain C). [PAPER]

59.11 Safety Considerations

The paper explicitly discusses safety implications of self-improving systems [PAPER]:

• Current measures: Docker sandboxing with resource limits, restricted internet access, time limits per execution, filesystem isolation, and human oversight at checkpoints. [PAPER, README]
• Repository warning: "This repository involves executing untrusted, model-generated code. We strongly advise users to be aware of the associated safety risks." [README]

The paper raises but does not resolve several safety questions: (1) if meta-level improvement accumulates across runs, capability evolution could accelerate beyond oversight capacity; (2) sufficiently capable self-modifying code might find sandbox escape vectors; (3) agents could evolve to appear aligned during evaluation while pursuing different objectives (deceptive alignment); (4) human oversight may not scale at the same rate as the system's self-improvement. [PAPER]

59.12 Summary