Self-Evolving Agent Harness

1 INTRODUCTION

• Harness revisions are directly inspectable and trackable, can reuse an existing model deployment, and may reduce adaptation and maintenance costs.The analysis holds the task model fixed to isolate harness self-evolution; joint model–harness evolution is addressed separately.Source: §1 · p. 2
• The framework separates interpreted-state updates from executable revisions, then treats candidate search and admission as distinct mechanisms.Interpreted-state changes affect instructions, stored experience, or task-level coordination; executable revisions affect implementations, runtime control logic, or plugin composition.Source: §1 · p. 2
• The paper maps harness search to evolutionary structures and derives conditional results for expected generalization, bounded accumulated regressions, and high-probability admission.The analysis draws on classical stability and concentration results.Source: §1 · p. 2
• The paper analyzes propagation and repair burdens across five settings and connects cases to model–harness pairing, deployment, and reuse decisions.It emphasizes continual validation and safety constraints.Source: §1 · p. 2

2 DEFINITION OF HARNESS SELF-EVOLUTION

• A harness is the software and configuration governing a model’s execution in a task environment, and its final assessment J cannot be modified by candidates.The assessment includes scoring, outcome verification, and the records that determine the result.Source: §2 · p. 2
• At each round, the incumbent harness generates a batch of rollouts, and an update uses that batch to produce the next harness.The rollouts include trajectories, outcomes, and available feedback.Source: §2 · p. 3
• The update operator combines diagnosis, proposal, assessment, and admission; if no revision is admitted, the incumbent is retained.The operator may use historical feedback, archived candidates, and additional validation rollouts.Source: §2 · p. 3
• The lifecycle requires feedback from the system’s executions, continued update capability, and accepted revisions stored for later runs.Feedback may come from environments, automated assessors, or people, and admission may require human approval.Source: §2 · p. 3
• Appending logs or compacting context under fixed rules is not harness revision, whereas learning reusable procedures or changing memory policies is.Revising the update mechanism adds another level of recursion.Source: §2 · p. 3
• Self-evolution names the update process, while self-improvement means a gain established by comparison; weight-only adaptation is outside this scope.Harness RSI names the research area and does not assume every revision helps.Source: §2 · p. 3

3 THE TAXONOMY OF HARNESS SELF-EVOLUTION

• Interpreted revisions change task-level sequencing or routing through fixed operators; executable revisions alter implementations or runtime coordination, and target categories can overlap.Plugin composition may span component implementations and repository-level logic; classifying a target does not establish that the update meets the feedback, continuity, and persistence requirements.Source: §3 · pp. 3–4

3.1 TOOLS AND CODE PATCHES

• Component-level revision confines edits to callable procedures or designated modules, while stable interfaces support replacement and local checks.Changed outputs or shared state can still propagate regressions beyond the edited module.Source: §3.1 · p. 4

3.2 REPOSITORY AND RUNTIME LOGIC

• Repository-level search revises context construction, orchestration, execution hooks, recovery, and termination; changing shared context or scheduling can alter unchanged components’ assumptions.Archiving a candidate preserves it for further search, whereas adoption promotes it into the runtime for later tasks; an exported program retains the lifecycle only if its update mechanism remains.Source: §3.2 · p. 4
• 77.58% accuracy: GPT-5.4-nano with HarnessOpt and skill exceeds GPT-5.5 with SkillOpt at 76.20% on SpreadsheetBench.Across all four models, HarnessOpt with skill improves on SkillOpt-Lite by 5.69–11.39 percentage points; the crossover does not establish superiority at matched cost.Source: Table 2 · p. 4, §3.2 · p. 4

3.3 EVERYTHING IS A PLUGIN

• Plugin architectures revise component implementations or bindings for runtime services under interface, dependency, and lifecycle constraints, but these constraints do not establish behavioral isolation or safe admission.Adoption still requires validation of composed behavior.Source: §3.3 · p. 5
• EIP spreadsheet tool calls fall from 13 to 3, while wall time rises 54.9% and tokens 15.7%; reported cumulative savings reach 110,351 tokens and 22.97 s after five tasks.The first-task totals and cumulative row 1 disagree on token and time increases, so the two reports do not form one cost trajectory.Source: §3.3 · p. 5, Table 3 · p. 5
• LiveBrowseComp reports 51.39 for XYZ + dsh-everything versus 48.7 for XYZ-Aquila-mini, ranking it first among six displayed < 40B entries and second among all eleven.The score unit is unspecified; repeated runs and matched budgets and task quality are needed to establish causal plugin gains or general reuse benefits.Source: Table 4 · p. 5, §3.3 · p. 6

4.1 AN EVOLUTIONARY PERSPECTIVE ON HARNESS SEARCH

• Evolutionary search separates mutable-state representation, edit variation, fitness assessment, and selection; empirical selection can still overfit or forget.Local elitism, archive diversity, and Pareto selection offer distinct search strategies.Source: §4.1 · p. 6

4.2 GENERALIZATION AND RETENTION FROM A CONTINUAL PAC-LEARNING PERSPECTIVE

