PaperlayerView exact revision on arXiv

Source-linked AI summary

RRSI: Regularized Recursive Self-Improvement of Agent Harnesses

Peng Xia, Rujun Han, Zifeng Wang, Yanfei Chen, Yufan Zhang, Yoonho Lee, Chengsong Huang, Han Yu, Zhongying CuiZhu, Yifei Ming, Huaxiu Yao, Burak Gokturk, Tomas Pfister, Chen-Yu Lee

arXiv:2609.24972v1cs.LGcs.AIcs.CL

TL;DR

Whether recursively improved agent harnesses transfer to unseen benchmarks remains a central question. RRSI regularizes candidate proposal and selection while keeping every harness component editable. Across eight benchmarks in three domains, it improves every held-out split, gaining up to 4.7 points out of distribution while using fewer policy tokens than unregularized evolution.

  • Problem

    The central question is whether recursively improved agent harnesses transfer to unseen benchmarks with different task descriptions, tool interfaces, or verifiers.

    Source: §1 · p. 2

  • Method

    RRSI regularizes candidate proposal and selection to favor reusable edits while keeping every harness component editable.

    Source: §1 · p. 2

  • Results

    Across eight benchmarks in three domains, RRSI improves every held-out split, gains up to 4.7 points out of distribution, and uses fewer policy tokens than unregularized evolution.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The findings suggest that transferable harness self-improvement requires controlling how repeated feedback guides evolution, not merely which components may change.

    Source: §6 · p. 11

    Generalization to substantially different agent architectures, tool ecosystems, and longer-running self-improvement processes still requires broader validation.

    Source: Limitations · p. 11

Abstract

from arXiv · show

An LLM agent's capability is largely magnified by its harness, namely the prompts, control flow, tooling, memory, and context management surrounding the frozen backbone model. Recent methods increasingly automate this process by iteratively proposing and selecting component-wise edits of an agent harness, practically establishing a form of recursive self-improvement (RSI) at the agent-system level. However, such recursive evolution may overfit by memorizing the training tasks, showing large in-distribution gains that shrink or even vanish on out-of-distribution benchmarks. We introduce Regularized Recursive Self-Improvement of Agent Harnesses (RRSI), which incorporates the principles of regularizations into harness self-improvement by constraining the evolution candidate proposal and selection. The proposer operates with a temporally annealed budget, limiting how many edits a candidate can bundle, and it encourages unexplored trajectories based on evolution history. The selector is equipped with a critic and a pruner: the critic screens benchmark-specific proposals, while the pruner, removes changes that are too small, too expensive, or no longer useful. Together these constraints favor reusable agent mechanisms over benchmark-specific ones or even noises. Across eight benchmarks spanning coding, agentic workspace and engineering design tasks, RRSI gains up to 14.1 points on the split it evolves against and up to 4.7 points on the five out-of-distribution benchmarks, while producing a harness that runs on 30% fewer policy tokens than the unregularized evolution. Code is available at https://github.com/google-research/rrsi and project page is https://regularized-rsi.com/.

1. Introduction

RRSI regularizes proposal and selection during recursive harness evolution, favoring reusable edits while keeping every harness component editable. Across eight benchmarks, it improves held-out performance using fewer policy tokens than unregularized evolution.

1. Introduction

  • A frozen model’s harness controls prompts, tools, memory, context, and execution, but manual improvement is limited by engineers’ capacity to inspect failed trajectories.Harness choices determine whether an agent reads relevant files, recovers from failed commands, manages working context, and writes findings into deliverables.Source: §1 · p. 1
  • Up to 14.1 points on the evolving split and up to 4.7 points out of distribution summarize RRSI’s gains across eight benchmarks.RRSI improves all six held-out splits and outperforms the average prior baseline by up to 22.9%. It uses fewer policy tokens than unregularized evolution.Source: Figure 1 · p. 2, §1 · p. 2
  • Repeated selection on finite evolve sets risks overfitting through benchmark-specific fitting, noise chasing, and complexity accumulation rather than transferable improvements.Prior methods retain little evolve-set gain, and several fall below the initial harness. Apparent improvements can also reflect increased test-time computation rather than reusable mechanisms (Ding et al., 2026; Lin et al., 2026b; Wang et al., 2026b).Source: §1 · pp. 1–2
  • RRSI keeps every harness component editable while encouraging simpler, reusable proposals and selecting against benchmark-specific signals, evaluation noise, and unnecessary complexity.Regularization constrains how finite evolve-set feedback guides the search, rather than restricting which harness components can change.Source: §1 · p. 2
  • Across eight benchmarks in three domains, each harness evolves on one suite and runs unchanged on held-out benchmarks with different tasks, tools, or verifiers.The study defines generalization as transferring evolved harnesses to unseen benchmarks with different task descriptions, tool interfaces, or verifiers.Source: §1 · p. 2

