Can AI Agents Fix Themselves Without Breaking? What Google's Open-Source RRSI Means for Production Agent Stacks

Last Updated: September 30, 2026

Google just handed every agent-building team a proven answer to the scariest question in production AI: how do you let an agent improve itself without it quietly breaking? On 21 September 2026, Google Cloud AI Research, with UNC-Chapel Hill, Stanford and Washington University in St. Louis, released RRSI (Regularized Recursive Self-Improvement), an open-source framework under the Apache 2.0 license where an LLM agent rewrites its own harness, meaning its prompts, tools, memory, control flow and sub-agents, while the model weights never change. The part that matters for anyone running agents in production: RRSI is the first published method whose self-improvement gains transferred to benchmarks it was never optimized against, and every held-out benchmark improved, six out of six.

Key Takeaways

• Google Cloud AI Research open-sourced RRSI, a framework where agents rewrite their own prompts, tools, memory and sub-agents while model weights stay frozen.
• Plain harness evolution overfits: the agent memorizes the benchmark it improves against, and two of three prior methods studied ended below their own starting point out of distribution.
• RRSI adds five rules: annealed edit budget, evidence ledger, leakage critic, noise-adjusted floor, and a cost rule plus pruning, so only generalizable, cost-justified edits stick.
• Results: Terminal-Bench 2.1 rose from 74.2% to 80.2%, and all six held-out benchmarks improved, including SWE-bench Verified from 82.0% to 83.8%, using roughly 30% fewer tokens than unregularized evolution.
• For production teams, RRSI is effectively a blueprint for governed agent self-improvement: version-controlled harness changes, evaluation gates, audit logs and cost accountability.
• The same pattern runs on your own stack: RRSI is Apache 2.0, accepts any LiteLLM model string, and its rules work even if you never run the full loop.

What is an agent harness, and why does it matter more than the model underneath?

An agent harness is everything wrapped around a large language model when it runs as an agent: the system prompts, control flow, tool definitions, memory files, context management and sub-agents. The model weights stay frozen and the harness determines what the agent can actually do, how it recovers from failures and what it keeps in context between steps. Two deployments of the identical model can score dramatically differently purely because of harness quality, which is why harness discipline matters more than model choice for most production agents.

Well-known examples make this concrete: Claude Code from Anthropic and Codex from OpenAI are harnesses, and the same model served raw scores worse than the same model inside a well-built harness. RRSI's starting harnesses were the open-source Terminus-2 agent from harbor and the react_toolbelt agent from archipelago. This matters for businesses because harness components are cheap configuration artifacts, expensive model weights are the only thing most teams cannot change, and the gap between a raw model and a production agent is nearly all harness.

Why is letting agents improve themselves so risky?

Self-improving agents are risky because harness evolution systematically overfits the benchmark it improves against. Each round, an LLM proposes harness edits, the edited harness runs on a fixed task set with automatic scoring, and the best candidate becomes the new incumbent. According to the RRSI researchers, on their workspace domain the best prior method added only 0.9 points on average on tasks it never trained on, and two prior methods ended below the harness they started from.

The paper identifies three overfitting mechanisms. First, benchmark-specific fitting: task names, entities or answers leak into prompts, and the polished harness is really memorizing a question bank. Second, noise chasing: because each evaluation has variance, a loop that keeps the best candidate every round trends toward lucky runs rather than real quality. Third, complexity accumulation: prompts and sub-agents accrete special cases that raise the measured score without making the agent smarter, and they cost tokens on every run.

Anyone who has run an automated prompt-optimization loop against a personal test set recognizes this pattern. The test numbers climb while real-world performance quietly degrades or stagnates, and nobody can say which of the 40 accumulated edits did the damage. In production terms this is untracked system drift, the thing change-management discipline exists to prevent.

How does RRSI regularize the search instead of restricting the harness?

RRSI keeps every component of the harness editable and instead regularizes how the search moves through that open space. Five rules govern the loop: an annealed edit budget, an evidence ledger, a leakage critic, a noise-adjusted acceptance floor, and a cost rule with pruning. The researchers explicitly analogize them to classical regularizers from ML: the edit budget maps to L0, pruning maps to Lasso's L1 penalty and the cost rule maps to Ridge's L2 penalty.

At the proposal stage, three rules govern how search capacity is spent. According to the paper, early rounds may bundle several coordinated edits per candidate, up to five, and the limit anneals down to a single attributable change by the final round on a cosine schedule, so late gains are traceable to specific causes. Every candidate is logged with its component, hypothesis, diff, score change and cost change in an edit ledger the proposer reads before drafting, so falsified hypotheses are not retried. When progress stalls inside the noise band, budget redirects toward components the run has never touched.

At the selection stage, regularizers decide which gains become permanent. A leakage critic screens every candidate for task names, benchmark entities, answers or suite-specific logic before any evaluation happens. A noise-adjusted floor, estimated from repeated runs of the unchanged base harness, blocks gains within evaluation variance. A cost rule requires extra inference tokens to be paid for by measured gain. Finally, components that stop earning their place are flagged for deletion.

There is also an engineering decision worth copying: every candidate harness is drafted, screened and evaluated in its own git worktree, and accepting a candidate fast-forwards the branch. The incumbent harness is always a commit, every rejected candidate has a diff, and the full loop produces an audit trail rather than a mystery.

What results did RRSI actually deliver?

Across eight benchmarks in three domains, RRSI improved every single one: Terminal-Bench 2.1 climbed from 74.2% to 80.2% on the evolve split, SWE-bench Verified rose from 82.0% to 83.8% without ever being used for selection, and the three out-of-distribution workspace benchmarks gained 3.5 to 4.7 points each. The evolved harness also used roughly 30% fewer tokens per trial than unregularized evolution, and the same gains held with Gemini 3.5 Flash as the policy model, where Terminal-Bench rose from 64.6% to 78.7%.

