Self-Evolving Agent Harness: A Comprehensive Summary

Summary (Overview)

• Formalizes "harness self-evolution": A framework where an agent's software scaffolding (prompts, memory, workflows, executable components) is revised through execution feedback while model weights remain fixed.
• Provides an operational taxonomy: Distinguishes between interpreted-state updates (instructions, memory, task-level coordination) and executable revisions (component implementations, repository-level control logic, plugin composition).
• Develops conditional theoretical guarantees: Uses evolutionary algorithm correspondences and continual PAC-learning to derive an expected generalization bound, a retention bound under historical regression budgets, and a high-probability admission rule using fresh validation data.
• Analyzes societal and safety implications: Examines how persistent harness revisions affect knowledge sharing, scientific reliability, physical safety (robotics), and institutional accountability across five application settings.
• Introduces the "Harness RSI" research area: Recursive self-improvement through harness revision, with comprehensive resources at https://github.com/zgcagi/Harness-RSI.

---

Introduction and Theoretical Foundation

Background and Motivation

As tasks and environments change after deployment, agents require continued adaptation. The paper focuses on harness self-evolution—revising the software scaffolding around a fixed model—for three primary reasons:

1. Direct behavioral control: The harness shapes a fixed model's behavior while reusable procedures preserve task constraints and lessons from earlier failures.
2. Cost efficiency: Harness revisions reuse existing model deployments, avoiding retraining and additional weight checkpoints, and permit updates through proprietary APIs without weight access.
3. Inspectability: Instructions, memory records, and code support direct inspection, version comparison, and change tracking, whereas attributing behavioral differences between model checkpoints requires controlled experiments.

Key Definitions

Harness: Following the model–harness decomposition, a harness $H$ is defined as the software and configuration governing a model $M$'s execution in a task environment $E$. Seven runtime functions are identified:

Execution and scoring:

$$\tau \sim \operatorname{Run}(M, H, E), \quad y = J(\tau). \tag{1}$$

Harness self-evolution lifecycle: At round $k \geq 1$, the incumbent $H_{k-1}$ generates a batch of $b$ rollouts:

$$\mathcal{B}_k = \{\tau_{k,i}\}_{i=1}^{b}, \quad \tau_{k,i} \sim \mathrm{Run}(M, H_{k-1}, E_{k,i}), \tag{2}$$ $$H_k = \text{Update}(H_{k-1}, \mathcal{B}_k). \tag{3}$$

Two essential requirements define the lifecycle:

1. Operational feedback and update continuity: The system uses its own execution feedback algorithmically and retains the update mechanism.
2. Persistence across runs: Accepted revisions are stored and loaded in subsequent runs.

---

Methodology

Taxonomy of Harness Self-Evolution

The paper organizes update targets along an interpreted/executable distinction:

1. Interpreted-State Updates

Revise instructions, stored experience, or task-level coordination over predefined capabilities. Workflow revisions remain interpreted when they change task-level sequencing through fixed coordination interfaces over predefined operators.

2. Executable Revisions

Organized into three categories:

• Component implementations: Confines mutation to callable procedures while keeping orchestration fixed (e.g., Self-Harness, HarnessCompass, Agentic Harness Engineering).
• Repository-level control logic: Exposes context construction, orchestration loops, execution hooks, recovery, and termination to revision (e.g., whole-agent synthesis, repository evolution).
• Plugin composition: Organizes mutation through declared interfaces, dependency constraints, and lifecycle operations (e.g., "Everything Is a Plugin" / EIP).

Theoretical Framework

The theory section uses two complementary perspectives:

Evolutionary Algorithm Correspondence

Four aspects of an update are separated: representation, variation, fitness assessment, and selection. Eight algorithmic correspondences are mapped to canonical EA structures (local elitism, archive-based diversity, Pareto selection), noting that empirical fitness selection can lead to overfitting or forgetting.

Continual PAC-Learning Perspective

Key definitions include:

• Population risk: $R_s(H) = \mathbb{E}_{z \sim \mathcal{D}_s}\ell(H, z)$
• Empirical risk: $\widehat{R}_s(H) = \frac{1}{n_s}\sum_{i=1}^{n_s}\ell(H, z_{s,i})$
• Stability under task replacement: Replace one task $z_{s,i}$ with an independent draw and rerun all downstream updates under coupled randomness to obtain $H_k^{(s,i)}$, then define: $$\beta_{s,k} = \frac{1}{n_s}\sum_{i=1}^{n_s}\mathbb{E}\left[\left|\ell(H_k, z_{s,i}) - \ell(H_k^{(s,i)}, z_{s,i})\right|\right]$$

---

Empirical Validation / Results

Case Study 1: HarnessOpt on Spreadsheet-Bench

HarnessOpt extends skill editing to runtime revision (spreadsheet previews, output checks, recovery after tool failures). Results show a model–harness crossover effect:

