Should Coding Agents Rewrite Their Own Prompts? The Case for Undo Limits

A coding agent that rewrites its own prompts should only be allowed to make changes it can provably undo, according to EvoUndo (arXiv:2608.28363), a preprint observed 2026-09-17 that is author-reported and has no independent replication. Its undo-recovery figures come from deterministic oracle analysis, not live agents. The practical consequence: teams still hand-tuning AGENTS.md files should reframe the decision from reviewing every rewrite to budgeting rollback capacity, and freeze what cannot be verified.

Who edits the harness, and can they undo it?

Most teams treat a coding agent’s harness (its system prompts, tool descriptions, instruction files, scaffold code) as a static contract. A human edits AGENTS.md, reviews the diff, and merges. The alternative, letting the agent rewrite that scaffolding itself during a run, has mostly been discussed as a capability question: does self-evolution make the agent better?

EvoUndo reframes it as a recoverability question. The paper proposes “representing, synthesizing, diagnosing, and independently verifying recoverability of model-generated self-modifications across counterfactual states.” The operative word is independently: the check on whether a rewrite can be undone is not performed by the same model that proposed it. This matters because, as Groundy’s threat model of malicious AGENTS.md files laid out, an agent reads its instruction files as trusted context and acts on them without verification. Compounding self-modification is exactly the channel where gradual drift or an injected instruction would hide: each individual rewrite looks like a small improvement, and nobody is watching the accumulated state.

The preprint’s own scoping deserves a caveat up front. Its abstract does name the layers agents modify, opening with “prompts, tools, middleware, resources, and execution harnesses,” but it assigns no per-layer policy for which of them may be rewritten under what conditions. The layer-by-layer rubric later in this article is an extrapolation from that general claim, not a quoted finding.

The failure ledger: 197 irreversible improvements across 600 tasks

The empirical core of the paper is a count. Across 600 unseen one-shot self-evolution tasks, the authors identify 197 capability-improving mutations that fail recoverability verification. Read that carefully: these are not the mutations that made the agent worse. These are the ones that made it better, and they surfaced in roughly one of every three tasks.

That is the finding that should change how a team evaluates a self-evolving harness. The natural intuition is that risky self-modifications are the ones that degrade capability, and evaluation gates catch those. EvoUndo’s ledger says the more dangerous population is on the other side of the gate: changes that pass evaluation, improve measured capability, and quietly destroy your ability to return to the prior state. An eval gate answers “is the agent better now?” It says nothing about “can we get back?”

The paper then asks what happens when you try to improvise a rollback after the fact. Under the original recovery representation, conventional repair strategies recover 0 of these 197 natural failures. Zero. If your undo plan is “we will fix it when it breaks,” the author-reported evidence says that plan does not exist for this failure class. Rollback has to be designed in before the mutation happens, not repaired afterward.

Repair math: the recovery language is the product

The most consequential result in the preprint is not the failure count but the progression of what changes when you invest in the undo machinery itself:

Two readings follow. First, undoability is a designable property, not a fixed attribute of a mutation. Going from L0 to the extended recovery calculus lifted oracle recovery from 48 to 191 out of 197 (EvoUndo), which means most “unrecoverable” rewrites were only unrecoverable under an impoverished vocabulary for describing how to reverse them. The investment target is the recovery representation, the same way the investment target in conventional reliability work is the backup format, not the restore script.

Second, the recovery machinery carries its own costs. On the primary gpt-oss-120b backbone, adding exact-address diagnostics to the richer language reduced recovery within the oracle-defined S1 stratum, from 142/143 (99.3%) to 133/143 (93.0%). More diagnostic precision made undoing harder, at least in this configuration. The paper’s own Qwen3.8-27B replication preserved the grounding and expressivity effects but not this negative interaction, which the authors read as model-dependent; nothing in the abstract resolves why the regression occurs. It is a single-backbone result that should not be over-read, but it kills the naive assumption that better observability monotonically improves recoverability. Teams building undo gates should expect to tune the diagnostics against the recovery calculus, not bolt on logging and assume it helps.

A framing note on the numbers themselves: 191/197 comes from deterministic oracle analysis, a best-case reconstruction of what perfect recovery knowledge would achieve. It is an upper bound on what a deployed harness could do, not a measurement of one.

The counter-discipline: freeze, then evaluate

EvoUndo’s answer to irreversibility is to verify undoability before permitting live self-modification. Gauntlet (arXiv:2609.18996), an earlier preprint, demonstrates the opposite discipline working: the agent modifies freely for a bounded period, then the result is frozen forever.

In Gauntlet’s develop-freeze-evaluate setup, a general-purpose coding agent receives a game description, a raw observation/action interface, and an empty policy file, with no strategy, algorithm, or architecture provided. The agent engineers a standalone controller in a single autonomous session; that controller is then frozen and scored on held-out instances with zero model calls during play. The results are striking: at full-game scale, a compiled raw-API controller defeated every fair StarCraft II built-in AI and two cheating variants, and single-session programs won complete Civilization (Freeciv) games by total conquest on held-out seeds.

The freeze solves the undo problem by making it irrelevant. A frozen artifact cannot drift, cannot accumulate unreviewed rewrites, and can always be replaced wholesale by rerunning the development session. Rollback is trivial because there is nothing live to roll back.