Three results deserve emphasis. On the held-out Harvey LAB split, the harness score rose from 89.4 on the evolve side by only 1.1 points, yet on the 40 held-out tasks it gained 2.3 points, and the three never-seen benchmarks gained 3.5 to 4.7 points each. Frontier-Eng rose 24.3% relative, from 17.7 to 22.0 Medal points.

Point two: the evolved harness is cheaper to run, not more expensive. RRSI averaged 2.42M policy tokens per trial on the workspace instance versus 3.80M for unregularized evolution, roughly a 36% reduction, and it averaged 26.3 steps per trial versus 27.3 to 34.6 for competing methods.

Point three: the gains are not tied to one policy model. With Gemini 3.5 Flash as the frozen policy, Terminal-Bench 2.1 rose from 64.6% to 78.7% and SWE-bench Verified from 76.8% to 79.0%. Even the smaller Gemini 3.1 Flash Lite, which took no part in the search, improved from 11.2% to 14.6% running the evolved harness, so the harness improvements transferred across model families.

It is not all upside, and the honest accounting matters. The base harness H0 stays cheapest overall at 1.56M tokens per trial, compared with 2.42M for the evolved one, so a real chunk of the quality gain is paid for in inference tokens. RRSI also only touches frozen-weight setups, it inherits any limitations of a finite task set, and its run cost is significant: each round evaluates two candidates across the entire evolve set, and teams should expect substantial compute spend per full run.

What does RRSI mean for your production agent stack?

For production agent stacks, RRSI is a blueprint for governed self-improvement rather than a product to install. Its five mechanisms double as a governance checklist you can adopt immediately: version-control every harness change, log each edit with its hypothesis and measured effect, reject changes that hardcode task specifics, ignore gains smaller than your evaluation noise, and require token growth to be paid for by measured quality. Google's team formalized what disciplined agent engineering already looked like, and they published it as an Apache 2.0 repository you can audit.

• Edit budget: change one or two things at a time. Bundled changes make attribution impossible, and unattributable gains are ungovernable gains.
• Evidence ledger: every change to a prompt, tool or memory file is logged with its hypothesis and its measured effect. Six months from now you can answer why the system behaves the way it does.
• Leakage critic: any change that hardcodes task names, customer names or expected answers gets rejected before it is even tested. This is the automated equivalent of the code reviewer who spots test gaming.
• Noise-adjusted floor: if the claimed improvement is smaller than your evaluation's run-to-run variance, it is not an improvement. Measure variance on the unchanged system first.
• Cost rule and pruning: every token of added inference cost must be paid for by measured quality, and components that stop earning their place are removed rather than tolerated.

Our take as a team that builds local agent stacks daily: once your harness lives in git, accepts candidate changes through worktrees, gates on held-out evaluation and logs every edit with a verdict, you have implemented change management for self-improving agents. That is exactly the TOGAF change-advisory-board discipline enterprises already require for any other production system, applied to the part of the AI stack that is actually editable. The model backbone deserves the same operational seriousness: our DeepSeek V4 Flash deployment works because the layer around it is disciplined, and RRSI shows what happens when that discipline is automated rather than enforced by human vigilance.

On-premises adoption is straightforward to reason about. RRSI ships as a framework that accepts any LiteLLM model string, evaluates agents in Docker containers for the coding domain, and pins candidates in git worktrees. Nothing in the loop requires your data to leave your environment, so a self-hosted policy model plus a managed eval suite is a coherent target architecture. The benchmark adapters for terminal, workspace and engineering domains prove the pattern generalizes, and your domain plugs in through a single adapter module. What you provide is the one thing no framework can generate for you: a task set with automatic verification and a split you genuinely never let selection peek at.

The governance angle deserves its own note, particularly for Australian enterprises navigating customer expectations that AI outputs stay auditable. An agent that rewrites its own prompts at 3am is only scary if the rewrites are untracked. Under RRSI-style discipline, the rewrite becomes a pull request with a hypothesis, a measured delta and an auditor-readable trail, which replaces vague unease with a reviewable artifact. According to the project's own repository, four real evolution runs, with every candidate's critic verdict and diff, are published on the project page for exactly this purpose.

Say the quiet part plainly: the teams shipping serious agent systems this year are already running some version of this loop by hand, measuring, tweaking prompts and pruning dead tools. RRSI mechanizes that loop while keeping its safeguards explicit. The companies that benefit will be the ones whose verification is trustworthy, whose data is clean, and whose agents have well-defined jobs. The companies that should wait are those who cannot yet articulate what a successful agent task looks like for their business, because no regularizer can rescue a bad benchmark.

Practical starting sequence if this is on your roadmap for the next quarter: first, freeze and version-control the current harness so every future change is a diff. Second, build a small evolve set of real tasks with automatic scoring and split off a held-out set that selection never sees. Third, measure evaluation variance with repeated baseline runs so you know what real signal looks like. Fourth, adopt the cost rule as policy: any change that raises tokens must demonstrate proportional quality gain. Fifth, only then consider automating the loop, candidates drafted in worktrees, screened by a leakage critic and gated on held-out scores. By the time you automate the loop, the loop is already safe.

Bottom line: Regularization beats good intentions. When you let agents improve themselves, the discipline that keeps them safe is not a values statement, it is an acceptance gate with measurable criteria. RRSI is the first major lab to publish that gate as open source, and the pattern is adoptable with or without the code.