← Back to Index

A-Evolve

Universal Infrastructure for Self-Improving Agents via Agentic Evolution Organization: Amazon (A-EVO-Lab) Published: February 3, 2026 (paper); March 25, 2026 (open-source release) Type: Position Paper (ICML) + Open-Source Framework Report Type: PhD-Level Technical Analysis Report Date: April 2026

Table of Contents

• Full Title and Attribution
• Authors and Team
• Core Contribution
• Supported Solutions
• LLM Integration
• Key Results
• Reproducibility
• Compute and API Costs
• Architecture Solution
• Component Breakdown
• Core Mechanisms (Detailed)
• Programming Language
• Memory Management
• Continued Learning
• Applications

1 Full Title and Attribution

Full Title: Position: Agentic Evolution is the Path to Evolving LLMs

arXiv: 2602.00359 (v2)

GitHub Repository: A-EVO-Lab/a-evolve

License: MIT

Publication Venue: ICML 2026 (Machine Learning)

Publication Date: February 3, 2026 (arXiv preprint); March 25, 2026 (open-source infrastructure release)

Lineage: Positioned as a unifying framework that subsumes and extends prior work on LLM self-improvement — including Reflexion (Shinn et al., 2023), test-time training (Huang et al., 2025), prompt optimization (Zhou et al., 2022), and heuristic memory accumulation (Wang et al., 2024; Gao et al., 2025). The authors explicitly frame A-Evolve as the "PyTorch for Agentic AI" — a standardized infrastructure layer rather than a standalone agent.

BibTeX:

@article{lin2026position,
  title={Position: Agentic Evolution is the Path to Evolving LLMs},
  author={Lin, Minhua and Lu, Hanqing and Shi, Zhan and He, Bing and
          Mao, Rui and Zhang, Zhiwei and Wu, Zongyu and Tang, Xianfeng
          and Liu, Hui and Dai, Zhenwei and others},
  journal={arXiv preprint arXiv:2602.00359},
  year={2026}
}

2 Authors and Team

The paper is authored by a large team at Amazon, operating under the lab name A-EVO-Lab:

Primary Authors: Minhua Lin, Hanqing Lu, Zhan Shi, Bing He, Rui Mao, Zhiwei Zhang, Zongyu Wu, Xianfeng Tang, Hui Liu, Zhenwei Dai, Xiang Zhang, Suhang Wang, Benoit Dumoulin, Jian Pei

The team spans Amazon's applied science and research divisions. Several authors have prior work in continual learning, LLM agents, and deployment-time adaptation. The inclusion of Jian Pei — a prominent database and data mining researcher (Simon Fraser University → Duke University → Amazon) — signals the team's focus on systematic, infrastructure-grade approaches to agent improvement rather than ad-hoc optimization.

The lab name "A-EVO-Lab" (Amazon Evolution Lab) and the paper's ICML positioning suggest this is a strategic research direction for Amazon — framing deployment-time agent self-improvement as a first-class scaling axis alongside training-time and inference-time compute.

3 Core Contribution

Key Novelty: A-Evolve introduces agentic evolution as a third scaling axis for LLM systems — complementary to training-time compute and inference-time compute — where an explicit evolver agent autonomously diagnoses failures, proposes structured mutations to persistent agent state, gates updates through validation, and commits only verified improvements. The framework treats the entire agent workspace (prompts, skills, tools, memory) as mutable file-system state, enabling domain-agnostic, algorithm-agnostic, and agent-agnostic evolution.

The Central Argument

The paper makes a position argument with three pillars:

1. The Train-Deploy Gap is Fundamental. Static LLM training (pre-training + post-training) cannot anticipate the infinite variety of real-world deployment scenarios. Models inevitably degrade under distribution shift, API changes, and evolving constraints. Neither scaling training data nor extending inference-time reasoning chains closes this gap.