2. Preliminaries

An agent combines a backbone policy with a harness; harness evolution optimizes the harness while keeping that policy fixed. Reusing the same tasks across evolution rounds makes this process adaptive empirical optimization.

Agents and Harnesses

  • An agent A = (π, H) combines a backbone policy with a harness governing prompts, control flow, tools, memory, and context management.The harness encompasses everything around the model weights, including skill files and tool descriptions.Source: §2 · p. 3
  • S(H; D) measures expected verifier reward, while C(H; D) measures expected policy-token consumption across tasks and agent trajectories.Verifier rewards lie in [0, 1]; verifiers may be coding unit tests or LLM-as-a-judge programs for workspace tasks. Trajectory cost c(τ) counts consumed policy tokens.Source: §2 · p. 3

Harness Evolution

  • Harness evolution keeps the backbone fixed while repeatedly collecting trajectories, summarizing feedback, proposing harness candidates, evaluating them, and selecting the best candidate (Lee et al., 2026b).Candidates are evaluated on the same evolve set; P_0 denotes unconstrained proposal, and empirical scores come from finitely many stochastic agent runs.Source: §2 · p. 3
  • Reusing the evolve set is adaptive because later candidates depend on earlier measurements from those same tasks, creating empirical optimization over an unusually expressive search space.Source: §2 · p. 3

3. RRSI

RRSI regularizes the trajectory of iterative harness evolution rather than restricting the available edits. It combines sparse, history-guided proposals with leakage screening, stability- and cost-aware acceptance, and structural pruning.

3.1. A Regularization View of Harness Evolution

  • RRSI leaves harness edits unrestricted while regularizing proposal capacity and requiring sufficiently strong, efficient, leakage-free improvements for selection.Candidates are proposed using feedback from a finite evolve set; the selector determines whether any candidate replaces the incumbent.Source: §3.1 · p. 4

3.2. Regularizing the Proposal Distribution

  • RRSI anneals an L0-style edit budget from b_max to b_min, enabling coordinated early changes and increasingly sparse, attributable later updates.The budget limits independently attributable edits per candidate, not a fixed parameter vector; RRSI does not optimize an L0-penalized objective.Source: §3.2 · p. 5
  • Evolution history guides credit assignment and reserves proposal capacity for unexplored components when progress stalls within the empirical noise band.Records retain each candidate’s component, hypothesis, source diff, score and cost changes, and acceptance outcome, preserving rejected mechanisms as negative evidence and successful mechanisms as explicit credit. A stall occurs when progress over the previous w rounds remains within δ.Source: §3.2 · p. 5

3.3. Regularizing Candidate Selection

  • Before full evaluation, a critic rejects benchmark-specific content and inert machinery while permitting generic prompt and tool-description improvements.Screening prevents leaking candidates from receiving inflated evolve-set scores that could attract subsequent search rounds.Source: §3.3 · p. 5
  • RRSI combines a noise-adjusted performance floor with cost-aware acceptance to limit stochastic selection errors, cumulative regressions, and unchecked resource growth.Repeated evaluations of the unchanged base harness estimate the noise band; the acceptance floor references the best evolve-set score observed. Policy tokens proxy resource cost, with cost-tolerance parameters selected on the evolve set and fixed for transfer evaluations.Source: §3.3 · p. 6
  • L1-style structural pruning targets components without strictly positive measured gains over a fixed window, sparsifying the retained harness rather than individual updates.Recently exercised but persistently unproductive components become deletion targets for subsequent proposals; this is a qualitative analogy to Lasso, not continuous parameter regularization.Source: §3.3 · p. 6

4. Experiments

Across coding, agentic workspace, and engineering design, RRSI improves every held-out split and outperforms prior harness-evolution methods on held-out datasets. Ablations connect transfer and lower token costs to its regularizers, while coding experiments demonstrate gains across policy families and transfer to an unseen weaker backbone.

