# Self-Evolving Agent Harness

> Harness self-evolution—revising an agent's software scaffolding while keeping model weights fixed—yields conditional generalization guarantees and enables weaker models to outperform stronger ones.

- **Source:** [arXiv](https://arxiv.org/abs/2610.18813)
- **Published:** 2026-10-17
- **Permalink:** https://picx.dev/p/7XAbOQ
- **Whiteboard:** https://picx.dev/p/7XAbOQ/image

## Summary

# 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:

| Component | Runtime Role | Mechanisms |
|-----------|-------------|------------|
| Agent loop and execution control | Controls execution and termination | Model/tool calls; continuation, stopping, cancellation, recovery |
| Tool and skill orchestration | Exposes callable capabilities | Interfaces, registration, dispatch, skill loading |
| Context construction | Prepares each model input | System instructions, tool descriptions, dialogue history |
| Memory and state management | Preserves information across calls | Retrieval, reusable memory, persistence, resumption |
| Context compaction | Keeps inputs within context limits | Summarization, retention policies, pruning |
| Scheduling and coordination | Assigns work across execution loops | Delegation, task scheduling, background work |
| Execution infrastructure | Enforces boundaries, records activity | Sandboxes, permissions, storage, logs, replay |

**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**:

| Model | Initial | SkillOpt | SkillOpt-Lite | HO only | HO + skill |
|-------|---------|----------|---------------|---------|------------|
| GPT-5.4-nano | 29.89 | 51.60 | 66.19 | 76.51 | **77.58** |
| GPT-5.4-mini | 28.21 | 47.50 | 73.31 | 81.14 | **82.56** |
| GPT-5.4 | 39.86 | 61.50 | 79.36 | 83.63 | **85.05** |
| GPT-5.5 | 37.37 | 76.20 | 79.72 | 83.63 | **85.77** |

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):

| Tasks | Δ tokens | Δ wall time (s) |
|-------|----------|-----------------|
| 1 | +4,895 | +6.74 |
| 2 | −19,907 | −3.97 |
| 3 | −47,375 | −8.44 |
| 4 | −77,542 | −13.87 |
| 5 | −110,351 | −22.97 |

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):
$$\left|\mathbb{E}[R_s(H_k) - \widehat{R}_s(H_k)]\right| \leq \beta_{s,k}
\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.

---

_Markdown view of https://picx.dev/p/7XAbOQ, served by PicX — AI-generated visual whiteboard summaries of research papers._