RSI: A Conditional Theory, Not an Achieved Milestone

Recursive self-improvement (RSI) is not a milestone reached when an AI edits code once. It is a demanding conditional claim: a system improves the mechanism that carries out the next round of improvement, and later generations remain better at continuing that process on evaluations they did not select against. Many bounded self-optimization systems are already valuable. They do not need to be inflated into strong RSI to deserve serious study. The agent-skill lifecycle is precisely the governed, bounded end of this spectrum, and the second half of this post develops it in full.

1. Theoretical Root and Its Preconditions

In 1965, I. J. Good proposed a conditional chain: if a machine already greatly exceeds humans at every intellectual activity, and machine design is among those activities, it may design better machines. This is a theoretical argument about what could follow if its premises hold, not a conclusion that every benchmark improvement creates an intelligence explosion.

The Gödel Machine gives a stricter formal model. Given a utility function, hardware description, and axiomatic system, it rewrites its own code only when it can prove that the rewrite improves expected future utility. Its optimality guarantee depends entirely on those formal assumptions and proof search. It is not evidence that deployed agents already possess general, self-certifying, self-improving ability.

2. Which Layer Is Actually Improving?

Self-Refine is a first-layer example. OPRO optimizes prompts. FunSearch searches candidate programs under a human-provided problem, evaluator, and seed program. Each is meaningful; none should be rewritten as “the model rewrote itself.”

3. What Current Results Approach Empirical RSI?

Work such as the Darwin Gödel Machine comes closest to an empirical RSI discussion: it modifies a coding agent’s tools and workflow, then evaluates descendants on coding tasks. It supports the conclusion that some agent designs can be improved by later variants through empirical feedback in controlled environments.

Three gates still cannot be skipped:

1. Object of modification. Is the system changing an external target, a prompt, a scaffold, or the mechanism that produces later generations?
2. Evaluation independence. Are the development evaluations that select descendants separate from the sealed evaluations used to report capability?
3. Cross-generation persistence. Under equal resources, unseen tasks, and shifted harness conditions, is there reliable v2 > v1 > v0 improvement?

Without these, “bounded self-optimization” or “automated target optimization” is the accurate label. That is not a downgrade. It protects the conclusion from adaptive overfitting to one evaluator.

Recent work makes the meaning of “recursive” more concrete. RSEA evolves a three-layer natural-language state for a frozen policy and uses a strict keep-better gate on a disjoint held-out split to decide whether to commit a candidate; it supports a selection protocol for bounded context evolution. MetaSkill-Evolve evolves task skills on a fast loop and a meta-skill for the improvement pipeline on a slower loop with a frozen backbone; it makes some parameters of the improvement procedure itself measurable, not the model weights or evaluator an unbounded self-modifier. GRASP admits bounded skill-library edits only for net improvement on a balanced held-out probe under a hard regression budget; it supports the value of a gate and regression accounting. Conversely, Test-time Recursive Thinking studies inference-time refinement driven by self-generated verification signals, which highlights that candidate generation and candidate selection without external ground truth are distinct quantities to report.

These preprints are all worth reading, but cannot borrow one another’s conclusion. Context/skill updates, meta-skill updates, held-out acceptance, test-time self-verification, and recursive improvement of a base model, trainer, or evaluator are different objects. Together they turn RSI from a vague binary label into a design space that can fail component by component.

4. Write Cross-Generation Change as Four Independent Curves

One v2 > v1 > v0 score line is insufficient. At minimum, split a multi-generation system into the four curves below and observe them under the same model, editable surface, resources, and acceptance policy. Improvement on one curve cannot substitute for the others.

The four curves also explain why credible generation results need not rise monotonically at every step. Preserve rejected candidates, failed generations, variance, and withdrawals/rollbacks rather than displaying only the best lineage selected from many branches. If the improvement operator does not improve, or transfer/integrity deteriorates, the system is at most locally searching a fixed measurement device and should not be promoted to strong RSI.

