Agent Builder Foundations

Appending an instruction to an agent's instruction file costs nothing — one more line. Safely deleting one costs a proof that it won't reintroduce whatever bug or regression it was added to prevent, and once the reason is forgotten, that proof requires reasoning about how the instruction interacts with every other instruction still in the file. That verification cost grows exponentially with file size, so in practice nobody pays it, and the file only grows. The one intervention shown to reverse this: write the rationale down as a comment next to the rule when you add it, not just the rule itself.

Don't model an instruction file as a static document you occasionally tidy. Model it as an append-only log with an invisible, growing debt: every instruction you add without recording *why* is a future deletion decision that will cost more the longer it sits there, because the number of things it might silently depend on only grows as the file grows. "Clean sweep" rewrites don't fix this — they reset the size but not the underlying asymmetry, so the same growth pattern starts again immediately. The actual fix has to change the unit economics of deletion, not the file's current size.

Consider a prompt with |D| instructions. Appending instruction number |D|+1 is O(1) — write it, done. But suppose instruction i was added months ago to fix some specific failure, and nobody wrote down what that failure was. To safely remove it now, you'd need to know whether any of the file's other instructions only work correctly *in combination with* instruction i — an interaction that could, in the worst case, depend on any subset of the remaining |D|-1 instructions. Checking all of those subsets is O(2^|D|). No team does exponential verification before deleting a line from a prompt, so the rational default becomes "leave it in," and the file accumulates rules whose purpose nobody can reconstruct.

The paper measures exactly this pattern at scale: across 247,694 instruction lifetimes in 1,867 repositories, agentic instruction files grew by +226% over their lifetime on average, adding a net +4.9 instructions per commit, and the deletion hazard falls with age (log-hazard -0.032 per commit) — the older an instruction is, the less likely anyone ever removes it. That's the signature of the cost asymmetry playing out in real repositories, not a hypothesis.

The proposed fix targets the actual bottleneck: the missing rationale, not the instruction count. Writing an instruction's *latent reasoning* as an inline comment turns "why is this here" from something you'd have to reconstruct by testing into something you can just read and re-check. To test this cleanly, the paper inverts IFEval — building synthetic "verifiable worlds" where the truly optimal, minimal instruction set is known in advance, so "excess instructions" can be measured exactly rather than estimated. Rationale-bearing comments cut excess instructions from +211.3% down to +1.4% relative to the optimal set, a 99.3% reduction in bloat. Applied to WildIFEval, a real-world instruction-following benchmark, the same intervention improved agentic instruction-following by up to 23.1% — the fix isn't just about file size, it also changes whether the agent follows the instructions correctly.

O(2^|D|) sounds abstract until you picture what "safe to delete" actually requires. If a file has |D| instructions and any pair (or larger group) of them could interact — instruction B only matters *because* instruction A exists — then proving instruction A is now redundant means checking its effect across every possible combination of the others still present. The number of subsets of a set of size n is 2^n, so the check grows exponentially with file size. At 10 instructions that's 1,024 combinations; at 30 instructions it's over a billion. Nobody does that check by hand, and an agent can't exhaustively re-verify it either without an explicit statement of what each instruction guards against — which is precisely what a rationale comment provides: it turns an exponential search over hidden interactions into a linear read of a stated dependency.

• Theory: the paper names catastrophic remembering as the structural mirror of catastrophic forgetting, and grounds the growth-only behavior in the O(1)-append vs. O(2^|D|)-verified-delete asymmetry — a mechanism, not just an observation.
• Benchmark/measured: the 247,694-instruction-lifetime, 1,867-repository measurement is an empirical characterization with a disclosed method (lifetime tracking across commit history), not a survey or anecdote; the IFEval-inversion and WildIFEval results are controlled benchmark evaluations of the proposed fix, also with disclosed method.
• Caveat: this is currently a single-author preprint submitted 2026-08-11, with no independent replication yet. The qualitative mechanism (cost asymmetry, rationale-as-fix) is sound and worth acting on; treat the specific percentages (226%, 4.9, 99.3%, 23.1%) as this paper's own reported figures, not an independently confirmed community result, until replicated.

• When you add a rule to CLAUDE.md, AGENTS.md, or a system prompt, write down why next to it — the failure it prevents or the constraint it enforces — not just what to do. This is the one intervention the paper found to actually reduce bloat, not brevity or better organization.
• Audit instructions whose stated rationale is now stale or no longer true, and delete those first. A documented rationale turns a combinatorial guess into a single fact-check: is the reason this was added still real?
• Track net instructions added per commit as a metric on any file agents read as instructions. A file drifting upward by roughly the same handful of net lines every commit, with no corresponding deletions, is this paper's growth signature, not an acceptable "just one more rule."
• Treat old, undocumented instructions as your highest-risk debt, not your safest ones — deletion likelihood measurably falls with age, so the longer an unexplained rule survives, the less likely it ever gets reconsidered.
• Don't rely on periodic "clean sweep" rewrites as the fix. They reset size, not the underlying cost asymmetry — without a rationale-comment discipline, the same unbounded growth resumes on the very next commit.

• Deleting an old, undocumented instruction on a hunch, causing a regression it silently prevented — which then makes the team even more reluctant to ever delete anything again.
• Assuming the fix is "write shorter instructions" rather than "write why an instruction exists" — the measured intervention is rationale-bearing comments, not terser prose.
• Treating this as specific to CLAUDE.md when the same mechanism applies to any accreting instruction surface an agent or a team reads as authoritative: system prompts, onboarding runbooks, review checklists.
• Citing the 99.3%-bloat-reduction or +23.1%-instruction-following figures as settled, replicated science instead of what they currently are — a single preprint's own benchmark results.
• Confusing this with session-level context bloat: this mechanism is about a persistent file growing across a codebase's commit history, not a live conversation's token count growing turn by turn.

See agent memory for how agents retain and lose information across steps and sessions, and context compaction for the mechanics of shrinking accumulated context without losing what matters. agent-context-lifecycle is the sibling Foundations concept: it covers a single session's conversational context growing quadratically in token cost, a different failure mode from a persistent instruction file's unbounded, cross-commit growth described here.