Notably, GPT-5.4-nano with HarnessOpt + skill (77.58%) exceeds GPT-5.5 with SkillOpt (76.20%), demonstrating that harness optimization can compensate for weaker models.

Case Study 2: Everything Is a Plugin (EIP)

Using DSH Everything, a Codex plugin enables tool generation during execution with retention for later tasks. Results from a simulated office workload:

First task costs: Tool calls drop from 13 to 3, but wall time rises by 54.9% and tokens by 15.7%.

Cumulative savings (EIP − baseline):

The paper notes an unresolved discrepancy between first-task totals and cumulative row 1, preventing treatment as a single cost trajectory.

Theoretical Results

Expected generalization bound (from replace-one exchangeability):

\tag{5}$$ **Retention bound** with regression budgets $\varepsilon_{s,u}$: $$\mathbb{E}R_s(H_k) \leq \mathbb{E}\widehat{R}_s(H_s) + \beta_{s,s} + \sum_{u=s+1}^{k}\varepsilon_{s,u} \tag{6}$$ **High-probability admission rule** (with fresh validation of $m$ tasks, $K$ candidates, $T$ rounds, confidence $1-\delta$): $$\Delta_k(H') \leq \widehat{\Delta}_k(H') + \sqrt{\frac{2\ln(KT/\delta)}{m}} \tag{8}$$ **Target-risk improvement condition** (with evaluator discrepancy $\eta$): $$\widehat{\Delta}_k(H') + \sqrt{\frac{2\ln(KT/\delta)}{m}} + 2\eta < 0 \tag{9}$$ --- ## Theoretical and Practical Implications ### Theoretical Implications 1. **Stability ≠ small code edits**: The bound in Equation (5) controls the expected generalization gap of the *complete update process*, not individual edits. Small code changes do not imply stability of the full process. 2. **Historical regression budgets are assumptions**: The retention bound in Equation (6) requires separate assumptions about per-transition regression, not consequences of stability. These allowances accumulate over time. 3. **Fresh validation is essential**: The admission rule in Equation (8) requires fresh, independent validation data. Search-time checks (e.g., reusing training tasks or held-out regression splits) lack the assumed independence. Secrecy and comparison-count corrections do not remove adaptive dependence. 4. **Certificate scope is limited**: Admission is certified on the historical mixture, not arbitrary future distributions. The discrepancy bound $\eta$ requires evidence from executable checks or independent human assessment. ### Practical Implications #### Five Application Settings Analyzed: 1. **Personal workspaces**: Revisable instructions and skills preserve conventions but risk temporary workarounds becoming standing rules or harmful skill generalization. 2. **Enterprise automation**: Shared skill libraries enable reuse but can spread faulty procedures causing correlated errors (algorithmic monoculture extended to persistent artifacts). 3. **Scientific discovery**: Persistent settings aid collaboration but evolving protocols can exploit provisional checks, leading to specification gaming that wastes resources before detection. 4. **Robotics and embodied interaction**: Errors in accepted action code can persist across motions; software rollback cannot reverse deformation, wear, or injury. Emergency stops, force/speed limits, and authorization checks must remain outside the editable surface. 5. **Public services and clinical systems**: Revisable procedures offer inspectability but erroneous preferences can become persistent rules reproducing institutional disadvantage. Software rollback cannot recover missed treatment windows or correct denied entitlements. --- ## Conclusion ### Main Takeaways The paper establishes harness self-evolution as a distinct research area characterized by: - **Feedback-driven revision** with continuing update capability and persistence around fixed models - **Clear separation** of mutation boundaries from search and admission mechanisms - **Conditional theoretical guarantees** distinguishing expected generalization, budget-constrained retention, and high-probability acceptance ### Key Recommendations 1. **Continual validation** is required as task distributions and evaluators change; reused calibration tasks cannot replace fresh admission evidence. 2. **Independent safeguards** must govern learning, runtime privileges, and consequential actions; creating capabilities must not confer authority. 3. **Rollback has limits**: Software recovery covers only effects within its recovery model; physical, financial, and institutional consequences require authorization limits and staged trials. 4. **Budget-matched studies** are needed to compare model selection, skill optimization, runtime revision, and weight updates fairly. ### Future Directions - **Model–harness co-design**: How to allocate adaptation effort between model and runtime, including transferable gains across checkpoints. - **Distributed execution**: Communication trade-offs in client–edge co-inference, including harness synthesis and validation costs. - **Plugin lifecycle economics**: When to reuse, revalidate, regenerate, or retire plugins based on task similarity and interface changes. - **Continual validation under drift**: Allocating budgets among calibration, admission, and regression checks remains an open problem. - **Safety boundaries**: Defenses should be evaluated by attack success, isolation time, and legitimate-work overhead. The paper concludes that persistent revisions preserve knowledge but can spread errors with irreversible consequences, demanding rigorous validation and independent safety controls throughout the evolution lifecycle.