5. A Minimum Evidence Package

Strong RSI should not be announced from one leaderboard curve. A serious report should disclose at least:

Repeated selection and tuning on the same evaluation set creates adaptive overfitting; Dwork et al. show that this is a rigorous statistical problem. For agent systems, model, prompt, tools, harness, sampling count, wall-clock budget, and API behavior all affect outcomes. A score is a property of a system configuration, not only of the base model.

6. A Candidate May Propose a Change but Cannot Accept Itself

This is an engineering recommendation in this post, not a summary of every paper’s implementation detail: separate the candidate system from the acceptance gate into distinct authority domains. A candidate version may analyze failed traces and propose narrow prompt, tool, memory, policy, or harness changes; it should not be able to modify hidden tests, graders, policies, scoring logs, or its own release decision. Each self-edit needs a change manifest: editable surface, expected gain, possible regression, resource budget, permitted external actions, and rollback condition.

This separation is not sufficient to make a system safe. It is the minimum needed to detect reward tampering, evaluation leakage, and silent authority escalation. Empirical work such as the Anthropic reward tampering study reminds us that once a model can influence a reward channel, the score itself becomes an attack surface to optimize. A candidate therefore cannot establish RSI by rewriting the scorer or approving itself. See Agent Evaluation Integrity for the full separation of reward, evidence, verifier, judge, and acceptance, plus adversarial integrity regressions.

7. A Multi-Generation Protocol That Can Fail

The following is a research design, not a reported result. It turns “v2 > v1 > v0” from a story into a statement that can fail:

A cross-generation curve is not the only metric. Report candidate count, acceptance rate, failure categories, resource ledger, held-out gain, regression count, and time to the first reliable improvement for every generation. A generation that scores higher on one unchanged benchmark may still be only searching a fixed measurement device.

Recent preprints such as the Red Queen Gödel Machine make evaluator evolution an explicit research object, fixing a criterion within an epoch and changing utility only at boundaries. That illustrates why evaluator version belongs to system state; it does not let us skip independent acceptance or call evaluator self-evolution a solved safety problem.

8. Treat Skills and Harnesses as Bounded Self-Modification Objects

Recent agent-skill work offers a more rigorous and tractable research object: treat a skill, tool recipe, or harness configuration as versioned state outside a frozen executor. For example, SkillOpt restricts a skill document to bounded add/delete/replace edits and accepts an edit only when held-out validation strictly improves. That is controlled optimization of a skill artifact; it does not show that the executor, training process, or evaluator has recursively self-improved.

Hack-Verifiable Environments supplies the other half. Rather than infer reward hacking only by reading trajectories after the fact, it places deterministically detectable hacking opportunities directly in an environment. For RSIBench / OpenRSI, that means “did the task complete?” and “did the system obtain score through tampering, leakage, or a reward proxy?” must be separate outcome columns.

This is a controlled self-modification protocol, not a declaration of strong RSI. Its falsifiers are direct: the held-out advantage vanishes, rejected edits cannot be explained, integrity violations rise, or a later generation does not become more effective at proposing the next change. For memory as editable but non-self-accepting execution state, checkpoints, and a trust boundary, see Agent Memory; broader adjacent choices appear in the hot agent directions map.

Sections 9–16 expand this bounded self-modification object into a full agent-skill lifecycle — from the SKILL.md format, activation, and routing to script authority, supply-chain security, and governed continual learning. Read it as the governed, bounded end of the self-improvement spectrum: skills, tool recipes, and harness configurations are versionable, rollback-capable external state outside a frozen executor, and however far their evolution is pushed, it is still not the “improving the improver” of Section 1. Precisely because this end can be strictly governed and falsified item by item, it marks the boundary a strong-RSI claim must cross.

9. A Skill Is an External Capability Package, Not Model Weights

