ML-Evolve: A Self-Evolving Agent System for Algorithm Optimization

How we built a self-evolving agent system that automatically researches, mutates, tunes, and improves ML algorithms — without a human in the loop. Think of it as an AI research assistant that works through the night, tests competing ideas in parallel, and leaves a complete audit trail of every decision.

Github Project: https://github.com/roylist/ml-evolve

1. The problem: your model is only as good as your last architecture search

If you’ve ever trained a machine learning model, you’ve been here: you pick a loss function, choose an encoder architecture, set a few hyperparameters, train, evaluate, and repeat. Maybe you run a grid search or let Optuna sample a few hundred combinations.

This works — up to a point. Standard tools like Optuna, Hyperopt, or AutoML handle the continuous knobs (learning rate, dropout, batch size) and can even pick between predefined model families (Random Forest vs. XGBoost vs. MLP).

But there’s a third dimension that none of these tools address: structural innovation.

What if the best architecture for your problem isn’t any of the standard options? What if you need a custom loss function that combines two existing ones? What if the latest paper from a top conference describes a technique that could boost your metric by 15% — but you’d need to implement and test it?

Historically, that’s been a human job. You read the papers, formulate hypotheses, implement them, run experiments, keep what works, discard what doesn’t. It’s slow, expensive, and hard to scale across multiple competing ideas.

ml-evolve automates this loop. It’s a self-evolving agent system that takes AlphaEvolve’s evolutionary paradigm — treat algorithm search as code mutation — and rebuilds it as a production-ready framework for ML optimization.

Instead of a single optimization algorithm, it orchestrates three specialized agents that collaborate to improve your model:

• Plan Agent Reads papers, tech blogs, and leaderboards; writes a research plan with grounded hypotheses for each competing approach. Runs once at startup, then periodically to refresh stale directions.
• Mutation Agent Edits the core algorithm — architecture, loss function, training logic — based on performance data and the research plan. Runs once per generation, per competing branch.
• Parameter Agent (powered by Optuna TPE) Runs Bayesian search over numerical parameters for each proposed architecture; reports when further tuning is pointless. Runs dozens of trials per architecture mutation.

This three-agent design puts LLM-driven structural evolution and TPE-driven numerical optimization into a single self-improving loop — auditable, resumable, and compute-aware.

2. What we optimized for

Before diving into the architecture, here is the design brief — the constraints that shaped every decision:

Deployable in production, not just a notebook. Every prompt the agent sees is written to disk as a file. State is serialized and resumable across machines. You can kill the process, restart on a different GPU, and pick up exactly where you left off.

Works for any ML problem, not one domain. The framework body contains zero domain knowledge. All task-specific info lives in a single YAML file. The same loop drives optimization for recommendation, ranking, tabular data, reinforcement learning, prompt engineering — anything with a scalar metric.

Compute-aware by design. Instead of running every candidate at full cost, the system uses multiple evaluation tiers: cheap proxy → medium validation → full test. Only candidates that win at each tier consume more compute. This is built in, not bolted on.

Prevents premature convergence. Multiple independent research branches explore competing hypotheses in parallel. Periodic replanning retires dead ends and injects fresh directions. The system deliberately avoids converging too early on the first plausible idea.

Two-level search, one loop. Architecture changes and parameter tuning are handled by different agents using different tools — no single optimization algorithm has to be good at both.

3. Architecture: Self-Evolving Agent System

The system operates as three coordinated agent layers, each with a distinct responsibility. Here’s the full flow, from strategy to execution to feedback:

Layer 1: Strategic Direction

The Plan Agent reads recent papers and conference proceedings, then writes a research plan. Each island gets its own hypothesis, kill criteria, and model family hints. The plan is a markdown file — editable, version-controllable, auditable.

Layer 2: Parallel Evolution (×3 islands)

Each island runs an independent evolution loop. Islands are deliberately isolated — a dead end in one doesn’t drag down the others.

Each iteration:

1. Select a parent from the island’s elite.
2. The Mutation Agent edits the candidate.
3. The Parameter Agent runs TPE trials.
4. Score the result.
5. Update the leaderboard.

