Self-Evolving Agent Harness

AI summary

Overview

Research area: Self-improving AI agents, specifically the software scaffolding around a model—prompts, memory, workflows, tools, and runtime code—rather than the model weights. The paper connects agent systems engineering, evolutionary search, continual PAC-learning, and AI governance.

Technical level: Advanced. The paper combines formal definitions, a mutation-boundary taxonomy, conditional generalization and retention bounds, and systems-level safety analysis; its empirical material is a synthesis of prior cases rather than a new benchmark study.

Scope: The paper defines, classifies, and theoretically conditions “harness self-evolution”—feedback-driven revision of an agent’s harness with model weights held fixed—and draws deployment, validation, and accountability implications. The abstract describes a 66-page treatment with continuously updated code at https://github.com/zgcagi/Harness-RSI.

What This Paper Is About

Agents deployed into changing tasks and environments need to keep adapting, but retraining model weights is expensive and often impossible when the model is reached through a proprietary API. This paper asks whether the software around the model—instructions, memory, workflows, executable components, and runtime control logic—can revise itself from execution feedback and persist accepted changes across later runs. It supplies a shared definition, a taxonomy of what can be edited, conditional theory about when such revisions generalize and are retained, and a discussion of the organizational and safety consequences.

Key Contributions

1. Definition and operational taxonomy. The paper defines a persistent feedback-driven lifecycle for harness self-evolution and separates interpreted-state updates (instructions, stored experience, task-level coordination over predefined capabilities) from executable revisions (component implementations, repository-level control logic, and plugin composition). It also enumerates seven runtime functions of a harness: agent loop and execution control; tool and skill orchestration; context construction; memory and state management; context compaction; scheduling and coordination; execution infrastructure.

2. Conditional theoretical analysis. It maps harness search to evolutionary optimization and uses stability and concentration results from continual PAC-learning to derive an expected generalization bound, a retention bound conditional on historical regression budgets, and a high-probability admission rule that uses fresh, independent validation data. These results hold under explicit assumptions rather than as unconditional guarantees.

3. Systems implications and design trade-offs. The paper analyzes how persistent revisions propagate and create repair burdens across five settings (the provided excerpt does not enumerate them), and connects attributed cases to model–harness pairing, deployment, and plugin-reuse decisions. It argues for continual validation as task distributions and evaluators change, plus independent safeguards for learning, runtime privileges, and consequential actions.

4. Case synthesis across prior work. It organizes prior systems by mutation boundary—for example Self-Harness, HarnessCompass, Agentic Harness Engineering, HarnessBank, MetaHarness, Darwin, DarwinX, Huxley, HarnessX, Argus, Autogenesis, and ModularRSI—and reports quantitative examples on SpreadsheetBench and an office spreadsheet workload.

Main Findings

• The harness is the adaptation surface. Because the model is held fixed, adaptation happens through prompts, memory, workflows, tools, and runtime logic. The paper argues this avoids retraining and new weight checkpoints, works through proprietary APIs without weight access, and leaves changes that can be inspected, version-compared, and tracked.

• Persistence is the defining requirement. A system qualifies only if it uses feedback from its own executions to construct or select revisions and retains the update mechanism for later updates, while accepted revisions are stored and loaded in a subsequent run. Appending logs or compacting context under fixed rules does not count; learning reusable procedures or changing memory policies can.

• Executable revisions have three distinct scopes. Component-level patches keep orchestration outside the editable surface; repository-level revisions expose context construction, loops, hooks, recovery, and termination; plugin architectures edit bindings that determine which implementation supplies a runtime service. A revision can belong to more than one category, and classification alone does not establish that a method meets the feedback, continuity, and persistence requirements.

• Theory yields conditional, not blanket, guarantees. The expected generalization bound, the retention bound conditioned on historical regression budgets, and the high-probability admission rule depend on stated assumptions and on fresh, independent validation data. Empirical selection by itself does not establish generalization or retention.

