Self-improving agents: what "self-improving" has to mean to be a claim

Analysis

Self-improving agents: what "self-improving" has to mean to be a claim

"Self-improving" is doing a lot of work in a lot of announcements. It is worth separating the versions that are ordinary engineering from the versions that would be remarkable.

A concrete spiral staircase photographed from below

Published

July 13, 2026

Reading time

3 minutes

Perspective

Analysis

Topics

agents · rl · evaluation

Prime Agent, described as a self-improving RLM agent, drew a large audience on Hacker News this week. The reception is a good moment to be precise about what the phrase can mean, because it spans several mechanisms with very different implications.

Four things "self-improving" is used to describe

1. Accumulating context. The system keeps notes from past runs and retrieves them later. This is memory. It is useful and it is not learning — remove the store and the system is exactly as capable as before.

2. Optimising its own prompts or scaffolding. The system edits the instructions or the tool descriptions it operates under, keeping variants that score better. Real, measurable, and bounded by the search space you gave it.

3. Generating its own training data. The system produces trajectories, filters them by some verifier, and trains on the survivors. This is where actual capability gain can happen, and the entire result depends on the quality of the verifier.

4. Modifying its own training procedure. The system changes how it learns, not just what it learns from. This is the version that would be genuinely notable, and it is the rarest.

Announcements frequently describe (1) or (2) in language that implies (4).

The verifier is the whole game

For version (3) — the practically important one — the mechanism is straightforward: generate, filter, train, repeat. The subtlety is entirely in the filter.

If the verifier is sound, the loop concentrates probability mass on correct behaviour. If the verifier is exploitable, the loop concentrates probability mass on exploiting the verifier, and does so efficiently, because that is what optimisation does.

This is why self-improvement results are so sensitive to domain. In code, you can run the tests. In theorem proving, you can check the proof. In open-ended research or writing, the verifier is usually another model, and a loop that trains against a model judge is training against that judge's blind spots.

The questions that separate a result from a demo

  1. What is the verifier, and could the agent satisfy it without doing the task?
  2. Was improvement measured on a held-out set the loop never touched? Self-improvement measured on the same distribution the loop optimised against is circular.
  3. How many iterations before it plateaus? Every published loop plateaus. Where is the interesting part of the claim.
  4. Does it degrade anything? Gains on the target task alongside quiet losses elsewhere are common and often unreported.

Why the framing matters

Recursive self-improvement is one of the field's oldest and most loaded ideas, and the phrase carries all of that weight into announcements that usually describe something considerably more modest. That is not dishonest — the mechanisms genuinely sit on a spectrum — but it makes the literature hard to read.

The useful habit is to translate every "self-improving" claim into which of the four it is, before evaluating whether the result is surprising.

Continue reading

More from COREXA