4.1. Experimental Setup

  • Eight benchmarks span three domains, with evolution on Terminal-Bench 2.1, Harvey LAB, and EngDesign and evaluation on five additional OOD benchmarks.Harvey LAB uses 120 evolution tasks and 40 pristine in-distribution held-out tasks; OOD tests cover SWE-bench Verified, JobBench, GDPval, APEX-Agents, and Frontier-Eng. All baseline runs share H0, the frozen policy, evolve set, and candidate budget.Source: §4 · p. 6, §4.1 · p. 7

4.2. Main Results

  • 1.8 points on SWE-bench Verified, 2.3 on Harvey LAB held-out, 3.5–4.7 on agentic OOD benchmarks, and 4.3 Medal points on Frontier-Eng demonstrate transfer.Evolve-set gains are 6.0 points on Terminal-Bench 2.1, 4.9 on EngDesign, and 1.1 on Harvey LAB, with no held-out regression. Engineering-design gains persist under deterministic simulator or testbench grading, rather than depending on judge-mediated scoring.Source: §4.2 · pp. 7–8, Figure 3 · p. 8
  • 43.6 versus 39.7 OOD average distinguishes RRSI from the unevolved H0, outperforming all four prior harness-evolution methods.Meta-Harness gains 0.9 points over H0, HarnessX matches H0, and AHE and TTHE fall below it, with TTHE losing 1.7 points. RRSI achieves the smallest evolve-set gain among evolved harnesses but consistently outperforms baselines on held-out datasets.Source: §4.2 · p. 7, Table 1 · p. 8

4.3. Analysis

  • 40.3 OOD average and 92.8 evolve-set score result when both regularizer groups are removed, versus RRSI’s 43.6 and 90.5, respectively.Removing acceptance constraints raises the evolve-set score to 91.5, lowers OOD average to 41.0, and increases token cost by half. Removing proposal constraints costs 0.2 evolve-set points and 1.7 OOD points; removing both uses 3.80 million tokens per trial versus RRSI’s 2.42 million.Source: §4.3 · pp. 8–9, Table 2 · p. 9
  • 2.2 points on SWE-bench Verified transfer under Gemini 3.5 Flash, while Claude Opus 4.8 improves the same benchmark from 82.0 to 83.8.Independent searches evolve only on Terminal-Bench 2.1, improving it from 64.6 to 78.7 with Gemini 3.5 Flash and from 74.2 to 80.2 with Claude Opus 4.8.Source: Table 3 · p. 9, §4.3 · p. 9
  • 11.2 to 14.6 Terminal-Bench 2.1 accuracy, a 30.4% relative gain, results when the Gemini 3.5 Flash-evolved harness runs unchanged on unseen Gemini 3.1 Flash Lite.The smaller evaluation backbone never participated in harness search, demonstrating cross-model transfer without adapting the evolved harness.Source: §4.3 · p. 9, Table 4 · p. 10
  • 26.3 steps per trial and the lowest token cost distinguish RRSI from prior evolved harnesses, which take 27.3–34.6 steps and achieve lower OOD averages.An L1-style proposal budget and pruning constrain growth; AHE uses 3.82 million tokens per trial, 58% more than RRSI, for 4.4 fewer OOD points. Evolution still costs more than H0’s 1.56 million tokens and 21.2 steps per trial.Source: §4.3 · pp. 9–10, Figure 4 · p. 10

5. Related Work

Harness-evolution gains can fail to transfer across benchmark suites (Huang et al., 2026d; Wang et al., 2026b). RRSI retains an open edit space but regularizes search dynamics to favor reusable mechanisms over task-specific fitting.

Harness evolution

  • Harness evolution automates manual engineering through benchmark-selected harness rewrites or evolution of individual components.LLM-proposed rewrites are retained when benchmark scores improve (Chen et al., 2026; Karten et al., 2026b; Lee et al., 2026a,b; Lin et al., 2026a; Liu et al., 2026b; Nie et al., 2026; Zhang et al., 2026a); component targets include skills (Xia et al., 2026a; Yang et al., 2026b), memory (Liu et al., 2026a; Ouyang et al., 2026; Tang et al., 2025; Wu et al., 2026), and rollout preferences (Pan et al., 2026). Manual harness-engineering costs recur with each backbone release because the best harness is model-specific (Huang et al., 2026b).Source: §5 · p. 10
  • RRSI regularizes search dynamics through evolution-history credit, pre-scoring filtering of task-specific logic, and acceptance against a noise-adjusted baseline, while retaining an open edit space.Its contribution is orthogonal to which harness components existing methods edit.Source: §5 · p. 11
  • Benchmark-driven evolution can produce gains that disappear across suites (Huang et al., 2026d; Wang et al., 2026b).Delta attribution distinguishes edits that install reusable mechanisms from those fitting evolution tasks.Source: §5 · p. 11
  • Concurrent work targets generalization through explicit search objectives (Zhang et al., 2026d) or diversity-preserving archives of candidate harnesses (Luo et al., 2026).These approaches differ from RRSI’s regularization of proposal and selection dynamics.Source: §5 · p. 11