The Agent Skills specification defines a skill as a directory containing at least SKILL.md, optionally with scripts, references, and assets. Its basic runtime is progressive disclosure: name and description at startup, the instruction body after a task matches, then resources on demand. This supplies a portable, versionable interface. The format itself does not ensure correct selection, safe scripts, correct output, or transfer across agents and harnesses.

Thus “the agent learned a skill” can mean four different things: a fixed skill was loaded and helped a task; an agent distilled a new skill from trajectories; a curator updated a skill repository; or a base model changed its parameters through SFT/RL. Report each separately rather than merging them into one skill success metric.

10. Turn a Format into a Lifecycle, Not Merely a Folder

An auditable skill needs a closed loop from provenance to retirement.

The format’s optional allowed-tools field is a useful declaration, but the specification calls it experimental and client support varies. A runtime host cannot treat YAML as an actual permission system: every call still needs the capability grant, parameter checks, sandbox, and independent postcondition in tool governance.

11. What Existing Skill Evidence Shows, and What It Does Not

SkillsBench compares no skill, curated skills, and self-generated skills on multi-domain tasks with deterministic verifiers. It supports the claim that some carefully constructed external skills can help specified agent-task configurations, while reporting substantial task variation and some negative effects; its self-generated skills do not automatically outperform the no-skill condition on average. SkillLearnBench studies continual skill generation. In its real-task taxonomy, no method leads consistently across every task and LLM, and it observes recursive drift from self-feedback alone.

SkillOpt treats a skill as text-space state outside a frozen executor, using bounded add/delete/replace edits, a rejected-edit buffer, and strict held-out validation for controlled optimization. It is important preprint evidence that a skill artifact can be trained like an optimization object. SkillOS separates a frozen executor from a trainable curator whose repository updates draw on cross-task experience. MUSE-Autoskill organizes creation, memory, management, evaluation, and refinement as a lifecycle. These works propose and evaluate systems in their stated settings; they do not imply that an arbitrary self-evolving library improves continually, transfers across environments, or constitutes strong RSI.

12. Activation Is Not Retrieval: Make Skill Routing a Rejectable Decision

The official Agent Skills guidance treats description as the primary activation signal in progressive disclosure. That describes a client interface; it does not show that metadata is sufficient for large-scale routing. SkillRouter finds, in its own large skill/query setting, that reranking with only name and description is substantially weaker than conditions with access to the skill body. SRA-Bench finds that current agents often load skills at similar rates whether a gold skill was retrieved or the task actually needs an external capability. Together they show that candidate relevance, whether a skill is needed, and correct execution after loading are three different questions. These are preprint results on their own benchmarks, not a conclusion about one routing algorithm across every client, repository, or security boundary.

An auditable router separates five gates:

At library scale, a body can be a strong retrieval signal, but that does not justify concatenating raw, untrusted skill bodies into an executable agent prompt. A safe research design separates retrievable text from executable content: a reranker reads a versioned, reviewed index_text or isolated embedding; only after the Activate gate passes is the full instruction loaded by content hash, and the host still grants minimum capabilities. This separation is an engineering inference from routing evidence and supply-chain risk, not a universal defense proved by one paper.

The minimum record is:

SkillRoutingRecord(
  task_and_state_digest, catalog_snapshot, visible_skill_ids,
  candidate_ids_and_index_digest, rank_scores,
  need_or_abstain, activated_skill_hashes, loaded_tokens,
  authority_grants, execution_trace, verifier_outcome, cost
)

Evaluation cannot stop at retrieval top-k. Report candidate_recall@k, route_top1, need precision/recall, false activation, missed useful activation, loaded-token/context cost, authority exposure, and final verified_success together. For a learned router, split queries by skill identity, near-duplicate body/template, source family, and environment/workflow. The final skill library may be indexed at inference, but final queries, gold skills, and acceptance traces cannot train the router or select its threshold. SkillRet provides a useful retrieval start with disjoint skill pools, but it alone does not establish safe activation, execution, or terminal transfer.