2. Existing Adaptation Methods Are Insufficient. Parametric approaches (fine-tuning, test-time training) are opaque, risk catastrophic forgetting, and lack semantic accountability. Non-parametric heuristic approaches (memory accumulation, append-and-retrieve) saturate with noisy text and exhibit diminishing returns. Both fail because the update mechanism F_Evolve is static and heuristic rather than adaptive and goal-directed.

3. Evolution Must Be Agentic. The evolution process itself must be elevated from a fixed pipeline to an autonomous evolver agent that reasons about failures, decides what/when/how to change, and produces verified, composable updates. This is the only path to sustained, open-ended adaptation over indefinite deployment horizons.

What Makes A-Evolve Novel

The Evolution-Scaling Hypothesis

The paper's most ambitious theoretical contribution is the Evolution-Scaling Hypothesis — a conjecture that deployment-time adaptation capacity scales predictably with compute allocated to the evolution process, analogous to training-time scaling laws (Kaplan et al., 2020) and inference-time scaling (Snell et al., 2025):

P*(C_evolve, π_0) = max_{F_evolve} E_{π ~ F_evolve(π_0)} [P(π)]

Where: - P*(C_evolve, π_0) is the compute-optimal evolution frontier - C_evolve is the total evolution-time compute budget - F_evolve ranges over all evolution strategies within that budget - π_0 is the initial deployed policy

The hypothesis states that P* is strictly increasing with C_evolve: more evolution compute → more accurate diagnosis, more candidate updates considered, more robust artifact synthesis, and stronger verification before committing. Validated updates persist and compound, making evolution a convergent process whose effectiveness scales with resources.

This positions agentic evolution as a third scaling law — after training-time and inference-time — and the first to operate during deployment rather than before it.

4 Supported Solutions

A-Evolve is a framework, not a standalone agent. It evolves any agent that implements the BaseAgent.solve() interface, across any domain with a BenchmarkAdapter, using any evolution strategy via EvolutionEngine.step(). The types of evolvable artifacts include:

Solution Domain Breadth

The framework ships with adapters for four diverse benchmark domains:

What an Evolved Agent Looks Like

A concrete before/after from the MCP-Atlas evolution:

Before (seed workspace):

mcp_agent/
├── manifest.yaml
├── prompts/system.md      ← 20 lines, generic
├── skills/                ← empty
└── memory/                ← empty