Layer 3: Evaluation & Advancement

Once candidates from all islands are scored:

• Evaluator Runs the candidate on a fixed evaluation protocol: data splits, metric computation, seed averaging. Candidates never touch this logic.
• Stage Gate small → medium → full → final. Only candidates that win at each stage consume more compute. This catches architectures that overfit to cheap evaluation early.
• Leaderboard + Archive Stores the best candidates per island with full evaluation history. Used by the Plan Agent for replan decisions.

Layer 4: Meta-Learning (Feedback Loop)

The replan step is the system’s anti-collapse mechanism. Without it, all islands eventually converge to the same lineage. The Plan Agent revises its own search strategy — the meta-cognitive loop that makes this a self-evolving system, not just a genetic algorithm with extra steps.

The replan decision per island is:

• KEEP — sharpen the hypothesis
• REFRESH — plateau detected, new direction in the same space
• RETIRE & REPLACE — dead end, inject a new branch

3.1 The task spec contract

A user authors one YAML file. That file is the only way information enters the loop. The framework explicitly refuses to inject domain knowledge from its own prompt.

3.2 The loop

At a high level, the system runs through these phases:

1. Setup Verify the environment, initialize the run directory, create the island structure.
2. Plan The Plan Agent reads the task spec and leaderboard, researches current literature, and writes a research plan with one hypothesis per island.
3. Per-generation loop Repeated until budget is exhausted:

• Select & Mutate — for each island, pick the best-performing parent candidate and ask the Mutation Agent to propose a structural improvement.
• Parameter search — run Optuna TPE trials on the new architecture to find optimal numerical parameters.
• Promote — every K rounds, re-evaluate top candidates on a more expensive evaluation stage to catch overfitting.
• Replan — every M rounds, check branch health per island; retire dead ends, refresh stalled branches, inject new directions.

The key insight: every decision in this loop is recorded as a readable file. You can replay why any choice was made, six months later, without needing to re-run anything.

3.3 Why every decision is auditable

Every piece of context the agents see is written to disk as a plain-text file — not buried in an API log or a database. This means:

• The Plan Agent’s research memo A file containing the leaderboard, per-island health metrics, and the current strategy. The agent reads this, does web research, and writes an updated strategy document.
• The Mutation Agent’s brief A file containing the parent candidate’s performance, saturation signals from the last parameter search, and the relevant slice of the research plan. The agent reads this and edits the candidate code.
• The evaluation log Every score, every trial, every promotion event — append-only, machine-readable.

Two practical benefits:

Full audit trail. Six months from now, you can ask “why did we abandon branch 1?” and the answer is sitting in a plain-text file in the run directory.

Engine independence. The system doesn’t care which LLM reads the files. Claude, GPT, an open-source model, or even a human manually editing the code — they all work without changing a line of orchestration code.

3.4 Islands and replan

Each island maintains its own family of candidates. The selector samples a parent from the island’s elite + archive, with a configurable exploitation ratio. Branch health is computed from:

• Best-score trend over the last K generations
• TPE saturation: did the last batch’s late_best — early_best stay within min_improvement?
• needs_new_branch flag if the island's best is below 50% of the global best for N generations

When replan_every triggers, the Plan Agent is shown per-island health and must decide for each island:

• KEEP — sharpen hypothesis but keep concept
• REFRESH — plateau detected; replace hypothesis with a different direction in the same problem space
• RETIRE & REPLACE — proven dead end; introduce a structurally new branch

This is the framework’s anti-collapse mechanism. Without it, all islands eventually converge to the global best lineage.

3.5 Two-level search

The mutation prompt makes the contract explicit:

The candidate file must declare a module-level PARAM_SEARCH_SPACE dict. After your structural changes, rewrite PARAM_SEARCH_SPACE so every dotted path resolves against the new build_candidate() config.

The agent’s job is to design the parametric family. Optuna’s job is to find the best parameters within that family. Past TPE results are surfaced in the next mutation request:

Previous TPE batch on this island: {trials: 8, best_score: 0.135, slope: -0.0002, saturated: true}

High trials with slope <= 0 and saturated: true mean the prior structure is tapped out; prefer a materially new structural direction this iteration.