• A weaker model with a better harness can beat a stronger model with a weaker harness. On SpreadsheetBench, GPT-5.4-nano with HarnessOpt and skill reaches 77.58%, exceeding GPT-5.5 with SkillOpt at 76.20%. The paper explicitly cautions that this crossover illustrates model–harness pairing but does not establish superiority at matched cost.

• Harness gains are large across model tiers. Across all four models, HarnessOpt with skill improves over SkillOpt-Lite by 5.69–11.39 percentage points. HarnessOpt extends the SkillOpt-Lite study from skill editing to runtime revision, improving spreadsheet previews, output checks, and recovery after tool failures.

• Self-generated plugins trade upfront cost for cumulative savings. In a simulated office workload using DSH Everything, a Codex plugin creates batch-lookup and summarization tools. First-task tool calls fall from 13 to 3, while wall time rises by 54.9% and tokens by 15.7%. A separately reported cumulative series shows savings from the second task, reaching 110,351 tokens and 22.97 s after five tasks.

• The plugin cost evidence is internally inconsistent. The first-task totals imply increases of 6,453 tokens and 8.51 s, whereas cumulative row 1 reports 4,895 tokens and 6.74 s. The paper calls this an unresolved difference that prevents treating the two reports as a single cost trajectory; negative cumulative differences indicate savings.

• Reliability is a continuing process. Because task distributions and evaluators change, deployment requires continual validation, admission based on fresh independent data, and separate safeguards for the learning process, runtime privileges, and consequential actions.

• Persistence changes organizational dynamics. The paper examines how retained harness revisions affect knowledge sharing and organizational workflows, with implications for scientific reliability, physical safety, and institutional accountability.

• Some reported evidence is incomplete in the provided text. Table 4 is labeled “LiveBrowseComp results” with columns “Model / harness” and “Score,” but the excerpt includes no score values, so those results are not reported here.

Methodology in Plain English

The paper first formalizes the setting. A harness H is the software and configuration governing a fixed model M in an environment E. Running the pair produces a rollout, scored by an assessment function J. Candidates may revise internal critics or provisional checks inside the harness but cannot modify J itself, which preserves an external standard for judging revisions.

The update loop is iterative. At round k, the current harness generates a batch of b rollouts with trajectories, outcomes, and available feedback. An update operator performs diagnosis, proposal, assessment, and admission. If no revision is admitted, the incumbent harness is retained unchanged. Accepted revisions become the state used for later execution, and their feedback can guide the next update.

The paper then classifies methods by where mutation is allowed—interpreted state versus executable code, and within executable code, component implementations, repository-level control logic, and plugin composition. This taxonomy is about the role of the edited artifact, not the programming language: a workflow that only composes fixed operators remains interpreted, while changing operator implementations or the runtime that enacts coordination is executable.

For theory, the authors treat

Authors’ abstract

Harness self-evolution revises an agent's software scaffolding, including prompts, memory, workflows, and executable components, while keeping model weights fixed. We formalize a feedback-driven process in which accepted revisions persist across runs. The framework separates update targets from proposal and admission mechanisms. It distinguishes changes to interpreted state from revisions to tools and code, repository-level control logic, and plugin composition. We characterize search through evolutionary optimization and examine its reliability through continual PAC-learning. Under explicit assumptions, the analysis yields an expected generalization bound, a retention bound conditional on historical regression budgets, and a high-probability admission rule using fresh, independent validation data. We examine how persistent harness revisions affect knowledge sharing and organizational workflows, with implications for scientific reliability, physical safety, and institutional accountability. Cases from prior work illustrate model--harness co-design, distributed execution, and plugin reuse. Reliable deployment requires continual validation as task distributions and evaluators change, with independent safeguards for learning, runtime privileges, and consequential actions. We provide a comprehensive 66-page discussion of related work, theory, algorithms, evaluation, applications, and the broader impact of Harness RSI, together with continuously updated code and supplementary materials, at https://github.com/zgcagi/Harness-RSI.