After (evolved — 79.4% on MCP-Atlas, #1 ranked):

mcp_agent/
├── manifest.yaml
├── prompts/system.md      ← 20 lines, unchanged
├── skills/
│   ├── entity-verification/SKILL.md   ← NEW
│   ├── search-iteration/SKILL.md      ← NEW
│   ├── multi-requirement/SKILL.md     ← NEW
│   ├── code-execution/SKILL.md        ← NEW
│   └── conditional-handler/SKILL.md   ← NEW
└── memory/
    └── episodic.jsonl     ← 6 entries

Key insight: 5 targeted skills outperformed 10 generic ones. The evolution engine learned to synthesize specific, verified skills rather than accumulating broad but shallow capabilities. The system prompt was left unchanged — all improvement came through structured artifact creation.

5 LLM Integration

Composite Policy Model

A-Evolve models an LLM system as a composite policy:

π_t = (π_θ,t, π_S,t)

Where: - π_θ,t — the parametric backbone (LLM weights, frozen during non-parametric evolution) - π_S,t — the persistent artifact state (prompts, skills, tools, memory) that conditions behavior across episodes

This separation is fundamental: the LLM backbone provides the reasoning engine, while the artifact state provides the accumulated deployment knowledge. Evolution can target either or both, though the current implementation focuses on non-parametric artifact evolution (mutating π_S) while keeping π_θ fixed.

LLM Roles in the Framework

Provider Abstraction

The framework abstracts LLM access through a LLMProvider.complete() interface:

Dual-Use Architecture

Unlike systems that use separate models for mutation and evaluation (e.g., AlphaEvolve's Flash/Pro ensemble), A-Evolve uses the same model for both solving and evolving by default. The evolution engine can optionally use a different (stronger) model for the evolution phases, but the default configuration demonstrates that a single model can bootstrap its own improvement through structured workspace mutations.

Critical distinction from AlphaEvolve: Where AlphaEvolve evolves code programs as solutions to mathematical/algorithmic problems, A-Evolve evolves agents — the prompts, skills, tools, and memory that govern an LLM's task-solving behavior. The mutation target is not a standalone algorithm but the deployed system's persistent state.

6 Key Results

Headline Performance

All results achieved with a single Claude Opus-4.6 base model, evolved using A-Evolve's reference algorithms, with zero hours of human harness engineering:

Result Significance

Ablation Study: Evolver Component Contributions

The paper includes ablation experiments (referenced in Sections 5-6 of the paper) that decompose the contribution of each evolver component:

Key ablation finding: The planning stage was the most impactful individual component. Without planning, the diagnosis stage produced correct failure attributions but the resulting updates were often syntactically broken or semantically incomplete. Planning translates "what's wrong" into "how to fix it" — bridging the gap between understanding and actionable improvement.

Convergence Behavior

The evolution loop converges when EGL (Evolutionary Generality Loss) stabilizes or max_cycles is reached. EGL measures the gap between training performance and holdout performance:

EGL(t) = Score_train(t) - Score_holdout(t)

The framework uses an egl_window parameter (configurable, default varies by algorithm) to detect convergence. When EGL stops improving over the window, evolution halts — preventing overfitting to the training task distribution. This mechanism is critical for ensuring that evolved skills generalize to unseen tasks.

7 Reproducibility

Reproducibility Infrastructure

A-Evolve provides unusually strong reproducibility guarantees for an LLM-based system:

Open Source Status

Reproducing Results

import agent_evolve as ae

# Reproduce MCP-Atlas #1 result
evolver = ae.Evolver(
    agent="mcp",                    # built-in seed workspace
    benchmark="mcp-atlas",          # built-in benchmark adapter
    engine="adaptive_evolve",       # reference algorithm
)
results = evolver.run(cycles=10)
# Expected: ~79.4% final score

Caveat: Exact numerical reproduction depends on LLM API determinism (temperature, sampling seed), which is not fully guaranteed across API versions. However, the directional results and convergence behavior should reproduce consistently.

8 Compute and API Costs

Cost Model

A-Evolve's compute costs decompose into two categories:

Estimated Costs Per Benchmark

Based on the reported configurations (Claude Opus-4.6, 10 evolution cycles):

Important: These are rough estimates. Actual costs depend heavily on task complexity, agent trajectory length, and LLM pricing at time of use. The evolution phase involves multiple LLM calls per cycle (diagnose, plan, update, verify), and complex benchmarks like SWE-bench generate longer trajectories.

Cost Scaling

The Evolution-Scaling Hypothesis implies that costs scale linearly with C_evolve but returns are sublinear (log-like improvement curve). Key cost levers:

9 Architecture Solution

High-Level Architecture

┌──────────────────────────────────────────────────────────────────┐
│                        A-EVOLVE FRAMEWORK                        │
│                                                                  │
│  ┌────────────────┐       ┌──────────────────────────────────┐  │
│  │  Agent (BYOA)  │       │     Evolution Engine (BYO-Algo)  │  │
│  │                │       │                                  │  │
│  │  BaseAgent     │       │  EvolutionEngine                 │  │
│  │  .solve(task)  │       │  .step(workspace, obs, hist)     │  │
│  │                │       │                                  │  │
│  │  ┌──────────┐  │       │  ┌──────────┐  ┌─────────────┐  │  │
│  │  │ Solver   │  │       │  │ Diagnose │→ │    Plan     │  │  │
│  │  │ (LLM)    │  │       │  └──────────┘  └─────────────┘  │  │
│  │  └──────────┘  │       │       │              │           │  │
│  └────────┬───────┘       │  ┌────▼──────┐  ┌───▼────────┐  │  │
│           │               │  │  Update   │→ │  Verify    │  │  │
│           │               │  └───────────┘  └────────────┘  │  │
│           │               └──────────────┬───────────────────┘  │
│           │                              │                      │
│  ┌────────▼──────────────────────────────▼───────────────────┐  │
│  │                    AGENT WORKSPACE (π_S)                   │  │
│  │                                                            │  │
│  │  manifest.yaml  prompts/  skills/  tools/  memory/        │  │
│  │                                                            │  │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────────────────┐    │  │
│  │  │Knowledge │  │  Tool    │  │   Validation         │    │  │
│  │  │Registry  │  │ Registry │  │   Registry           │    │  │
│  │  │  (K_t)   │  │  (T_t)  │  │    (V_t)             │    │  │
│  │  └──────────┘  └──────────┘  └──────────────────────┘    │  │
│  └────────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐  │
│  │              Benchmark Adapter (BYOE)                      │  │
│  │  .get_tasks(split, limit)    .evaluate(task, trajectory)   │  │
│  └────────────────────────────────────────────────────────────┘  │
│                                                                  │
│  ┌─────────────────┐  ┌──────────────┐  ┌─────────────────┐    │
│  │  VersionControl │  │ EvolutionHist│  │  TrialRunner    │    │
│  │  (git-backed)   │  │  (obs+logs)  │  │  (on-demand     │    │
│  │                 │  │              │  │   validation)   │    │
│  └─────────────────┘  └──────────────┘  └─────────────────┘    │
└──────────────────────────────────────────────────────────────────┘

The Solve-Evolve Control Loop

The core loop separates instance-level task execution from cross-episode capability improvement:

┌─────────┐    ┌─────────┐    ┌─────────┐    ┌──────┐    ┌────────┐
│  SOLVE  │───▶│ OBSERVE │───▶│ EVOLVE  │───▶│ GATE │───▶│ RELOAD │
│         │    │         │    │         │    │      │    │        │
│ Agent   │    │ Collect │    │ Engine  │    │Check │    │ Agent  │
│ runs on │    │ trajs + │    │ mutates │    │hold- │    │ reloads│
│ tasks   │    │ feedback│    │ work-   │    │out   │    │ from   │
│         │    │ into    │    │ space   │    │tasks │    │ (maybe │
│ π_S is  │    │ Obs     │    │ files   │    │      │    │ rolled │
│ read-   │    │ buffer  │    │         │    │accept│    │ back)  │
│ only    │    │         │    │         │    │/     │    │ work-  │
│         │    │         │    │         │    │reject│    │ space  │
└─────────┘    └─────────┘    └─────────┘    └──────┘    └────────┘
     │                                                        │
     └────────────────────────────────────────────────────────┘
                          NEXT CYCLE

Formal specification:

Solve:    τ_t = Solve(π_t, x_t)                    # Black-box execution
Observe:  Obs_{1:t} = Obs_{1:t-1} ∪ {τ_t}          # Evidence accumulation
Evolve:   Δ_t ← F_Evolve(π_θ,t, π_S,t, Obs_{1:t}) # Structured mutation
Gate:     c_t ← C(π_t, Δ_t, Obs_{1:t})             # Commit decision {0,1}
Reload:   π_{t+1} = π_t ⊕ (c_t · Δ_t)             # Conditional update

Three-Axis Pluggability

Key architectural insight: The Agent Workspace is the unifying abstraction. By standardizing agent state as a file-system directory with a manifest, the evolution engine can mutate any agent without knowing its internals. The agent reloads from its workspace after each cycle, picking up mutations transparently. This decoupling is what makes A-Evolve truly agent-agnostic.

10 Component Breakdown

Core Type System

from agent_evolve.types import Task, Trajectory, Feedback, StepResult

# Task: input to the agent
Task(
    id: str,                    # Unique task identifier
    input: str,                 # Task prompt/description
    metadata: dict              # Benchmark-specific metadata (rule, answer, etc.)
)

# Trajectory: agent's execution trace
Trajectory(
    task_id: str,               # Links back to Task
    output: str,                # Agent's final answer
    steps: list[dict]           # Execution trace (tool calls, reasoning, etc.)
)

# Feedback: benchmark evaluation result
Feedback(
    success: bool,              # Binary pass/fail
    score: float,               # Continuous score [0, 1]
    detail: str,                # JSON-serialized evaluation details
    raw: dict                   # Raw evaluation data
)

# StepResult: evolution engine output
StepResult(
    mutated: bool,              # Whether workspace was modified
    summary: str,               # Human-readable mutation description
    metadata: dict              # Engine-specific metadata
)

Agent Workspace Contract (AgentWorkspace)

The AgentWorkspace class mediates all file-system interactions:

Base Agent Contract (BaseAgent)

from agent_evolve.protocol.base_agent import BaseAgent

class BaseAgent:
    def __init__(self, workspace_dir: str | Path):
        self.workspace = AgentWorkspace(workspace_dir)
        self.system_prompt = self.workspace.read_prompt()
        self.skills = self.workspace.list_skills()
        self.memories = self.workspace.list_memories()

    def solve(self, task: Task) -> Trajectory:
        """Implement this: process task, return trajectory."""
        raise NotImplementedError

    def reload_from_fs(self):
        """Re-read workspace state after evolution mutations."""
        self.system_prompt = self.workspace.read_prompt()
        self.skills = self.workspace.list_skills()
        self.memories = self.workspace.list_memories()

    def remember(self, content: str, category: str = "episodic"):
        """Store episodic memory during solve phase."""
        self.workspace.add_memory({"content": content}, category)

Evolution Engine Contract (EvolutionEngine)

from agent_evolve.engine.base import EvolutionEngine

class EvolutionEngine:
    def step(
        self,
        workspace: AgentWorkspace,      # Mutable workspace reference
        observations: list[Observation], # Accumulated solve results
        history: EvolutionHistory,       # Previous cycles' data
        trial: TrialRunner               # On-demand validation
    ) -> StepResult:
        """One evolution cycle. Analyze failures, mutate workspace."""
        raise NotImplementedError

Benchmark Adapter Contract (BenchmarkAdapter)

from agent_evolve.benchmarks.base import BenchmarkAdapter

class BenchmarkAdapter:
    def get_tasks(
        self,
        split: str = "train",    # "train" or "holdout"
        limit: int = 10
    ) -> list[Task]:
        """Return benchmark tasks for the given split."""
        raise NotImplementedError

    def evaluate(
        self,
        task: Task,
        trajectory: Trajectory
    ) -> Feedback:
        """Score agent output against ground truth."""
        raise NotImplementedError

Evolver Configuration (EvolveConfig)

import agent_evolve as ae

config = ae.EvolveConfig(
    batch_size=8,       # Tasks per solve batch
    max_cycles=10,      # Maximum evolution iterations
    egl_window=2,       # EGL convergence window size
)

Shared Primitives

The evolution engine has access to three shared primitives:

11 Core Mechanisms (Detailed)

Mechanism 1: The Four-Phase Evolver

The evolver F_Evolve is decomposed into four cooperating functions that implement the three principles of agentic evolution:

                    ┌─────────────────┐
                    │  Obs_{1:t}      │  Accumulated deployment evidence
                    │  (trajectories, │  (tool traces, errors, feedback)
                    │   feedback)     │
                    └────────┬────────┘
                             │
                    ┌────────▼────────┐
                    │    DIAGNOSE     │  Goal-oriented: identify WHAT to change
                    │                 │
                    │  • Classify     │  Analyze failure modes across tasks
                    │    failure      │  Attribute to root causes
                    │    modes        │  (missing tools, brittle logic,
                    │  • Attribute    │   interface mismatches)
                    │    root causes  │
                    │  • Produce      │  Output: update objective g_t
                    │    update       │
                    │    objective    │
                    └────────┬────────┘
                             │ g_t
                    ┌────────▼────────┐
                    │      PLAN       │  Compositional: specify HOW to change
                    │                 │
                    │  • Target       │  Select target artifacts
                    │    artifacts    │  Choose edit operators
                    │  • Edit ops     │  (add, patch, refactor, prune)
                    │    (add/patch/  │  Define ordering constraints
                    │     refactor/   │
                    │     prune)      │  Output: edit plan p_t
                    │  • Ordering     │
                    └────────┬────────┘
                             │ p_t
                    ┌────────▼────────┐
                    │     UPDATE      │  Execute the plan
                    │                 │
                    │  • Synthesize   │  Generate concrete file changes
                    │    artifact     │  Write SKILL.md, patch prompts,
                    │    changes      │  update memory
                    │  • Attach       │  Include provenance + tests
                    │    provenance   │
                    │  • Build Δ_t    │  Output: candidate update Δ_t
                    └────────┬────────┘
                             │ Δ_t
                    ┌────────▼────────┐
                    │     VERIFY      │  Autonomy: decide WHEN to commit
                    │                 │
                    │  • Run holdout  │  Evaluate on held-out tasks
                    │    validation   │  Check for regressions
                    │  • Check for   │  Return commit decision c_t ∈ {0,1}
                    │    regressions  │
                    │  • Commit or    │  Output: c_t
                    │    rollback     │
                    └─────────────────┘

Mechanism 2: Persistent Artifact State (π_S)

The artifact state is organized into three typed registries:

Knowledge Registry (K_t): - Stores structured or textual artifacts: schemas, workflows, interface contracts, exemplars - Addressable and versioned — supports retrieval, patching, and replacement - Enables goal-oriented evolution by localizing failures to specific knowledge components - Physically: prompts/, skills/ directories

Tool Registry (T_t): - Contains executable functions with explicit input-output signatures and associated tests - During solve-time: provides deterministic action primitives reducing inference variance - During evolve-time: serves as diagnostic instruments for replaying failures and probing edge cases - Physically: tools/ directory

Validation Registry (V_t): - Contains governance assets: unit tests, regression suites, human review hooks - Validation artifacts are themselves editable (the evolution engine can synthesize new tests) - Grounds the commit decision c_t: updates committed only if they pass verification - Critical for preventing regressions over long deployment horizons

Mechanism 3: Edit Operators

A-Evolve supports a small set of canonical edit operators over π_S:

All proposed updates are logged with full provenance, enabling auditing, rollback, and risk-based human oversight.

Mechanism 4: Reference Evolution Algorithms

A-Evolve ships with four reference algorithms, each implementing EvolutionEngine.step():

Mechanism 5: Evolutionary Generality Loss (EGL)

EGL is A-Evolve's convergence detection metric:

EGL(t) = Score_train(t) - Score_holdout(t)

The framework monitors EGL across a sliding window (egl_window parameter). When EGL stabilizes (the gap between training and holdout performance stops narrowing), evolution halts. This serves two purposes:

1. Prevents overfitting: If training score improves but holdout score doesn't, the agent is memorizing task-specific solutions rather than learning generalizable capabilities
2. Saves compute: Stops evolution when further cycles are unlikely to yield meaningful holdout improvement

The EGL window is configurable per algorithm — skillforge uses strict EGL gating, while guided_synth uses a looser window to allow longer exploration before convergence.

Mechanism 6: Git-Based Version Control

Every accepted mutation is git-tagged with an incrementing version:

evo-0  →  Initial seed workspace
evo-1  →  First accepted mutation (e.g., prompt hardening)
evo-2  →  Second accepted mutation (e.g., added json-sum-exact skill)
evo-3  →  Third accepted mutation (e.g., added episodic memory patterns)
...

If the Gate phase rejects a mutation (holdout regression), the workspace is automatically rolled back to the last tagged version. This provides:

• Full audit trail: Every evolution step is inspectable via git diff evo-N..evo-N+1
• Reproducibility: Checkout any tag to reproduce the agent at that evolution stage
• Safety: No permanent damage from bad mutations; always recoverable

12 Programming Language

Framework Implementation

Package Structure

a-evolve/
├── agent_evolve/              # Core framework package
│   ├── __init__.py            # ae.Evolver, ae.EvolveConfig exports
│   ├── protocol/
│   │   └── base_agent.py      # BaseAgent ABC
│   ├── benchmarks/
│   │   └── base.py            # BenchmarkAdapter ABC
│   ├── engine/
│   │   └── base.py            # EvolutionEngine ABC
│   ├── contract/
│   │   └── workspace.py       # AgentWorkspace file-system abstraction
│   ├── types.py               # Task, Trajectory, Feedback, StepResult
│   └── algorithms/            # Reference evolution algorithms
│       ├── adaptive_evolve/
│       ├── adaptive_skill/
│       ├── skillforge/
│       └── guided_synth/
├── seed_workspaces/           # Pre-built starting points
│   ├── swe/
│   ├── mcp/
│   ├── terminal/
│   └── reasoning/
├── docs/                      # Benchmark-specific guides
│   ├── swe-bench-demo.md
│   ├── mcp-atlas-demo.md
│   ├── terminal-bench-demo.md
│   ├── skill-bench-demo.md
│   └── algorithms/            # Algorithm documentation
│       ├── adaptive-evolve.md
│       ├── adaptive-skill.md
│       ├── skillforge.md
│       └── guided-synth.md
├── figs/                      # Figures for README
├── pyproject.toml / setup.py  # Package definition
└── README.md

API Design Philosophy

The API is designed for minimal surface area — "3 lines of code" is the guiding principle:

import agent_evolve as ae

evolver = ae.Evolver(agent="swe-verified", benchmark="swe-verified")
results = evolver.run(cycles=10)

Extensibility is achieved through interface implementation rather than configuration complexity. Custom agents implement solve(), custom benchmarks implement get_tasks() + evaluate(), and custom algorithms implement step(). Each interface is a single method.

13 Memory Management

Memory Architecture

A-Evolve employs a file-system-native memory model where all memory is serialized to the workspace directory. This is fundamentally different from in-process memory systems — memory persists across agent restarts, evolution cycles, and even deployment sessions.

Memory Flow Through the Loop

SOLVE PHASE                    EVOLVE PHASE
─────────────                  ──────────────
Agent reads:                   Engine reads:
  • prompts/system.md            • Obs buffer (all trajectories)
  • skills/                      • memory/episodic.jsonl
  • memory/ (last N entries)     • Current workspace state

Agent writes:                  Engine writes:
  • memory/episodic.jsonl        • skills/new-skill/SKILL.md
    (task outcomes, traces)      • prompts/system.md (patches)
                                 • memory/episodic.jsonl (patterns)

Memory Capacity and Saturation

Unlike heuristic memory accumulation systems (Reflexion, Voyager) that can suffer from context saturation, A-Evolve's approach to memory is qualitatively different:

1. Memory is structured, not raw text. Episodic entries have schema (content, category, metadata). Skills have YAML frontmatter + procedural content.

2. Memory is curated by the evolution engine. The engine doesn't just append — it synthesizes, refactors, and prunes. This addresses the diminishing returns problem of naive memory accumulation.

3. Memory is bounded by workspace size. The file system imposes natural limits, and the agent reads only the last N entries during solve-time. This prevents context overflow.

4. Skills amortize memory. Recurring failure patterns are compiled into permanent skills rather than remaining as raw episodic traces. This is the key compositional principle in action — fragile reasoning is crystallized into reusable capability.

The amortization argument: A-Evolve's central memory insight is that memory should be consumed by the evolution engine to produce skills, not merely accumulated for the solver to re-read. This prevents the context saturation that plagues append-and-retrieve systems.

14 Continued Learning

Continual Deployment-Time Adaptation

A-Evolve's entire thesis is built on continued learning. The system is explicitly designed for open-ended, indefinite deployment horizons where the agent must adapt to:

The Three Scaling Axes

A-Evolve's theoretical framework positions evolution alongside two established scaling axes:

                        ┌──────────────────────────┐
                        │    CAPABILITY FRONTIER    │
                        │                          │
 Scaling Axis 1:        │   ┌──────────────────┐   │
 Training-Time ─────────│──▶│  Static ability   │   │
 Compute               │   │  (pre-training +  │   │
 (Kaplan et al.)       │   │   post-training)  │   │
                        │   └──────────────────┘   │
                        │            │              │
 Scaling Axis 2:        │   ┌────────▼─────────┐   │
 Inference-Time ────────│──▶│  Per-task         │   │
 Compute               │   │  reasoning        │   │
 (Snell et al.)        │   │  (CoT, search)    │   │
                        │   └──────────────────┘   │
                        │            │              │
 Scaling Axis 3:        │   ┌────────▼─────────┐   │
 Evolution-Time ────────│──▶│  Cross-episode    │   │
 Compute               │   │  adaptation       │   │
 (A-Evolve)            │   │  (skills, tools,  │   │
                        │   │   memory)         │   │
                        │   └──────────────────┘   │
                        └──────────────────────────┘

Convergence and Termination

The evolution loop terminates when any of these conditions is met:

1. EGL convergence: The Evolutionary Generality Loss stabilizes over the egl_window
2. Max cycles reached: Hard limit on evolution iterations
3. Perfect score: Training score reaches 100% (rare)
4. Budget exhausted: Compute budget for evolution-time is depleted

Long-Horizon Deployment Vision

The paper envisions A-Evolve running continuously in production:

Deployment Timeline
────────────────────────────────────────────────────────
Day 1:    Deploy seed agent (π_0)
Day 2-5:  Accumulate deployment evidence (Obs)
Day 5:    Evolution cycle 1 → add entity-verification skill
Day 6-10: More evidence; improved performance
Day 10:   Evolution cycle 2 → patch prompt, add memory patterns
Day 15:   API change detected → evolution cycle 3 → schema adapter
Day 20:   EGL converges → evolution pauses
Day 30:   New failure pattern → evolution resumes
...

Open question from the paper: Whether the evolution-scaling frontier P*(C_evolve) eventually saturates (suggesting fundamental limits to non-parametric adaptation) or continues to improve (suggesting that evolution can substitute for retraining). The authors present this as an empirical question requiring longer-horizon experiments than current benchmarks support.

Relationship to Other Continual Learning Paradigms

15 Applications

Current Applications (Demonstrated)

Potential Applications (Framework Affordances)

Because A-Evolve is a framework with pluggable agents, benchmarks, and algorithms, it can in principle be applied to any domain where:

1. Tasks can be automated (agent can attempt them)
2. Evaluation signal exists (success/failure can be measured)
3. Agent state is file-representable (prompts, skills, tools, memory)

Comparison with Other Evolutionary Systems

Key Differentiators for Applications

A-Evolve's unique position in the evolutionary AI landscape is that it evolves agents (the deployed system's behavior) rather than programs (standalone code solving a specific problem). This means:

1. The mutation target is the deployment-time policy, not a static algorithm
2. Evolution happens during deployment, not in a separate research loop
3. The evolver is itself an agent, not a fixed pipeline — it can adapt its own strategy
4. Governance is built-in, not bolted on — the validation registry and git integration ensure safety
5. The framework is agent-agnostic — it can evolve any system whose state lives on the file system

Limitations and Open Questions

This analysis is based on the arXiv paper (v2, February 2026), the open-source repository (March 2026), the MarkTechPost coverage and tutorial (March 2026), and the Hugging Face paper page. The A-Evolve framework represents a significant conceptual advance in how we think about LLM system improvement — shifting from manual prompt engineering and static training to autonomous, governed, deployment-time evolution. Whether the Evolution-Scaling Hypothesis holds at scale and across diverse production environments remains the central open empirical question.