What is recursive self-improvement in AI?
An AI can retry a task without getting better at solving the next one. Recursive self-improvement asks a harder question: can a change improve the process that makes future changes?
Updated
The definition, without the hype
Recursive self-improvement is a process in which an AI system changes part of itself, and the improved system contributes to further improvements. The changed part could be model weights, code, tools, a search policy, or the process used to run experiments. The important point is that the change reaches the machinery of improvement.
Consider a coding agent that proposes a better patch tool. An independent test finds that the tool helps on unseen tasks. The next agent version uses that tool to develop and test further changes. That is a candidate recursive loop. An agent writing five answers and picking one is just a search over answers unless the result also changes how future search works.
We use the term as a claim to test, not a promise of endless progress. A system may improve for a few rounds and then stall. Gains can disappear when tasks change, costs rise, or a hidden bug in the evaluator is fixed.
- Propose
- Change the system
- Test
- Check independent evidence
- Retain
- Use the change next time
What counts as self-improvement?
Start by naming the thing that persists after a task ends. A longer conversation, a new file, and a new model are different forms of state. None alone establishes that the system will solve new tasks better.
| Loop | What changes | Evidence to ask for |
|---|---|---|
| Retry or reflection | The current answer or plan | Does this answer pass? |
| Memory or retrieval | Context available to later tasks | Do relevant memories improve held-out tasks? |
| Fine-tuning | Model weights or an adapter | Does the trained model beat the baseline? |
| Agent code evolution | Tools, scaffolding, or search code | Do new versions improve under equal budgets? |
| Recursive improvement | Part of the improvement process itself | Does that change help produce further gains? |
What the research demonstrates
Sakana AI's Darwin Gödel Machine experiments explore agents that modify their own code and keep an archive of variants. Google DeepMind's AlphaEvolve combines proposed programs with automated scoring. These are useful examples of measured search and code improvement, with different targets.
Neither example licenses a claim that any agent will improve forever or autonomously build a more capable foundation model. Read what was changed, which tasks were scored, and which resources were held fixed. A reported result belongs to that setup.
Design your first loop around one failure
Our starting point would be one recurring failure: an agent loses a file path, cannot recover from a compiler error, or spends its whole budget testing the wrong patch. Save real examples of that failure. Reserve some tasks for development and keep another set away from the proposer.
Give each candidate a parent version, an exact patch, a fixed budget, and a result record. Test candidates in a separate environment. The candidate should not be able to edit the grader, test data, budget limit, or evidence log. Preserve failed runs as well as wins so the next round can learn from actual outcomes.
Use a simple baseline such as the original agent with the same total token and execution budget. Then compare the modified agent against that baseline on the reserved tasks. If the new agent merely spends twice as much, the result answers a different question.
- Define one target and the parts that may change.
- Freeze a baseline, evaluator version, and task split.
- Record candidate lineage, raw results, cost, and failures.
- Promote only after independent checks; keep a way to restore the prior version.
Why apparent improvement can be misleading
The search may learn the test instead of the task. If you run enough candidates against the same held-out set and choose the winner, that set has become part of development. Keep a final untouched check and report how often each dataset influenced selection.
A faster agent may also skip work. Test output, tool receipts, and completed artifacts matter more than a convincing summary. A narrower agent can win the benchmark while losing capabilities that the benchmark never checked. Include a small set of known-good tasks to catch those regressions.
What stops a recursive loop from improving forever?
Better candidates do not guarantee a better way of finding candidates. A loop can exhaust its budget, run out of useful proposals, or optimize a score that no longer reflects the task. A flat trace alone does not tell you which happened. Record the stopping condition as carefully as the winning score.
Here is a deliberately constructed counterexample you can run locally. Each candidate is six bits. Its score is 6 for 111111; otherwise it is 5 minus the number of ones. Higher is better. The search tries all six one-bit changes, keeps the first highest-scoring neighbor only if it improves the score, and stops when a complete neighborhood offers no improvement. Scores are exact integers; there is no measurement noise.
From 110000, the accepted scores rise from 3 to 4 to 5. The search then stops at 000000 after 19 score evaluations, including the starting point and repeated candidates. Every one-bit neighbor scores 4, yet 111111 scores 6. Raising the allowed budget from 25 to 49 changes nothing: the stopping rule fires before either budget is exhausted. Starting at 111110 instead reaches 111111. These starts were chosen to explain the mechanism, not sampled to estimate a success rate.
| Start / allowed evaluations | Evaluations used | Final score / stop |
|---|---|---|
| 110000 / 25 | 19 | 5 / no better neighbor |
| 110000 / 49 | 19 | 5 / no better neighbor |
| 111110 / 25 | 13 | 6 / no better neighbor |
python3 search-plateau.py > my-plateau-report.json- Download the runnable search-plateau.py
- Inspect our complete trace and all 64 candidate scores
- Build an independent evaluator before testing agent changes
This is a hand-designed local-search example, not an AI benchmark, OpenEvolve reproduction, or evidence against recursive self-improvement. The policy never changes itself. The separate exhaustive check costs 64 evaluations and establishes the optimum only for this tiny space; it is not a budget-matched competitor.
Diagnose the plateau before buying more compute
The report includes every evaluated neighbor, each accepted parent, the exact objective, budgets, and source/input hashes. In this example, more allowed evaluations cannot help because the same policy stops at the same point. Larger changes, restarts, or accepting temporary regressions could change that behavior, but this run does not compare their effectiveness.
For an agent experiment, distinguish a hard budget limit from a lack of accepted proposals, invalid outputs, and evaluator uncertainty. Optimizers also distinguish iteration limits from convergence criteria: SciPy's differential evolution documentation, for example, specifies both. Its algorithm is different from this toy search. A stopping condition is a rule for ending a run, not a universal certificate that no better solution exists.
To test the recursive claim, change the proposal or evaluation machinery and compare how well the resulting system discovers further useful changes on reserved tasks, under the same total budget. Count the cost of finding that machinery too. A human switching strategies after inspecting this toy landscape would be a manual intervention, not demonstrated autonomous self-improvement.
Does recursive self-improvement imply AGI?
No. Improvement in a bounded code search does not establish general intelligence, unbounded growth, or an intelligence explosion. Those are separate hypotheses. The practical question is smaller: did this version help produce another useful version, under a fair comparison?
You do not need your own GPU to test a small tool or prompt change. Local tests and a hosted model may be enough. GPU compute becomes relevant when the candidate must run tensor code, serve a local model, or train an adapter. Choose compute after you define the experiment.
References
Keep the experiment inspectable
A research loop needs files, run history, and evidence that survive its compute session. Start with Meshia's workspace guide and map those records before running a search.
Read the workspace guide →