13. Accept a Skill Edit with the Discipline of a Code Change

When an agent may write or modify a skill, the minimum useful protocol is not “run it a few times and save it if the score goes up.” Use this controlled path instead:

1. Freeze executor and editable surface. State whether instructions, metadata, script, reference, or routing rule can change; the candidate cannot change evaluator, credentials, policy, or final release decision.
2. Retain a change manifest. Every diff records parent version, task/feedback sources, predicted gain, possible regressions, authority/dependency change, token/compute use, and review state.
3. Separate development from acceptance. Candidates, failures, and rejected edits remain in the development trace. A non-writable acceptance runner executes held-out tasks, regressions, and security tests.
4. Count cost and triggering quality. A skill that lifts outcome while misfiring, consuming excessive context, widening authority, or raising cost cannot be accepted by pass rate alone.
5. Release a rollback-capable version. Bind accepted version, scope, expiry, artifact hash, and revocation. A regression returns to the prior accepted version through its manifest.

This gives RSIBench a clean starting point: not a candidate freely rewriting itself, but a candidate proposing changes to a restricted, external, rollback-capable skill surface whose retention is decided by independent acceptance.

14. Supply Chain and Runtime Security: A Skill Mixes Code and Instructions

A skill package can carry scripts, reference content, triggering descriptions, and dependencies, creating both package-supply-chain and prompt-injection risks. Agent Skills in the Wild reports prompt injection, data exfiltration, privilege escalation, and supply-chain risk in its collected marketplace corpus and detection setup. Its sample, detector, and marketplace scope are not an unconditional prevalence estimate for the full ecosystem, but they show that installing a skill is not neutral text loading. Towards Secure Agent Skills divides the attack surface across creation, distribution, deployment, and execution, further warning that single-approval persistent trust is not enough control.

Every skill should at least have traceable provenance and license; content/script/dependency hashes; static and semantic review; isolated script execution; minimum default network/file/credential authority; untrusted labels on references and tool output; version pinning; revocation; and a post-install adversarial test. For browser and computer-use skills, a screenshot or success toast cannot replace a backend postcondition. For coding skills, tests do not replace dependency, secret, and egress audit.

15. Connect Skills Correctly to Synthetic Instances and Foundation-Model Training

A skill can be both a source of training data and external state used by a post-trained policy, but those paths must stay separate.

ACuRL connects target-environment exploration, curriculum generation, and continual adaptation, offering a concrete case where environment experience becomes a training signal. It does not remove the need to separate generator, training, validation, and final evaluation. Any positive claim that skills help foundation-model training should fix the base model, harness, library snapshot, tool policy, and total budget; compare no-skill, curated fixed skill, revision-only, SFT-only, RL-only, and SFT+RL; then accept on holdouts separated by environment, workflow/rule, skill topology, and security family.

16. How Skills Return to the Core Research Threads

These skill-lifecycle sections (9–15) complement the controlled self-modification protocol of Section 8: the RSI framing of Sections 1–7 says when we may discuss improving the improver, while these sections define a smaller, operational external skill artifact. They also connect to synthetic agent training, Agent Tool Governance, long-horizon agents, and Hot Agent Directions.

17. How RSI Relates to AutoResearch and Agentic RL

AutoResearch asks whether, after development search on D_dev, a system can freeze a candidate and use selection-independent H_accept plus a clean rerun to turn experimental history into more effective later experiments. It may improve an external research artifact without improving itself.

Agentic RL asks how to train from real harness behavior, tool trajectories, and verifier rewards without replacing the execution conditions of the test-time policy. It may produce a stronger policy without constituting RSI.

RSI is the stronger system-level question: does an improved agent or harness become better at generating subsequent improvements, and does that advantage survive sealed, shifted evaluation? The skill lifecycle of Sections 9–16 supplies the smallest governable experimental surface for that question; the three ideas are connected, but none substitutes for another.