• The expected generalization-gap bound concerns the complete update process under independent task sampling and stability analysis, not the gap in any individual run.Small code edits alone do not establish stability of the full process.Source: §4.2 · p. 7
• Retention is bounded only under fixed historical-risk regression budgets, whose allowances accumulate across later transitions.Those budgets are separate assumptions, not consequences of stability.Source: §4.2 · p. 7
• Admission uses fresh independent tasks from the historical mixture to compare a bounded set of candidates, accepting only candidates with negative upper bounds.Search-time checks that reuse tasks lack the assumed independence; edits or merges informed by validation data need fresh validation.Source: §4.2 · p. 7
• The admission certificate applies to the historical mixture, not arbitrary future distributions, and concerns evaluator-defined loss without a bound on evaluator discrepancy.A discrepancy bound requires executable checks or independent human assessment.Source: §4.2 · p. 8

Personal workspaces

• Personal workspaces can preserve project conventions and preferences, but accumulated workarounds or skills may persist and generalize harmfully.Reviewable changes, provenance, and recovery of derived artifacts support ongoing curation.Source: §5 · p. 8

Enterprise automation

• Enterprise skill libraries reuse operational fixes, but shared faulty procedures can cause correlated errors across teams with different permissions or data assumptions.Containment may require identifying consumers, withdrawing versions, and restoring dependent workflows.Source: §5 · p. 8

Scientific discovery

• In scientific discovery, reusable protocols can spread specification gaming, consuming laboratory resources before independent measurement detects failure.The final assessment must remain outside the editable surface; independent measurement and replication are needed for scientific validity.Source: §5 · p. 8

Robotics and embodied interaction

• In robotics, accepted action-code errors can persist across motions, while software rollback cannot reverse physical damage or injury.The authors recommend keeping emergency stops, force and speed limits, and authorization checks outside the editable surface.Source: §5 · p. 8

Public services and clinical systems

• In public services and clinical systems, erroneous persistent rules may reproduce disadvantage, while rollback alone cannot recover missed treatment or denied entitlements.The authors recommend recording rule versions, evidence, and admission history alongside accessible review and remediation.Source: §5 · p. 9

6.1 MODEL–HARNESS CO-DESIGN

• Model–harness co-design studies should compare model selection, skill optimization, runtime revision, and weight updates while accounting for adaptation and execution costs.Testing frozen, transferred, and re-evolved harnesses across checkpoints can distinguish transferable gains from gains requiring further evolution.Source: §6.1 · p. 9

6.2 DISTRIBUTED EXECUTION AND EDGE INFRASTRUCTURE

• Client–edge co-inference minimizes latency across 100–500 KB/s in the cited study.Future comparisons should include harness synthesis, validation, and distribution costs at matched quality and subject to privacy constraints.Source: Figure 3 · p. 9, §6.2 · p. 9

6.3 PLUGIN CREATION AND REUSE

• Plugin lifecycle studies should measure when reuse repays creation and validation costs, including repair and dependency maintenance, at matched quality.Admission should assess the resulting composition because a locally valid plugin can alter shared state or other components' behavior.Source: §6.3 · p. 10

6.4 CONTINUAL VALIDATION UNDER DISTRIBUTION AND EVALUATOR DRIFT

• Continual validation should separate harness gains from workload drift and use fresh admission evidence; evaluator changes also require independent calibration of η.Reused calibration tasks cannot replace fresh admission evidence, and protecting the final assessment does not prevent specification gaming.Source: §6.4 · p. 10

6.5 SAFETY BOUNDARIES FOR SELF-MODIFYING SYSTEMS

• Safety studies should test harmful skill transfer and enforce least privilege, isolation, and limits on consequential actions.Validating composed behavior and revoking grants as dependencies change remain open problems.Source: §6.5 · p. 10

• Harness self-evolution combines feedback-driven revision, continuing update capability, and persistence around fixed models.Source: §7 · p. 10
• The framework separates mutation boundaries from search and admission, covering expected generalization, budget-constrained retention, and high-probability acceptance under fresh validation.Source: §7 · p. 10
• Persistent revisions can spread errors with irreversible consequences, so deployment requires continual validation under distribution and evaluator drift and independent controls over learning, runtime privileges, and consequential actions.Source: §7 · p. 10

• The paper presents a self-contained framework for harness self-evolution.Source: A EXTENDED TECHNICAL REPORT · p. 18
• The companion technical report provides broader literature coverage and extended discussions of evaluation, applications, and societal implications.Source: A EXTENDED TECHNICAL REPORT · p. 18
• The companion report is titled Harness Self-Evolution: Theory, Algorithms, Evaluation, Applications, and Impact.Source: A EXTENDED TECHNICAL REPORT · p. 18

4. Executable Update Targets

• Section 4 covers executable update targets, including tools and code patches, repository and runtime logic, and plugins.Source: §4 · p. 18

5. Theory of Harness Self-Evolution

• Section 5 covers an evolutionary perspective on harness search and continual PAC-learning perspectives on generalization and retention.Source: §5 · p. 18