Google Cloud's RRSI throttles how many harness edits a self-improving agent may bundle

Three of RRSI's five constraints are penalties on size ^[14]. Complexity-aware acceptance rejects a small gain that arrives with a large token cost, which the post calls a ridge-style L2 penalty ^[10]. Structural pruning deletes components showing consistently zero or negative gains over a window of evaluations, described as Lasso-style L1 ^[11]. The annealed sparsity budget limits how many edits can ride in a single candidate, and the post calls that analogous to L0 ^[7]. None of the three tests whether the survivor generalises, because the performance signal they score against is the evolution benchmark itself ^[3][4]. The post does not describe a held-out task split. In supervised learning the penalty strength is set by watching a held-out set.

Leakage screening is the one filter aimed at distribution rather than size. A critic reads each proposal for benchmark-specific logic: task names, dataset-specific patterns, hardcoded responses, with memorising proposals rejected ^[9]. That catches the crude version. The post's own example of the subtle version is a prompt clause that works on the training examples and fails on anything outside that distribution ^[5]. Such a clause need not name the dataset. It can be plain English, fitted to the eval set, and it sails past a critic hunting for task names.

The proposer side is the better engineering. Evidence-aware credit assignment keeps a record of which mechanisms have been tried, credits the ones that succeeded, and treats rejected ones as negative evidence ^[8]. When progress stalls, it reserves budget to explore components that have not been exercised yet ^[8]. The bookkeeping targets a different failure: a loop that keeps reproposing its own past winners and never touches the retry code.

Adoption cost shows up in pruning. Deleting a component because it contributed nothing over a window requires per-component gain attribution across that window ^[11]. That means evaluations that separate memory retrieval from context management from error handling, all of which the post counts as parts of the harness ^[2]. On agent tasks, those evaluations are the expensive half of the loop. The annealing schedule, the token-cost-to-gain ratio and the pruning window are numbers an implementer picks.

For any of this to bind in your loop, two things have to hold: the edits are proposed and accepted without a human in the path, and the score comes from a fixed task set ^[3][4]. If someone reviews every harness diff, leakage screening is code review. If the eval set is refreshed from production traffic, the overfitting the paper targets decays on its own. The premise underneath all of it is that reliability lives in the scaffolding around the frozen model, and the post puts that strongly: a capable model with a poorly designed harness will fail on tasks that a weaker model with a well-designed harness handles reliably ^[12].