6. Conclusion

RRSI regularizes both proposal and selection during harness evolution, improving held-out and cross-benchmark performance while reducing inference cost relative to unregularized evolution.

6. Conclusion

  • RRSI improves held-out and cross-benchmark performance while using less inference cost than unregularized evolution across coding, agentic workspace, and engineering design tasks.The conclusion reports these improvements without numerical results.Source: §6 · p. 11
  • Adaptively reusing a finite evolve set can make apparent self-improvement reflect benchmark-specific fitting, evaluation noise, or unnecessary complexity rather than transferable progress.This motivates regularizing the recursive evolution process itself.Source: §6 · p. 11
  • RRSI regularizes proposal and selection while leaving the harness edit space open, controlling how repeated feedback becomes persistent changes.The paper studies iterative harness evolution as a practical form of recursive self-improvement at the agent-system level.Source: §6 · p. 11

Limitations · Contents of Appendix

RRSI studies harness-level self-improvement with frozen models, and its effectiveness may depend on feedback quality and search budget. Despite evaluations across domains, benchmarks, and policy models, broader validation is needed for different architectures, tool ecosystems, and longer-running evolution.

Limitations

  • The study addresses harness-level evolution with frozen backbone models, not settings where model weights change during self-improvement.Source: Limitations · p. 11
  • RRSI’s effectiveness may depend on the quality of the feedback signal and the chosen search budget.Source: Limitations · p. 11
  • RRSI still relies on a finite evolve set and several regularization hyperparameters.Source: Limitations · p. 11
  • Broader validation is needed to establish generalization to substantially different agent architectures.The existing evaluation covers transfer across multiple domains, benchmarks, and policy models.Source: Limitations · p. 11
  • Generalization to substantially different tool ecosystems requires broader validation.Source: Limitations · p. 11
  • Broader validation is needed to determine how well RRSI generalizes to longer-running self-improvement processes.Source: Limitations · p. 11

A. Evaluation … A.8. Frontier-Eng

Harnesses and baselines are evaluated under matched timing, tools, judges, and trial counts. The eight benchmarks use task-specific tests, rubric scores, expert comparisons, or deterministic engineering evaluators.

A. Evaluation / A.1. Terminal-Bench 2.1

  • 89 tasks determine Terminal-Bench 2.1 accuracy: the fraction passing hidden task-specific tests after the agent finishes its shell-based work (Merrill et al., 2026).Each task runs in a container rebuilt between evaluation arms to prevent state carryover. Across evaluations, harnesses and baselines share the same evaluation window, tool environment, judge, and trial count.Source: §A.1 · p. 17, A. Evaluation · p. 17

A.2. SWE-bench Verified

  • SWE-bench Verified measures resolve rate: patches must pass fail-to-pass tests while preserving pass-to-pass tests on issue-specific repository snapshots.Each instance pairs a real GitHub issue with the repository snapshot from the time of its report.Source: §A.2 · p. 17

A.3. Harvey LAB

  • 160 Harvey LAB tasks are partitioned into fixed 120-task evolve and 40-task held-out sets, with performance measured by the fraction of criteria passed.Tasks provide Word, Excel, and PDF sources and require exact deliverable filenames (Harvey AI, 2026); Gemini-3.5-Flash independently judges 20 to 100 criteria per task, roughly 14,000 verdicts per evaluation. Longer rubrics contribute proportionally more to the score, and missing deliverables fail every applicable criterion.Source: §A.3 · p. 17

A.4. JobBench

  • JobBench measures weighted rubric scores on professional workflows requiring retrieval and production of office or PDF deliverables (Li et al., 2026).Tasks supply input files and wrapper prompts but deliberately withhold reference material; the harness exposes filesystem access, code execution, and grounded web search. Evaluation averages scores from Gemini-3.5-Flash and Claude Opus 4.8.Source: §A.4 · p. 17

