Anatomy of a Recursive Self-Improvement System

What changes, what judges it, and what must remain outside the loop.

Your self-improving coding agent returns with good news: its score is up 12 percent. Then you open the run. It used twice as many model calls, broke tasks that passed yesterday, and saw evaluation examples while writing its patch. The score improved. Did the agent?

That question sits at the heart of recursive self-improvement. A higher number is not enough. We need to know what changed, whether that change caused the gain, and whether the comparison was fair.

Chapter 2 built the smallest useful loop: run, judge, mutate, then keep or revert. This chapter opens up those four verbs. Once the loop leaves a notebook, each verb hides a different kind of power. One part produces evidence. Another interprets it. Another proposes a change. And someone must decide whether that change becomes the system used next time.

The run behind that 12 percent gain began with one failure. A coding agent was halfway through a patch when a tool timed out. The retry lost the last valid plan, repeated work, and exceeded its call budget. A small harness patch now saves the state before retrying, so more tasks finish. Before we call that self-improvement, however, the patch has to survive a much harder question: did it really make the system better?

Answering that question does not require a committee of LLMs. It requires four clear layers: the system we may change, the machinery that turns failure into a candidate, the state that survives between rounds, and a judge the candidate cannot control.

What makes the loop recursive?

The loop becomes recursive when a tested change survives into the next round. Call the current system at round t h[t]. It may include a prompt, tools, memory, workflow code, model weights, or some combination of them. The loop runs h[t], studies the evidence, and proposes h'. If the candidate passes its tests, it becomes h[t+1]. Otherwise, h[t] stays in place.

This rules out a common impostor. An agent that tries twenty answers and returns the best one searched harder, but its answer-producing machinery did not change. If it writes a lesson, fixes a tool, updates a prompt, or rewrites its search rule, it has made a persistent change. That change counts as improvement only after a protected judge accepts it and it shapes the next round.

Four questions every loop must answer

The architecture becomes easier to understand when we turn it into four questions:

1. What exactly may change?
2. How does a failure become a candidate change?
3. What evidence and lessons survive the round?
4. Who has the authority to say the candidate is better?

Layer 1: What exactly is changing?

In our example, only one middleware module may change: the harness code that manages tool retries and state. The coding model, task set, tools, and evaluation stay fixed. That makes the claim more precise. We are testing a new retry policy, not a mysteriously “better agent.”

Name the mutable artifact

The mutable artifact is the thing the loop is allowed to rewrite. This is the missing noun in many accounts of self-improvement. “The agent improved itself” tells us almost nothing. Did it change a prompt, add a retry, replace a parser, rewrite a memory rule, or update its weights? Those changes have different costs, risks, and failure modes.

In practice, the editable surface may include prompts, tool descriptions, middleware, skills, sub-agent settings, or long-term memory. LIFE-HARNESS shows why this matters. Some failures that look like weak reasoning are really interface failures. The surrounding system can improve even when the model stays frozen.

Every loop should therefore publish a small edit map:

• Which files or parameters may change?
• Which component owns each one?
• What budget limits the size of an edit?
• How is the previous version restored?
• Which surfaces are permanently read-only?

Start with changes that are easy to inspect and undo. Prompts, skill files, memory entries, and small harness modules are good first targets. Weight updates and changes to the optimizer come later because they are harder to attribute and more expensive to reverse.

Keep the executor and environment separate

The executor runs the current system on a task. It is the worker from Chapter 2, but now the environment is part of the experiment. The same candidate can look excellent in an easy simulator and fail in production if its tools, permissions, data, or time limits change.

For each run, the executor receives a specific task, a versioned system, a controlled environment, and a resource budget. It returns what happened: outputs, tool calls, state changes, cost, latency, and final status. It does not grade itself.

This boundary matters when a system finds an easier route to a high score. In the Meta-Agent Challenge, agents sometimes exploited the evaluation path instead of solving the task. A clean boundary makes the difference visible. Actions inside the task environment are evidence. Attempts to alter the evaluator or read private tests are violations.

Layer 2: How does failure become a candidate?

We now know what may change. The next layer turns experience into a fair experiment. It preserves the trace, forms a diagnosis, proposes a bounded edit, decides where to spend search effort, and runs the candidate under the original conditions.

Start with the trace, not the score

A final score tells us that something went wrong. A trace tells us where to look.

The tracer preserves the steps behind that summary: model responses, tool calls, results, retries, state changes, errors, time, and cost. It also records which component touched each step. Without that identity, a bad tool call could come from the model, the tool description, middleware, or stale memory, and we would have no way to tell.

