Self-Evolving Agents Rewrite Their Own Rules—Who Approves?

AI Agents are learning to modify their own rules. Two recent papers upgrade the "Agent Harness"—the software scaffolding that includes prompts, memory, workflows, tools, and code snippets—from a static configuration into an evolvable object. The model weights stay fixed; what changes is the software layer hosting them, and those changes persist across multiple runs. This raises a core operational question: who decides which changes get to stick?

The Agent Harness Becomes the Target of Evolution

Traditionally, an Agent's harness was treated as a one-time configuration: write the prompt, wire up the tools, design the workflow, then deploy and run. Even when the model doesn't change, this surrounding structure quietly accumulates experience—such as a successful tool-call sequence or a memory fragment proven effective. The papers formally treat this "change-as-you-run" process as an object of study: the model is fixed, and what evolves is the software layer that defines what the Agent sees, what it calls, and how it decides.

State Changes vs. Structural Revisions

Self-Evolving Agent Harness (arXiv:2610.18813) distinguishes two kinds of changes: state-level ones, such as modifying prompts or updating memory contents; and structural ones, such as revising tool definitions, adjusting repository logic, or recomposing plugins. The former is like changing parameters; the latter is like changing rules. The paper proposes an "admission mechanism" with independent verification to gate these changes, and discusses how generalization boundaries blur when the task distribution and the evaluator itself are also changing.

The term "Agent Harness" is borrowed from software testing and simulation, where it originally referred to the shell that wraps the system under test, providing a runtime environment and recording capabilities. In the LLM Agent context, it broadly refers to all the peripheral software outside the model weights that is written and maintained by engineering teams: system prompts, context assembly logic, memory write and retrieval strategies, tool (function-call) schemas and implementations, multi-step workflow orchestration code, retry and parsing logic, and so on. Distinguishing "model capability" from "harness capability" is a prerequisite for understanding self-evolution research: the same model can perform very differently under a carefully tuned harness versus a crude one, which makes the harness itself a worthwhile object of optimization. Traditional harnesses are iterated offline by human engineers; self-evolution research lets the Agent automatically generate harness modification proposals during operation.

The distinction between "state" and "structure" has a long history in computer systems: state is runtime-mutable data (memory contents, caches, session records), while structure is the code and rules that define how the system behaves (function definitions, types, protocols). Mapped onto the Agent harness, prompt text and memory entries are state—if changed incorrectly, the impact is limited and easy to roll back; tool definitions, evaluator implementations, and plugin composition are structure—once rewritten, they affect the behavioral logic and judgment criteria of all subsequent runs. This distinction matters because the risks and approval requirements of the two are not symmetric: state changes can use looser automated gating, while structural revisions require stronger independent verification, or even a human signature. Similar ideas have counterparts in database schema migrations and change management for infrastructure as code.

Two-Layer Recursion: The Ambition of Harness²

Harness² (arXiv:2610.14224) pushes self-evolution to a second level: it can recursively edit the running harness during task execution, and it can also recurse at the level of "the harness that improves the harness," using the experience accumulated from each edit for the next round. The paper reports that, on specialized benchmarks, a single step of evolution alone improved the performance of GLM-5 and Gemini 3.5 Flash configurations over the base harness.

The significance of this result is not whether "self-evolution can work," but that it turns the question from a research hypothesis into a realistic option for production deployment.

The idea of "recursive self-improvement" traces back to I. J. Good's 1965 intelligence explosion hypothesis and Jürgen Schmidhuber's formal work on self-referential improvement systems, whose core is that the system also treats its own capacity for improvement as an object of improvement. Harness²'s "two layers" are a lightweight engineering version of this structure: the first layer edits the harness in place during task execution, and the second maintains a meta-process dedicated to improving the harness, distilling the successes and failures of past edits into priors for the next round. It is important to note that what is recursively optimized here is the software scaffolding, not the model weights, so it involves no gradient updates or retraining—cost and controllability are far better than model-level self-improvement, but it also means the improvement ceiling is bounded by the harness's expressive capacity.

The Risk of Opening Production Capabilities to Agents

For teams running production Agents, the real question is not whether self-evolution works, but who holds the approval authority for persistent changes. A "lesson" distilled from one successful run can become a permanent rule—including the very rule used to judge the next round of changes. If change proposals and acceptance criteria remain in the same loop, the system effectively begins to govern itself without a clear human approval chain.

This is not alarmism. The admission mechanisms and independent verification discussed in the papers are essentially responses to this governance gap. In engineering practice, continuous validation, regression budgets, and the separation between "what an Agent may propose" and "what an Agent may write into the shared harness" go from research details to engineering necessities.

Implementation Checklist: Three Hard Requirements

First, inventory which parts of the harness are allowed to be rewritten. Not every component should be open to self-evolution; tool definitions and evaluation logic especially need protection. Second, require fresh evidence and independent verification before persisting a change—new rules cannot be approved using stale data or judgments from within the same loop. Third, retain rollback capability and version identifiers, ensuring that the Agent inherits a clearly identified version on the next run rather than an accumulation of changes of unknown provenance.

"Who approves changes" has a mature counterpart in software engineering: code review and merge permissions. One of the core designs of version control systems like Git is to separate "proposing a change" from "approving a merge," with branch isolation ensuring the mainline always remains in a known-good state. Treating the Agent harness as a version-controlled code repository naturally yields several engineering conventions: changes must be submitted as patches or PRs with an audit trail, they must pass tests independent of the proposer before merging, the mainline must retain revertible historical versions, and sensitive files (such as evaluation logic) should have protected branches. Moreover, the industry's familiar risk of "evaluator contamination" applies here as well—if an Agent can modify the tests or scoring scripts used to judge itself, any performance improvement numbers become meaningless, which is the fundamental reason for requiring separation between acceptance criteria and the proposal path.

Key Takeaways

• Recent research treats the Agent Harness (prompts, memory, tools, workflows) as an evolvable object while the model itself remains fixed.
• Self-Evolving Agent Harness distinguishes state changes from structural revisions and introduces an admission mechanism with independent verification.
• Harness² implements two-layer recursion, with a single step of evolution already improving performance on GLM-5 and Gemini 3.5 Flash configurations.
• The production risk lies in change proposals and acceptance criteria residing in the same loop, with no human approval chain.
• Engineering requires limiting the rewritable scope, requiring fresh verification evidence, and preserving rollback and version identifiers.

Without these boundaries, the Agent is changing the rules of the game without anyone signing off.

One-line Summary

Self-evolving Agent Harnesses let the software scaffolding modify itself, but who holds approval authority becomes the core governance question for production deployment.

Paragraph Summary

The article discusses self-evolution of the Agent Harness around two recent papers: model weights stay fixed, while the peripheral software layer—prompts, memory, tools, workflows—evolves, and changes persist across runs. Self-Evolving Agent Harness distinguishes state changes from structural revisions and proposes an admission mechanism with independent verification; Harness² implements two-layer recursion, with a single step of evolution improving performance on GLM-5 and Gemini 3.5 Flash configurations. The author points out that the real production question is not whether self-evolution works, but who holds approval authority for persistent changes—when change proposals and acceptance criteria sit in the same loop, the system effectively self-governs. The article offers three implementation requirements: limit the rewritable scope, require fresh evidence and independent verification, and preserve rollback and version identifiers.