A.5. GDPval

  • 185 GDPval tasks measure the harness’s deliverable win rate against benchmark-provided human expert deliverables (Patwardhan et al., 2026).Qwen3.6-35B-A3B, Claude Sonnet 4.6, and Gemini-3.1 Pro judge each pair in both presentation orders, with majority voting determining the task verdict. A win rate above 50% means harness deliverables are preferred more often than the paired expert deliverables.Source: §A.5 · pp. 17–18

A.6. APEX-Agents

  • 480 APEX-Agents tasks form the fixed pass@1 denominator, with infrastructure-related missing rollouts counted as failures rather than excluded (Vidgen et al., 2026).Sandboxed worlds span three professional domains and expose MCP tools for files, PDFs, spreadsheets, communications, calendars, documents, and code execution. Gemini-3.5-Flash judges per-task rubrics, and success requires satisfying the rubric on the single sampled rollout.Source: §A.6 · p. 18

A.7. EngDesign

  • 61 license-free EngDesign tasks support evolution without an in-distribution held-out split, using frozen deterministic simulations or testbenches rather than judge models (Guo et al., 2025).Tasks specify design goals and physical constraints and require no proprietary simulators. The suite is considered too small for a held-out split, and measured variance comes entirely from the policy.Source: §A.7 · p. 18

A.8. Frontier-Eng

  • 47 tasks define Frontier-Eng’s Medal Score denominator; this engineering benchmark is used only for out-of-distribution testing (Chi et al., 2026).Across 26 domains, frozen deterministic evaluators score continuous objectives; gold, silver, and bronze thresholds from the frozen v1 snapshot award 1, 0.67, and 0.33 credit, averaged and reported as a percentage. Overlapping EngDesign tasks are excluded and unbuildable environments receive no credit in either arm, leaving 38 tasks contributing credit under identical scoring coverage.Source: §A.8 · p. 18

B. Baseline Methods

The four harness-evolution baselines use execution experience or feedback to guide changes through code optimization, observability-driven editing, test-time adaptation, or modular configuration changes.

Meta-Harness

  • Meta-Harness (Lee et al., 2026b) optimizes executable harness code using an agentic proposer informed by previous candidates’ source code, evaluation scores, and execution traces.Harness engineering is formulated as an outer-loop optimization problem.Source: B. Baseline Methods · p. 18

Agentic Harness Engineering (AHE)

  • AHE (Lin et al., 2026a) organizes harness components, execution experience, and edit outcomes into explicit representations to diagnose failures, propose changes, and evaluate previous edits.Its observability-driven evolution loop targets coding-agent harnesses.Source: B. Baseline Methods · p. 19

Test-Time Harness Evolution (TTHE)

  • TTHE (Nie et al., 2026) evolves multiple executable harness candidates during test-time adaptation with fixed model weights, using execution traces for modifications and an agentic judge for selection.The selected harness persists to subsequent inputs.Source: B. Baseline Methods · p. 19

HarnessX

  • HarnessX (Chen et al., 2026) composes harnesses from modular, typed primitives and uses execution feedback to modify and select configurations over time.The primitives span prompts, tools, memory, and control flow.Source: B. Baseline Methods · p. 19

C. Method Details … C.3. Selection-Side Bookkeeping

RRSI regularizes transitions through an unrestricted source-edit space using annealed edit budgets, history-guided exploration and pruning, and noise- and cost-aware selection. Its L_0, L_1, and L_2 terminology describes complexity-control analogies rather than norm-penalized optimization.

C. Method Details

  • L_0, Lasso/L_1, and Ridge/L_2 denote analogous complexity-control roles, not norm-penalized objectives over a shared continuous harness parameter vector.These implementation details specify the same proposal- and selection-side regularizers used in the experiments.Source: C. Method Details · p. 19

C.1. Round-Level Formulation

  • RRSI leaves the reachable source-edit space unrestricted while regularizing transitions, calibrating empirical noise tolerance through repeated evaluations of the unchanged base harness.Evolution runs for T rounds from H_0, initializing the running best to its measured score. Round state includes feedback, edit history, the annealed budget, exploration directives, and structural pruning targets.Source: §C.1 · p. 19