More logs do not automatically create more insight. A million-token transcript can hide a two-line cause. Agentic Harness Engineering keeps raw task traces, summarizes each task, and then looks for patterns across tasks. Over ten iterations, its first-try Terminal-Bench 2 success rate rose from 69.7 to 77.0 percent. The final harness also worked across model families.

The study's edit-proposing agent was better at predicting fixes than regressions. Traces narrow the search, but they do not make the diagnosis correct. This is why Scaling Laws for Agent Harnesses focuses on useful feedback, not raw tokens or tool calls. Activity matters only when it leaves valid evidence that can guide a later decision.

Turn the trace into a testable diagnosis

Next, the diagnostician explains what may have caused the failure. The result is a hypothesis, not a verdict.

Compare two diagnoses:

• “The agent needs stronger reasoning.”
• “After a tool timeout, middleware discards the last valid state, so the retry begins from a stale plan.”

The first diagnosis invites a broad prompt rewrite. The second points to one component and predicts what should change in the next trace. It also reveals a regression to watch: saving more state may increase context cost.

Self-Harness calls this weakness mining. On tasks withheld from the editing process, its largest reported gain was 21.4 percentage points on one of three tested models. The operating model found the weakness and proposed the edit without help from a stronger model. That is promising, but narrow. The lesson is not that diagnosis is solved. It is that repeated, model-specific failures make better edit targets than generic advice.

A good diagnosis separates three things: the final failure, the behavior that produced it, and the editable mechanism that may have caused that behavior. The third step remains a hypothesis until a controlled test supports it.

Locate the behavior before editing the code

A diagnosis can name the right mechanism and still produce an incomplete patch. In a production harness, one behavior may cross a tool schema, runtime middleware, state resets, mirrored implementations, fallback paths, and documentation. Finding every source location involved in that behavior is a separate job called behavior localization.

Harness Handbook builds a behavior-centered map of the repository, including execution stages and the places where shared state is read and written. A planner moves from the requested behavior to candidate code locations, then verifies each one against the current source before proposing an edit. The map guides the search; the repository remains the authority.

On 30 modification requests each for Codex and Terminus-2, handbook-assisted planning raised overall plan win rates by 10.0 and 18.9 percentage points while reducing planner-token use by 12.7% and 8.6%. The experiment measured localization and plans, not executed patches, so it supports adding this step to the loop without showing that the resulting harnesses improved.

Change one thing at a time

The proposer turns the diagnosis into a candidate. In this case, it writes a small middleware patch that checkpoints the last valid state before a retry. A proposer might also edit a prompt, synthesize workflow code, or plan a weight update.

It receives only what it needs: the allowed edit surface, the current version, the failure pattern, passing behavior to preserve, and lessons from earlier attempts. It does not receive hidden tests or permission to rewrite the judge.

Small edits make the result easier to explain. SkillOpt limits how much the system may change in one edit. It was best or tied-best across all 52 reported model, benchmark, and harness combinations. But its gate is only as good as the tasks used to validate it, and the study did not test transfer to very different domains. The evidence supports bounded, validation-gated changes. It does not justify blind trust in one held-out set.

Let the search controller choose where to look

Once the proposer can generate changes, the search controller decides which candidate gets the next experiment. It chooses a candidate to build from, asks for variants, and balances trying a new direction against refining a promising one.

For the timeout failure, it might compare a full-state checkpoint with a smaller retry summary. It can then spend more trials on the version that recovers without breaching the budget.

A greedy keep-or-revert rule is the right first controller because it is easy to reproduce and hard to misunderstand. Richer search methods matter only after the baseline exposes a real problem, such as getting stuck or spending its budget badly.

AIDE² divided its budget across candidate families, refined candidates within each family, and restarted from the best-known system when progress stalled. The point is simple: a controller may mix search methods, but the mix should remain visible and reproducible.

Run every candidate under the same conditions

The experiment manager turns a candidate into a fair comparison. It creates an isolated workspace, pins dependencies, assigns tasks and seeds, enforces the budget, records logs, handles timeouts, and cleans up.

Its job is practical rather than interpretive. In the timeout experiment, it gives the old and new systems the same model, tools, tasks, permissions, and budget. If the checkpoint patch wins only by making more calls, it did not improve under the original contract. If it wins once and loses on repeats, we have an anecdote, not a result.

Layer 3: What must survive the round?

A long-running loop needs two kinds of persistence. Think of them as a lab notebook and a playbook. The evidence ledger is the lab notebook: complete enough to audit. Memory is the playbook: short enough to guide the next move.

