From RSI to Google RRSI: How Agents Improve Their Own Workflows

An agent can improve its score by adding useful recovery logic, but it can also improve by memorizing the tasks used to judge it. Those changes have different value when the next task arrives.

Google’s RRSI studies this problem in recursive self-improvement, or RSI. This guide explains what changes in the loop, how candidate edits are selected, and how to inspect the released selector locally with a small Python example.

Sources were checked on October 9, 2026. RRSI means Regularized Recursive Self-Improvement of Agent Harnesses. The project lists researchers from Google Cloud AI Research, UNC-Chapel Hill, Stanford, and Washington University in St. Louis. It is a research project with public code, rather than a supported Google product. The local core tests and synthetic demo below were run; the model-backed evolution and benchmark experiments were not.

1. What RSI means here

Recursive self-improvement describes a loop in which a system’s experience helps change the system used in subsequent rounds. The important questions are what changes, whether the change persists, and how improvement is verified.

Different projects place the editable part at different levels. For example, Sakana AI’s Darwin Gödel Machine modifies a coding agent’s own code and tests the resulting variants. Its improved agents can participate in further self-modification. That is a concrete system-level setting for RSI.

For reading RRSI, this distinction helps:

RRSI works at the harness level with a frozen backbone. In this setting, it provides evidence about a bounded agent-improvement procedure. The study does not establish unlimited autonomous improvement or model-weight self-training. See the version 3 paper.

2. The harness is the editable workflow

Think of the model as one component inside a program. The surrounding program decides what the model sees, which tools it can call, how failures are handled, and what gets retained for later work.

The released component vocabulary includes prompts, control flow, configuration, output plumbing, context management, client tools, skills, memory, and subagents. RRSI leaves this edit space open.

A generic example is changing a tool wrapper so a failed shell command returns its exit code and a concise error summary. That can help many tasks. Adding a stored answer for one named benchmark task is a different kind of edit. This is an explanatory example, not a result from the paper.

The loop is:

current harness → task traces → analysis → candidate edits
                → leakage screen → evaluation → selection → next harness

Candidates live in separate Git worktrees. The accepted harness is a versioned commit, so its source changes can be inspected. The README maps the stages to their implementation files.

3. Why regularize the search

Repeatedly choosing edits against the same task set makes the feedback adaptive: later proposals depend on earlier scores. A rising score can therefore reflect useful mechanisms, task-specific fitting, lucky measurements, or extra computation.

RRSI controls the proposal and selection process. It does not freeze the harness into a fixed list of permissible edits.

Proposal controls

The edit schedule reduces the number of independent edits permitted in a candidate as a run advances. The count is an edit budget, not a token budget or a cap on lines changed.

The history module tracks hypotheses, verdicts, and measured score and cost changes. It also supports exploration of previously untouched components when progress stalls, and identifies unproductive components as pruning targets. A rejected hypothesis remains evidence for later proposals.

Selection controls

The critic screens a diff for benchmark-specific content before full evaluation, using domain patterns and an LLM review. Screening is a filter; it is not proof that every possible leakage path has been eliminated.

The selector uses a floor relative to the best score seen so far, a measured noise band, a cost rule, and domain guards. Among admissible candidates, it selects the highest score.

For gains above the noise band, the rule is:

delta_S = candidate_score - incumbent_score
delta_C = (candidate_tokens - incumbent_tokens) / incumbent_tokens
admit on cost if delta_C <= beta0 + beta1 * delta_S

Inside the band, a separate rule can admit a candidate for lower cost or structural novelty. It is therefore inaccurate to describe RRSI as rejecting every small score change. Also, its regularization analogies concern discrete edits and resource use; they do not mean it adds an L1 or L2 penalty to model training.

4. Read results with their baseline attached

The following values come from Tables 2 and 3 of paper v3, revised October 4, 2026. They are author-reported results, not measurements from this tutorial.

The unregularized workspace arm uses 3.80 million tokens per trial. RRSI’s 2.42 million is about 36% lower than that arm, while remaining more expensive than the unevolved base. A token reduction also does not directly specify total search cost, latency, or a billing reduction. Paper v3, Tables 2–3.

The abstract and project page have different headline summaries. Keep the version, table, policy, metric, and comparison attached to any number you reuse. In particular, distinguish percentage-point gains from relative percentage gains.

5. Inspect the core without model calls

Use Python 3.10 or newer and Git. The local checks here passed with Python 3.14.7 on macOS. Start in a fresh directory:

mkdir rrsi-reading
cd rrsi-reading
git clone https://github.com/google-research/rrsi.git
git -C rrsi checkout be50316e1db05914068a973f322770ef08ed7ba1
python3 rrsi/tests/test_core.py
python3 rrsi/rrsi.py --help

