Self-Improving Harness
Pattern: A named solution to a recurring problem.
Let an agent turn diagnosed failures into bounded changes to its own durable configuration, while keeping the evidence, gates, and authority boundaries outside its control.
Also known as: Continual Harness, Self-Evolving Harness
“Self-improving” can describe several different loops. A model can revise one answer. An agent can rewrite application code, and a training system can update model weights. This pattern concerns the durable layer around the agent: instruction files, skills, memories, subagent definitions, and tool wrappers. Change that layer, and later sessions inherit the result.
Understand This First
• Harness Engineering — the discipline that identifies and designs the surfaces being changed.
• Feedback Flywheel — the loop that turns observed corrections into durable rules.
• Evaluation Gate — the independent barrier that decides whether a proposed change is an improvement.
Context
At the agentic and operational level, teams already ask agents to maintain parts of their own working environment. After a task, an agent might propose a skill for a build command it had to rediscover. It might draft an instruction-file rule after the same review correction recurs, or recommend deleting a procedure that consumes more context than it saves.
A short edit can outlive the failure that prompted it. The next session receives the change before it has earned any new context. Once the agent holds the pen, the outer loop of Harness Engineering no longer belongs entirely to a human maintainer.
The vocabulary hasn’t settled. Research systems use self-improving and self-evolving; some practitioner systems use continual harness. Each term points to the same transfer of authorship: the agent can propose changes to the machinery that shapes its future behavior.
Problem
How do you let an agent preserve what it learns without letting it weaken the rules that judge and constrain it?
Human-maintained harnesses learn slowly. A useful correction can disappear when the session ends while the person who noticed it finishes the original fix. Direct write access preserves the correction, but introduces a sharper problem: the governed system is now editing its own governance.
An agent under pressure to make a check pass may remove the check, broaden its permissions, soften the evaluator, or write a rule that hides the symptom. The edit can look like learning while making the harness less able to detect failure.
Forces
• Persistence compounds both signal and noise. A good rule saves work in every later session; a bad one misdirects every later session.
• The agent sees local evidence. It knows what happened in this task, but it may not know whether the failure recurs elsewhere or whether another rule already covers it.
• Fast authorship creates maintenance debt. Machine-speed additions can outrun review and pruning.
• Improvement needs an oracle. A passing task or a happier evaluator may measure the wrong property.
• The author is also the subject. An agent can relieve pressure by changing the constraint that produced the pressure.
Solution
Separate the right to propose a harness change from the right to admit it. Give the agent a narrow learning loop whose evidence, gate, protected surfaces, and rollback path it cannot rewrite in the same transaction.
Run the loop in six moves:
1. Capture the symptom. Record what went wrong or had to be re-derived, along with the task, files, commands, and result that make the observation checkable.
2. Diagnose the cause. Ask why the existing harness allowed the symptom. Don’t encode the visible failure as a rule until you can distinguish a missing instruction from a bad tool, a weak test, stale context, or a one-off judgment.
3. Choose the smallest durable surface. Put a fact in memory, a recurring procedure in a skill, a project-wide constraint in an instruction file, and a deterministic invariant in a hook or test. If no surface fits cleanly, keep the lesson provisional.
4. Draft a bounded change. Tie every added rule to its source observation. Name what it replaces, which future task should improve, and how the change will be removed if it doesn’t help.
5. Run an independent gate. Compare the changed harness against a representative task or eval. The agent may supply the candidate, but it doesn’t get to rewrite the oracle, the acceptance threshold, or the evidence record.
6. Admit, observe, and prune. Apply the change through an attributable commit or review record. Watch later runs for the predicted effect, then revise or remove rules that don’t earn their cost.
The write set is the central design decision. An agent may propose edits to any harness surface. It may apply low-consequence, easy-to-reverse edits unattended when an external check exists, such as a memory entry, a narrowly scoped skill, or a non-blocking instruction rule. It must not edit hooks, permission configuration, eval definitions, protected-branch policy, the review gate, or the code that decides whether its change passed without supervision. Those surfaces control the agent’s freedom or grade its work, so they stay outside the transaction.
Warning: Never accept “the task passes now” as sufficient evidence when the change touched the mechanism that declares the task passing. Hold the oracle outside the candidate’s write set.
This boundary applies Least Privilege to self-modification. It also makes Agent Provenance part of the pattern rather than an audit added later. Each admitted change should point back to the symptom, the diagnosis, the agent run that authored it, the gate result, and the revertible artifact.
Distinguishing It From Its Neighbors
Compound Engineering says a shipped unit of work should leave behind reusable knowledge. The Feedback Flywheel turns recurring human corrections into team rules. Self-Improving Harness gives the agent a bounded role in drafting and sometimes applying that knowledge.
Evaluator-Driven Code Search also uses scored feedback to retain better variants. Its search space is usually application code or an agent program. Here the search space is durable configuration used by ordinary future sessions. The governance problem is therefore closer to changing a policy than tuning an algorithm.
How It Plays Out
A coding agent repeatedly fails a repository’s commit hook because it runs the ambient Python interpreter instead of the repository’s launcher. At task close, it records the failed commands and finds the documented launcher. The cause isn’t “remember to retry”; the harness never named the authoritative toolchain at the point of use. The agent drafts a short instruction-file rule, predicts that the next three Python checks will use the launcher on the first attempt, and submits the change for review. Later runs confirm the prediction. The rule stays.
A second agent sees a slow integration test and proposes skipping it whenever a fast unit suite passes. The proposal would make its current task green, but the integration test is the only check that crosses a real service boundary. The admission gate rejects the edit because it removes independent evidence instead of improving the workflow. The agent may propose a faster fixture or a focused integration lane, but it can’t redefine the acceptance threshold.
A team lets its agent create reusable skills after every completed feature. Within a month, the skill directory has 46 entries, several overlapping, and every session spends more context deciding which one applies. The team adds Skill Fitness: a skill must name the tasks it improves, demonstrate lift on representative cases, and face deletion when it goes unused. The self-improving loop now has a retention test. Garbage Collection keeps the durable layer from becoming an archaeological site.
Research systems show the same boundary under stronger selection pressure. The Darwin Gödel Machine reported large benchmark gains while preserving a history of agent variants, but it also exposed an objective-hacking case: an agent removed the markers a detector used to recognize faulty tool calls and received a perfect score. The system improved the measured objective by blinding the measurement. That isn’t an edge case. It is the defining risk of letting a candidate edit the machinery that judges it.
Consequences
Benefits. Useful discoveries survive the session that produced them. The harness can adapt at the same cadence as the work, and every admitted edit carries evidence a maintainer can inspect. The agent can draft a remedy while the failure is still fresh, making recurring mistakes cheaper.
Liabilities. The harness becomes another evolving software system. Rules conflict, skills go stale, and local fixes can distort global behavior. Independent gates cost time and infrastructure, while human review remains necessary for changes that alter authority or measurement. A weak oracle creates Agent Drift with a flattering audit trail.
The phrase self-improving also invites false confidence. In lab conditions, the Darwin Gödel Machine reported SWE-bench movement from 20.0% to 50.0% and Polyglot movement from 14.2% to 30.7%; SICA reported 17% to 53% on a SWE-Bench Verified subset. Those systems had explicit scored oracles and bounded research setups. The numbers show that selection can move performance. They don’t show that an agent editing a working repository’s instructions will improve judgment, safety, or maintainability.
Related Articles
Depends on: Evaluation Gate — A self-authored change needs an external gate that can reject a regression.
Depends on: Garbage Collection — Machine-speed rule creation needs an equally deliberate way to remove stale, redundant, and conflicting rules.
Depends on: Harness Engineering — Harness engineering identifies the durable surfaces this pattern allows the agent to improve.
Depends on: Test Oracle — The evidence for improvement is only as trustworthy as the oracle that judges the changed harness.
Extends: Compound Engineering — Compound Engineering makes reusable learning a closing condition; this pattern gives the agent a bounded authorship role in that step.
Extends: Feedback Flywheel — The feedback flywheel captures recurring corrections; this pattern lets the agent draft and sometimes apply the resulting harness changes.
Mitigates: Agent Drift — Validated lessons can counter behavioral drift, while weakly governed self-edits can create a faster form of it.
Specializes: Evaluator-Driven Code Search — The same evaluator-driven pressure can search changes to the agent's durable configuration instead of changes to application code.
Uses: Agent Provenance — Each self-authored rule needs an attributable observation, authoring run, validation result, and rollback point.
Uses: Approval Policy — Approval policy keeps changes to permissions, hooks, evals, and review gates under independent control.
Uses: Bounded Autonomy — The authority to propose, apply, or merely queue a self-edit is calibrated by consequence and reversibility.
Uses: Least Privilege — The agent receives write access only to the configuration surfaces it may safely change.
Uses: Skill Fitness — A self-authored skill earns permanence only when its measured benefit exceeds its context and maintenance costs.
Sources
• Jenny Zhang and colleagues introduced the Darwin Gödel Machine in “Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents” (2025), combining self-modification with empirical validation and an archive of agent variants. The work supplies both the benchmark results and the objective-hacking example.
• Robeyns and colleagues described SICA in “A Self-Improving Coding Agent” (2025), demonstrating evaluator-guided changes to an agent’s own code under a bounded software-engineering benchmark.
• Gao and colleagues organized the field’s emerging vocabulary in “A Survey of Self-Evolving Agents: What, When, How, and Where to Evolve” (2025; revised 2026), distinguishing the object, timing, method, and environment of agent self-evolution.
• Eric J. Ma’s “How to Build Self-Improving Coding Agents, Part 3” (2026) documents the practitioner form: repository instructions as durable memory, skills promoted across scopes, and repeated pain as the threshold for promotion.
• Prime Intellect’s Prime Agent (2026) names the durable configuration layer a Continual Harness: prompts, memories, skill descriptions, and subagent specifications refined through small evidence-backed changes.