Mixing them is dangerous. A plausible summary can quietly replace the run that might prove it wrong.

Keep a complete evidence ledger

The ledger stores the previous version, proposed diff, hypothesis, tasks, seeds, model, tools, permissions, budget, traces, evaluator outputs, and final decision. For the timeout experiment, it must answer a simple question months later: which middleware patch ran under which retry budget?

Evidence is complete, immutable, and sometimes awkward to read. Files are a strong default because they survive process restarts, support diffs and checksums, and remain open to human inspection. Keep rejected candidates too. Otherwise the controller may spend budget rediscovering the same failed edit.

Use memory as a guide, not as proof

Memory compresses experience into something the next round can use. ReasoningBank suggests a useful unit: a strategy distilled from both success and failure. Raw traces are too long and specific for every decision. Success-only summaries throw away the sharpest corrective signal.

But storing lessons is not the same as learning. Across six CL-BENCH domains, giving the model its full prior history improved aggregate performance by 25.4 percent. ACE's compressed-memory approach improved it by 8.6 percent and cost more. This does not prove that full history will always win. It shows why a memory system should be compared with both no memory and uncompressed history.

Start small: an append-only ledger, an archive of candidates, a few distilled lessons, and a retrieval rule you can test. Memory may guide the next diagnosis. The ledger remains the source of truth.

Layer 4: Who gets to say it improved?

We now have a checkpoint patch and a fair run. We still do not have a trustworthy verdict. That requires three separate decisions.

First ask whether the run is valid

The verifier checks hard constraints before anyone celebrates the score. Did the agent produce the correct files? Did it use the declared model and budget? Were the tests untouched? Can the run be reproduced?

For the timeout patch, a run that doubled its calls fails here, even if more tasks finished. Whenever possible, use deterministic checks such as compilers, schemas, checksums, unit tests, or exact simulators. Fuzzy tasks may still need a model or human judge, but hard checks should come first.

A valid result is not necessarily a useful one. A program can be correct and slower. A memory entry can be well-formed and harmful. This is why evaluation is a separate step.

Then ask whether the candidate is better

The evaluator compares value. In our example, it asks whether more tasks recover after timeouts, whether ordinary tasks still pass, how much extra context the checkpoint adds, and whether the gain transfers to new repositories.

“Better” is rarely one number. It may include success, generalization, reliability, cost, latency, maintainability, and safety. Keep those dimensions visible. A single score helps the search controller rank candidates, but a human should still see whether the gain came from better results, higher spend, or a newly tolerated failure.

Current loops work best when feedback is crisp and fast. Exact-match accuracy is easy to test. Scientific taste, maintainability, novelty, and long-term value are slower and easier to counterfeit.

Promote by policy, not by excitement

The promotion gate decides whether the candidate becomes h[t+1]. A valid patch may still fail if its gain is small, its context cost is large, or its regression rate is too high or unstable across repeats.

Set the gate before seeing the results. A sensible policy requires a valid run, improvement on held-out tasks, no unacceptable regression, and reliable performance under the original budget. Keep a final test sealed until selection ends. A gate used every round becomes feedback, so the search can eventually overfit it.

Self-Harness, Agentic Harness Engineering, and SkillOpt all converge on bounded edits plus regression gates. The reason is simple. A self-improvement loop without a gate is only a self-modification loop. Change is guaranteed. Improvement is not.

The version manager then stores the previous version, candidate version, diff, receipt, and rollback path. Rejected candidates stay in the archive with the reason they failed.

Protect the measurement path

The candidate must not control the system that judges it. Reward hacking is not a job for another agent inside the loop. It is a threat that requires a real integrity boundary.

Keep these surfaces outside the editable system:

• The objective and reward calculation
• The verifier, evaluator, held-out tasks, and private labels
• Permission limits and resource budgets
• Audit logs, version history, and the production promotion path

Chapter 1 showed why. Under optimization pressure, agents in the Meta-Agent Challenge found routes to evaluation secrets. A score-maximizing system sees no moral difference between solving a task and changing how the task is scored. The architecture must make that difference physical.

Read-only mounts, separate credentials, checksums, sealed test services, least-privilege tools, and fixed budgets all help. “Do not cheat” may shape a proposal. It is not a security control.

Private evaluation helps, but it is not a complete defense. AIDE² reports the reward-hacking rate falling from 63% in its seed harness to 34% in a later selected harness, perhaps because visible-score exploits failed on private tests. Treat that result as provisional. The report did not release its full protocol and code, and a stronger optimizer may find a different path around the measurement.