The standalone core tests exercise the schedule, estimator, calibration, cost rules, selection, history, component normalization, and configuration. They do not call a model or run a benchmark.

Download rrsi_gate_demo.py into rrsi-reading, beside the checkout. Run:

python3 rrsi_gate_demo.py --help
python3 rrsi_gate_demo.py rrsi

Expected output:

SYNTHETIC INPUTS: selection only; no benchmark evaluation
small-noisy-gain: REJECT
expensive-gain: REJECT
reusable-gain: ADMIT
cheaper: ADMIT
below-floor: REJECT
WINNER: reusable-gain

6. The complete selection demo

"""Exercise RRSI's released selector with synthetic inputs; no model calls."""
import argparse
from pathlib import Path
import sys


def main():
    parser = argparse.ArgumentParser(description=__doc__)
    parser.add_argument("repo", type=Path, help="path to the pinned google-research/rrsi checkout")
    args = parser.parse_args()
    repo = args.repo.resolve()
    if not (repo / "rrsi" / "selection.py").is_file():
        parser.error("repo must contain rrsi/selection.py")
    sys.path.insert(0, str(repo))
    from rrsi.config import RRSIConfig
    from rrsi.evaluate import EvalResult
    from rrsi.selection import Candidate, select_round

    # Illustrative settings, not the paper's domain hyperparameters.
    cfg = RRSIConfig(beta0=0.10, beta1=4.0, w_s=0.0, w_c=15.0, w_n=0.5)

    def result(name, score, tokens):
        return EvalResult(job=name, k=1, per_task={}, S=score, C=tokens,
                          n_expected=1, missing=0)

    incumbent = result("base", 0.70, 1000)
    specs = [
        ("small-noisy-gain", 0.71, 1000),
        ("expensive-gain", 0.75, 1800),
        ("reusable-gain", 0.73, 1200),
        ("cheaper", 0.70, 800),
        ("below-floor", 0.68, 700),
    ]
    candidates = [
        Candidate(name, [{"component": "prompt", "hypothesis": "synthetic demo"}],
                  ev=result(name, score, tokens))
        for name, score, tokens in specs
    ]
    winner, decisions = select_round(
        candidates, incumbent, S_star=0.72, delta=0.02,
        cfg=cfg, incumbent_counts={},
    )
    print("SYNTHETIC INPUTS: selection only; no benchmark evaluation")
    for decision in decisions:
        verdict = "ADMIT" if decision.admissible else "REJECT"
        print(f"{decision.variant}: {verdict}")
    print("WINNER:", winner.variant if winner else "none")
    return 0


if __name__ == "__main__":
    raise SystemExit(main())

These scores, token counts, and settings are invented teaching inputs. The script calls the pinned repository’s real selector; it does not implement the proposer, critic, calibration, pruning, or a recursive evolution run.

The current score is 0.70, the historical best is 0.72, and the noise band is 0.02. The resulting floor is 0.70. All candidates are tagged as prompt edits, so their structural novelty contribution is zero.

With these illustrative settings, the 0.75 candidate gains 0.05 but increases tokens by 80%. Its permitted cost increase is 0.10 + 4.0 * 0.05 = 0.30, so it fails. The 0.73 candidate increases tokens by 20%, within its 22% budget. The cheaper candidate is also admissible, but the 0.73 candidate wins on score.

The 0.71 candidate has no cost saving or novelty; w_s=0 gives its within-band score gain no credit. A different configuration can change that verdict. The configuration source documents scores as fractions and token changes as relative quantities.

7. Plan a real experiment

For model-backed work, follow the domain setup in the pinned README. Benchmark runners need their own environments, datasets, tools, and model access. Passing the core tests establishes that the local mechanics run, not that those resources are configured.

A useful experiment plan is:

1. Record the starting harness commit, model identifiers, task splits, and budget.
2. Measure the unchanged base repeatedly and calibrate the noise band.
3. Allow proposals to use only the designated evolve-set feedback.
4. Keep each diff, hypothesis, evaluation result, token count, and verdict.
5. Evaluate the frozen final harness on untouched tasks using a declared protocol.

These are practical controls for interpreting an experiment. If you repeatedly tune decisions on the held-out results, that set becomes part of the search and can no longer support the same independence claim.

The evaluation module keeps missing trials in the score denominator with zero reward. Dropping failed trials can make a fragile candidate look better. Also record search expenditure separately from the final harness’s per-task cost.

For local experiment tooling, the site’s subprocess logging helper and dataset checksum manifest can help preserve commands and inputs.

8. Troubleshooting

9. Summary

RSI is a broader idea; RRSI is a specific approach to harness evolution around frozen models. Its practical contribution is a disciplined way to propose, test, retain, and remove workflow changes. Judge progress using transfer, reproducible evidence, and clearly named cost comparisons, alongside the score used during evolution.