C.2. Proposal-Side Bookkeeping

  • Each round redraws atomic edits, limits candidate bundles with an annealed budget, and records component-level history whose attribution improves toward single-edit candidates.Each measured edit receives component, hypothesis, and source-diff metadata; bundled edits share candidate-level score changes, cost changes, and selection outcomes. Only round winners are marked accepted, and the budget limits bundled edits rather than components eventually modifiable.Source: §C.2 · pp. 19–20
  • Stalled searches reserve exploratory candidate slots for untested components, while pruning targets exercised components lacking any strictly positive recent measured gain.Stalling means progress over the previous w rounds does not exceed empirical noise tolerance. The proposer receives unproductive components and their previously accepted edits, with instructions to remove that machinery.Source: §C.2 · p. 21

C.3. Selection-Side Bookkeeping

  • Above the empirical noise tolerance, acceptance permits larger inference-cost increases only when accompanied by larger measured improvements.This gain-dependent rule controls aggregate resource growth without requiring individual components to be eliminated; its Ridge/L_2 analogy is functional, not a squared-norm penalty.Source: §C.3 · p. 21
  • Within the noise band, candidates passing the performance floor face a shaped admissibility rule combining score change, relative inference-cost change, and structural novelty.Coding sets w_s = 0, requiring sufficient cost savings and/or novelty; agentic-workspace and engineering-design instances use positive w_s. Novelty counts distinct structural component types absent from prior winning edits, excluding prompt, control-flow, configuration, output-plumbing, and context-management edits.Source: §C.3 · pp. 21–22
  • 0.03 and 0.02 bound tolerated valid-output-rate decreases and no-submission-rate increases, respectively, for engineering-design candidates relative to the incumbent.Exceeding either threshold triggers rejection regardless of primary pass-rate gains. Coding and agentic-workspace instances apply no additional domain guard.Source: §C.3 · p. 22
  • Selection chooses the highest-scoring candidate satisfying the noise-adjusted performance floor, complexity-aware acceptance rule, and active domain guards; otherwise, it retains the incumbent.The leakage critic screens candidates before full evaluation, and the performance floor requires S_hat' >= S_star - delta. The running best score is updated after selection.Source: §C.2 · p. 20, §C.3 · pp. 21–22

D. Experiments · D.1. Hyperparameter Setting

RRSI sets its hyperparameters using only the evolve environment and operational considerations, without tuning on held-out or OOD benchmarks. These parameters control edit sparsity, exploration, pruning, and the trade-off between performance gains and inference cost.

D.1. Hyperparameter Setting

  • RRSI fixes hyperparameters without consulting held-out or OOD benchmarks, using only the evolve environment and operational considerations.Table 5 identifies the hyperparameters used in each evolution setting.Source: §D.1 · p. 22, Table 5 · p. 23
  • RRSI calibrates noise tolerance δ from repeated evaluations of the unchanged base harness.δ corresponds to 3 passes out of 178 trials for coding, 60 criteria out of roughly 14,100 criterion verdicts for agentic workspace, and 5 passes out of 244 trials for engineering design.Source: §D.1 · p. 22
  • 25% token allowances apply per additional coding pass or 100 additional agentic-workspace criteria; engineering design allows 10% per additional pass.β_0 and β_1 encode the gain–cost trade-off. Scores are fractions in [0, 1], and ΔC measures relative policy-token change per trial.Source: §D.1 · pp. 22–23
  • The edit-budget parameters b_min and b_max determine how many independent changes can be bundled into one candidate.Source: §D.1 · p. 22
  • The parameters w and m_draft control when and how strongly the search explores underused components.Source: §D.1 · p. 22
  • The pruning window n_prune determines how much recent evidence is required before a component is treated as unproductive.Source: §D.1 · p. 22

E. Qualitative Case Study

Representative evolution decisions show that RRSI retains changes based on measured benefit relative to complexity, rather than score alone. Lower inference cost does not guarantee acceptance, while a reusable control-flow correction can survive with little resource growth.

E. Qualitative Case Study

  • Only the first coding round’s candidate with a sufficiently large measured improvement survives cost-aware selection, despite the two candidates’ superficial similarity.This illustrates selection for sufficiently robust measured benefit relative to complexity.Source: E. Qualitative Case Study · p. 23
  • The round-8 candidate reduces inference cost but is rejected because its performance falls below the admissible floor.Source: E. Qualitative Case Study · p. 23
  • The engineering example retains a small, reusable control-flow correction with little resource growth.Source: E. Qualitative Case Study · p. 23
  • RRSI’s representative decisions depend jointly on candidate specificity, evaluation stability, and inference cost, rather than score alone.The examples come from released evolution trajectories.Source: E. Qualitative Case Study · p. 23, Table 6 · p. 24
Loading 2609.24972v1…