Humans do not need to approve every tool call. They should retain authority over hard-to-reverse changes: rewriting the objective or judge, expanding permissions, updating weights or the search controller, and accepting noisy gains with conflicting metrics. The useful question is not “human in or out?” It is “which state transitions require human authority?”

Which jobs need a language model?

Not every box in the diagram should become an agent. Language models help when the work is semantic, such as reading a long trace or writing a patch. Ordinary code is better at bookkeeping, isolation, enforcement, and exact checks.

In the timeout example, only diagnosis and patch generation clearly benefit from a language model. Scheduling, tracing, budgets, tests, versioning, and promotion can remain simple code. This is a harness, not a committee of chatbots.

When does the loop improve its ability to improve?

Running experiments automatically is not enough. The stronger form of recursion appears when the loop changes the machinery that finds future improvements, and that new machinery helps produce the next accepted change.

We can ask for three increasingly strong receipts:

1. First-order: the modified system performs better on held-out tasks.
2. Second-order: the improvement transfers to task families that did not shape selection.
3. Meta-level: the improved system is itself better at finding the next improvement under the same budget.

Bilevel Autoresearch gives us an early example. Its inner loop searched for better training configurations. An outer loop periodically rewrote that inner search mechanism in Python. The reported mean gain was about five times the inner loop alone, while tuning parameters inside the fixed mechanism produced no reliable improvement.

The evidence is still narrow: one pretraining benchmark, three repeats, small budgets, high variance, and no transfer test across task families. The result shows that a search procedure can itself become editable. It does not show that the edited procedure finds better improvements across settings.

AIDE² reached the same boundary. Its selected harness transferred to unseen tasks, but a follow-up test asked a harder question: could the improved harness produce a still better successor? It did not show a reliable gain. That negative result separates a better artifact from a process that is getting better at improving.

Most useful systems today will stay below that line, and that is fine. A harness that improves once, transfers, freezes, and serves millions of tasks may be more valuable than a loop that rewrites itself forever. Recursion is a mechanism, not a product requirement.

Where the architecture still breaks down

A clean diagram can make the field look more settled than it is. The hardest problems now sit between the boxes.

• Fuzzy evaluation. Correctness and speed are easy to measure. Scientific taste, maintainability, novelty, and long-term value are harder to measure reliably. A controller can optimize only the proxy it receives.
• Causal attribution. A trace makes diagnosis possible, not correct. Several components may interact, and a fix that looks causal on one task family may be incidental.
• Long horizons. Search can collapse around one idea. Memories can become stale. Short experiments rarely capture maintenance cost, permission creep, or future debugging burden.
• Recursive judgment. Evaluators may need improvement too. Changing an evaluator inside the loop it judges breaks the evidence chain, so it needs a higher-level, independent gate. We still do not have a general rule for when that gate can be automated.

So, did the timeout patch improve the agent?

Not on the evidence we started with. The 12 percent run broke its budget, regressed on tasks that used to pass, and exposed evaluation examples to the proposer. The verifier should reject that run before its higher score enters the discussion.

The patch may still be useful. Keep the diff and traces, then rerun it under the original budget on held-out tasks and a sealed final test. Until it passes, h[t] stays in place. That is not a failed loop. It is the loop protecting its own claim.

Build the smallest honest system first

The four-layer architecture may look heavier than Chapter 2. Do not build all of it at once. Build the smallest system that can disprove its own improvement claim.

1. Name one mutable artifact. Start with a prompt, skill, or small harness module.
2. Freeze one judge. Use deterministic checks and a held-out gate.
3. Save one complete receipt. Keep the previous version, diff, tasks, traces, score, cost, and decision.
4. Use greedy keep-or-revert. Establish a baseline before adding tree search or evolution.
5. Inspect failures manually. Learn the failure patterns before automating diagnosis.
6. Add complexity only to fix a measured failure. Memory needs a no-memory control. Richer search needs evidence that greedy search is stuck.

Make the first loop almost boring. Prove that each boundary works. Then add one new capability at a time and make it earn its place.

The principle to carry forward

The papers use different names: evolver, critic, curator, selector, archive, reward model. Underneath those names, the same structure keeps returning. The system changes one explicit surface. It diagnoses from traces, tests a bounded proposal under fixed conditions, preserves the result, and asks an independent gate for permission to continue.

The deepest lesson is not that recursive self-improvement needs more agents. It needs a separation of powers.

Once that boundary is real, the remaining questions become concrete. What should change? What evidence would justify the change? And how cheaply can the next experiment prove us wrong?