So saturation is the explicit signal for when to spend an architectural mutation vs. another parameter sweep.

3.6 Stage promotion

The system uses multiple evaluation tiers, typically:

• a quick smoke test
• a small-scale evaluation
• a medium-scale validation
• a full final evaluation

The evaluator knows which stage it’s running and adjusts its protocol accordingly. When the promotion gate triggers, top candidates from the cheap stage are re-evaluated at the next tier. This catches architectures that look good on small data but degrade at scale — early and cheaply.

This is critical: a structural mutation that looks great at small scale may fail at medium scale because the small stage favors low-data regimes. Promotion gates surface that misalignment early and cheaply.

4. A real run: what this looks like in practice

Here is what an actual run looks like. The task was a sequential ranking model — given a user’s history, predict which items they’ll interact with next. Three competing architectural families, 9 generations, single T4 GPU, about 3 hours.

• Generation 1 — Best score: 0.087 Baseline model — standard encoder with cross-entropy loss
• Generation 3 — Best score: 0.1336 Branch 2 discovers a graph-enhanced encoder + modified loss combo — a 53% jump
• Generation 6 — Best score: 0.1353 TPE converges on branch 2’s best architecture; saturation detected
• Generation 8 — Best score: 0.1350 Branch 1 (attention-based encoder) catches up via a different structural path
• Generation 9 — Best score: 0.1353 All three islands within 0.5% of each other; budget exhausted

54 candidates evaluated total, ~3 hours compute, no human intervention.

The mutation request that triggered the breakthrough at generation 6 contained:

• Saturation signal: branch health showed 8 TPE trials with near-zero improvement slope
• Prior TPE results: a key hyperparameter was pegged at the upper edge of the search range — hint to widen it
• Research plan excerpt suggesting a warm-start initialization technique

What the agent did in response: changed the aggregation method, added the warm-start technique, widened a hyperparameter range, and kept the search space compact. TPE then found the optimal numerical configuration for this new architecture.

This pattern repeats across runs: the saturation signal tells the agent when to stop tuning and start redesigning. The agent acts, TPE finds the new optimum, and the cycle continues.

5. How ml-evolve relates to AlphaEvolve

AlphaEvolve (DeepMind, 2024–2025) is the closest published system and the direct intellectual ancestor of ml-evolve. It is a code-evolution framework that uses Gemini to mutate programs guided by automated evaluators, and has produced novel results in matrix multiplication, data-center scheduling, and Google-internal algorithm improvements.

ml-evolve is the first framework to take AlphaEvolve’s evolutionary paradigm and rebuild it as a self-evolving agent system for ML tasks — bringing multi-island evolution, agent-driven research, and TPE-accelerated parameter search out of Google-scale infrastructure and into a production-ready agent architecture.

Where AlphaEvolve focuses on general-purpose algorithm discovery, ml-evolve targets the specific needs of ML optimization: noisy scalar evaluators, expensive training pipelines, and the need for a self-improving agent loop that can be audited and deployed.

The shared lineage is real. Both systems:

• treat algorithm search as code mutation, not just hyperparameter optimization
• score every candidate with a deterministic evaluator
• maintain a population with diversity controls
• iterate propose → evaluate → select

5.1 What AlphaEvolve optimizes for

• Scale — Gemini’s mutation throughput is enormous; AlphaEvolve runs thousands of evaluations per problem.
• Closed loop — orchestration, mutation, and evaluation are owned end-to-end by DeepMind infrastructure.
• Reach — it has been demonstrated on a wide variety of optimization problems, including ones with formal verifiers and noisy ML evaluators.

5.2 What ml-evolve optimizes for

ml-evolve redesigns the evolutionary paradigm as a three-agent self-evolving system, each agent optimized for a distinct role in the ML improvement loop:

• Three-agent architecture A Plan Agent (research + strategy), a Mutation Agent (Claude, structural edits), and a Parameter Agent (Optuna TPE, numerical optimization). This decoupling lets each agent specialize.
• Cost per run ml-evolve assumes a single workstation or a small cluster. A run is hours, not days; tens of candidates, not thousands. The two-level split (LLM = structure, TPE = parameters) is critical for this regime.
• Single agent, no proprietary infra The orchestration is a 1,800-line Python script and a markdown skill. The agent can be Claude Code, an API call, a human, or any tool that can read a markdown file and edit Python.
• Auditability as a first-class concern Every prompt is a file. AlphaEvolve’s prompts are constructed inside its serving stack; for an external researcher reading a paper, they’re a black box. For ml-evolve, the trajectory is on disk and reviewable line by line.
• Explicit research grounding The mutation prompt mandates web search and requires citations. Mutations are required to cite sources.
• Stage promotion baked in AlphaEvolve has progressive evaluation as a configuration choice. ml-evolve’s task spec contract makes it a required field — you must declare a stage hierarchy.

5.3 Where ml-evolve is materially weaker

• No formal verification
• No mass parallelism
• No automatic code minimization or certification of improvements
• A winning candidate is a Python file, not a theorem

The honest framing: ml-evolve is “AlphaEvolve redesigned as a self-evolving agent system for practical ML deployment — bringing multi-island evolution, agent-driven research, and TPE-accelerated parameter search to the case where an ML engineer wants to run autonomous algorithmic improvement on a real problem, and needs to explain every step to their team.”

6. How ml-evolve relates to Karpathy’s AutoResearch

AutoResearch is Andrej Karpathy’s recent project: “give an AI agent a small but real LLM training setup and let it experiment autonomously.” It is the closest spiritual relative to ml-evolve: both are file-based, agent-driven research loops designed to run autonomously for hours without supervision.

The critical distinction is that ml-evolve inherits AlphaEvolve’s multi-island evolutionary architecture, while AutoResearch uses a single-stream greedy loop. On multimodal ML landscapes — the norm for production ML problems — this difference is decisive.

6.1 AutoResearch in one paragraph

Three files: prepare.py (data, frozen), train.py (the single file the agent edits — full GPT model, Muon + AdamW optimizer, training loop), program.md (agent instructions and research directives). Each training cycle runs for exactly 5 wall-clock minutes. The agent reads program.md, edits train.py, trains, evaluates on validation bits per byte, then decides keep or discard.

6.2 The shared vision

Both ml-evolve and AutoResearch agree on:

• The agent is the proposer, not the orchestrator
• Instructions live in markdown files, not in a hidden system prompt
• A frozen evaluation contract prevents the agent from cheating its own metric
• Wall-clock economy matters
• Reproducibility-by-disk matters

6.3 Side-by-side

AutoResearch

• Domain: LLM pretraining on a fixed dataset
• Editable surface: the entire training script
• Search topology: single sequential stream
• Diversity mechanism: implicit
• Parameter vs. structural search: conflated
• Per-trial compute budget: fixed 5-minute wall clock
• Cost-aware promotion: none
• Decision unit: keep-or-discard a single run
• Halt criteria: run overnight / human kill
• State persistence: Git commits + run artifacts
• Research grounding: whatever the human-written strategy document says
• Metric: val_bpb
• Loop driver: shell loop calling the agent

ml-evolve

• Domain: domain-agnostic — retrieval, ranking, tabular, RL, prompt programs, schedulers
• Editable surface: only the algorithm core
• Search topology: multi-island population with archive
• Diversity mechanism: explicit
• Parameter vs. structural search: decoupled
• Per-trial compute budget: stage hierarchy
• Cost-aware promotion: promotion gates
• Decision unit: population update with archive and elite selection
• Halt criteria: explicit iterations / target score / patience
• State persistence: full serialized state, resumable across sessions and machines
• Research grounding: mandatory web research in every mutation prompt
• Metric: user-defined primary score
• Loop driver: modular Python commands

6.4 What ml-evolve optimizes relative to AutoResearch

These are deliberate additions to handle failure modes that emerge when you run a single-stream, edit-everything loop on tasks more complex than nanoGPT pretraining.

