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.
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 →