This does not make Gauntlet a refutation of EvoUndo. It is evidence about where each discipline fits. Continuous in-run self-evolution buys adaptation during deployment; freeze-then-evaluate buys auditability and cheap rollback at the cost of re-running development when conditions change. Where undoability cannot be proven cheaply, the author-reported evidence favors freezing. Where live adaptation is the point, EvoUndo’s verification gate is the price of admission. A related pattern shows up in Groundy’s coverage of test-time harness evolution, where mutating the harness mid-run raised capability but pulled the verification layer into the solution space. Mutability keeps showing up as a capability gain with a verification debt attached.

Verification you can afford

An undo gate is only practical if the check is cheaper than the change. Two other September 2026 preprints in this fetched set address the cost side, though neither measures recoverability directly.

The Safety Signals paper (arXiv:2609.14422) constructs ground truth for NetArena’s network repair task via a symbolic replay of the emulated network, validated against the environment at every turn to yield the exact value of every action. Across 10 agent models, verifiers that use internal signals predicted both harm and progress more reliably than a baseline restricted to observable signals. That is encouraging for recoverability verification specifically: undo checks need to reason about counterfactual states, and internal-signal verifiers appear to carry more predictive power for that kind of judgment than black-box observation.

CERA-MoA (arXiv:2609.18779) attacks verification overhead differently: a predictive familiarity estimator built on mid-layer hidden states evaluates semantic competence among co-evolving agents without full rollouts. FrogNano (arXiv:2609.07925) improves a 4B coding agent through online task synthesis calibrated to the frontier of learnability for the current checkpoint. All three are capability-first in orientation; none quantifies what self-modification costs to undo. But they sketch the tooling a rollback-budget regime would need: cheap verifiers that run per-mutation, not per-rollout.

A layer rubric: what may rewrite itself

Because EvoUndo’s abstract names the layers agents modify but assigns no per-layer undo or freeze policy, the following is this article’s rubric, built from that general claim and the surrounding evidence, not a quoted taxonomy.

Self-modifiable, behind an undo gate: prompts and tool descriptions. These are the layers manual prompt tuning already touches, they are cheap to snapshot, and their state space is text, which a recovery calculus can plausibly address. This is where EvoUndo-style verification buys the most: a rewritten tool description that improves task success but cannot be cleanly reverted is exactly the failure shape counted in 197 of the paper’s 600 tasks. Teams already weighing automated prompt optimization against manual tuning, the tradeoff in Groundy’s DSPy coverage, should read the undo gate as the missing precondition for letting the optimizer write directly to the harness.

Freeze or compile: the policy and controller layer, where Gauntlet’s evidence applies. If a bounded development session followed by a frozen artifact meets the requirement, take the free rollback.

Frozen, always: permissions, network egress, and eval gates. If the agent can rewrite the gate that judges its rewrites, recoverability verification collapses into self-assessment, and the “independently verifying” clause in EvoUndo’s own definition is what prevents that. This matches the pattern from Groundy’s self-hosted agent safety analysis: controls that are unreliable as prompt-level rules have to be rebuilt as harness infrastructure, and harness infrastructure is precisely what the agent must not be able to edit.

The operational shift this implies is real. An AGENTS.md file stops being a static contract the moment a harness may rewrite it; it becomes mutable state with a provenance requirement. The review burden moves from “read every diff” to “fund enough rollback capacity and recovery vocabulary that the undo gate passes,” and the bottleneck moves from writing good prompts to designing action spaces in which every permitted action has a describable inverse.

Limits worth keeping in view

Every EvoUndo number above is author-reported from a single arXiv preprint. arXiv posts are approved after moderation but not peer reviewed, and no independent replication exists for any figure here. The measurements come from one-shot self-evolution tasks with a primary gpt-oss-120b backbone and a Qwen3.8-27B replication; the 191/197 figure is an oracle upper bound, not deployed-agent behavior. The diagnostics regression (133/143) was measured on the oracle-defined S1 stratum of the primary backbone and did not recur in the replication. Gauntlet, CERA-MoA, FrogNano, and Safety Signals carry the same single-preprint status. Treat “self-improving agent” marketing that cites capability gains without undo costs as unverified.

The verdict

For a team deciding whether to let a coding agent upgrade its own prompts: yes, conditionally, and the condition is not better evaluation but provable undoability. Permit a self-rewrite only after an independent recoverability check, because the author-reported ledger says 197 capability-improving mutations across 600 one-shot tasks fail that check and conventional repair recovers none of them. Spend the engineering budget on the recovery representation, where the extended calculus lifted oracle recovery from 48/197 to 191/197, and expect the diagnostics layer to fight you, as it did on gpt-oss-120b. Where you cannot afford that machinery, adopt the Gauntlet discipline instead: let the agent build, freeze the artifact, and evaluate the frozen thing. The decision is no longer whether the agent writes better prompts than you do. It is whether you can get your old harness back.

Frequently Asked Questions

What should teams do if they cannot afford the machinery for provable undoability?

Where you cannot afford that machinery, adopt the Gauntlet discipline instead: let the agent build, freeze the artifact, and evaluate the frozen thing.

Which layers of the agent harness should always remain frozen?

Frozen, always: permissions, network egress, and eval gates. If the agent can rewrite the gate that judges its rewrites, recoverability verification collapses into self-assessment, and the “independently verifying” clause in EvoUndo’s own definition is what prevents that.