• Multi-island evolution This is the primary structural difference. AutoResearch follows one trajectory with accept-or-rollback — a greedy hill climber. ml-evolve maintains multiple independent research branches with periodic replan. On multimodal ML landscapes, this is decisive.
• Parameter sweeps belong to TPE, not the agent On a realistic ML task where each evaluation takes minutes and involves multiple continuous hyperparameters, the agent should not spend its attention on brute-force search. ml-evolve pushes the LLM out of the loop for parameter search and lets Optuna TPE do what it’s good at.
• Saturation is a first-class signal AutoResearch’s agent sees its own run history but has no explicit telemetry telling it when the structure is tapped out. ml-evolve computes this from TPE’s trial-by-trial best-score series and injects it into the next mutation prompt.
• Stage hierarchy lets you spend compute where it matters ml-evolve requires you to declare cheap-to-expensive stages and which stage drives the inner loop. Promotion re-evaluates winners at higher cost, so structural mutations that look good at small but degrade at medium are caught early.
• Web research is enforced per mutation AutoResearch can ask for research in program.md, but it is a request. ml-evolve's mutation prompt has a required “Research Before Editing” section that demands citations and rejects mutations that aren't grounded in recent evidence.
• Domain-agnostic by construction AutoResearch is purpose-built for LLM pretraining. ml-evolve was designed so that swapping the task specification, the evaluator function, and the initial candidate program is enough.
• Resumability across sessions and machines AutoResearch’s state lives in Git commits and run logs. ml-evolve’s state is fully serialized — population, archive, saturation metrics, evaluation history, everything.
• Industrial-grade audit trail Every decision in the loop is saved as a readable file. This is required for deployment in production ML pipelines where every algorithmic decision must be explainable.

6.5 Where AutoResearch is stronger

• Ergonomics on a well-posed task
• No premature commitment to a search structure
• Real-time iteration speed on small models
• Designed for the LLM-pretraining domain it targets

The honest framing: AutoResearch and ml-evolve are siblings, not competitors. AutoResearch optimizes for a single, well-bounded, single-stream search. ml-evolve optimizes for a production ML optimization problem with a noisy scalar evaluator, a compute budget, multiple plausible architectural families, and a need to explain every decision six months later.

7. Summary: what we built and why it matters

ml-evolve is a self-evolving agent system for ML algorithm optimization — not an academic experiment, but a production-ready framework where three specialized agents collaborate to continuously improve your model.

The key design decisions:

• Two-level search — an LLM handles structural mutations, while Bayesian optimization handles parameter tuning.
• File-based audit trail — every prompt is a file on disk. Every decision can be replayed and reviewed, six months later.
• Multi-island evolution — inherited from AlphaEvolve. Multiple competing hypotheses evolve in parallel, with structured replanning to retire dead ends and inject fresh ideas.
• Compute gating — cheap evaluation first, expensive evaluation only for winners.
• Research-grounded mutations — the plan agent must read and cite recent sources.
• Saturation-driven timing — TPE telemetry tells the mutation agent when to stop tuning and start redesigning.
• Domain-agnostic — one framework, any ML problem.
• Production-ready — resumable across machines, no proprietary infrastructure, works with any code-editing LLM.

The result, in one real run: a 53% improvement in the primary metric, 54 candidates evaluated, about 3 hours on a single GPU.

8. Closing: self-evolving agents for production ML

ml-evolve is a self-evolving agent system — the first framework to bring AlphaEvolve’s evolutionary paradigm into a closed-loop agent architecture designed for industrial ML deployment:

• three specialized agents collaborate in a self-improving loop
• multi-island evolution provides multimodal coverage and prevents premature convergence
• agent-driven research grounds every mutation in current literature
• TPE-accelerated parameter search with explicit saturation feedback tells each agent when to act
• every prompt is a file — audit trail as a first-class requirement, not an afterthought

It is not a replacement for AlphaEvolve at scale, nor for AutoResearch’s tight five-minute loop on the nanoGPT-pretraining domain it targets. It is the right tool when you have a production ML optimization problem: a noisy scalar evaluator, a few hours of GPU, multiple plausible architectural families to compare, and a need for a self-evolving agent system that can explain every decision.

The framework is open-sourced under the ml-evolve skill. Contributions, alternative task specs, and case studies welcome.