Anthropic Deleted More Than 80% of Its Own System Prompt. When Did You Last Delete a Rule?

Anthropic removed more than 80% of Claude Code’s system prompt and reported no measurable loss on its internal evaluations. That is self-reported, from the team with the most to lose if the number were wrong, which is exactly why it is uncomfortable. Four out of every five instructions in a production agent config were carrying no weight.

Now count the rules in your own agent config. Then count how many you have deleted this quarter.

Most teams have the same answer: zero. Configs only grow. Every misbehaviour adds a line, and nobody is assigned to take one away. The same logic governs sessions. Restarting a long-running agent feels wasteful, so the session runs on, accumulating history that looks like an asset.

Two practitioner essays published in August 2026 measured what actually happens to both. Addy Osmani looked at the files. Tomasz Tunguz looked at the lifetime. They arrive at the same operation from opposite ends.

The Files Decay

Osmani reports a June study across 100 repositories with three findings that describe the same failure. Lint leakage, in 62% of repos: linting and formatting rules sitting in the agent’s context when the linter already enforces them. Context bloat, in 42%: files large enough that the instructions compete with the task. Skill leakage, in 35%: skills loaded regardless of whether the task calls for them.

A separate context-files study ran 288 runs across 17 real tasks. One user cut their skill count from 250 to 25.

None of these numbers describe a writing problem. Every one of those lines was correct when someone added it. The linter rule was real. The skill was useful once. What changed is that the surrounding system absorbed the responsibility, and the instruction stayed behind as sediment.

This is the part that resists ordinary code review. A stale test fails. A stale dependency triggers an audit warning. A stale instruction in an agent config does nothing visible at all. It consumes tokens, competes for attention, and produces no error anyone can point at. We have written before about the context window as a budget rather than a bucket, and about how to write a CLAUDE.md that earns its space. Both assume someone is still deciding what belongs. The 80% result says nobody is.

Osmani also cites an arxiv study on personalized skills (arxiv.org/abs/2608.10319) with a result worth sitting with: “A skill based on one developer’s history performed about as well as a skill borrowed from somebody else. A generic skill built from lots of developers was more useful overall.” The experiments used an LLM-based simulator rather than live developers, so treat it as directional. Directionally, it undercuts the main reason teams give for hoarding bespoke instructions.

The Sessions Rot

Tunguz attacks the other half. His summary: “Long sessions rot from the inside out.”

The mechanism is compaction. When a session exceeds its window, the runtime summarizes earlier history to keep going. Research by Shiyang Chen, cited by Tunguz, found that compaction drops standing rules in 30 to 59 percent of episodes. An instruction you gave the agent at the start of a session may or may not still be in context after several compactions, and nothing in the interface tells you which.

There is a security dimension that follows directly. Tunguz: “One malicious email or calendar invite can poison the conversation, quietly hijacking your schedule months down the road.” A long-lived session is a long-lived attack surface. Anything that enters the context stays until compaction removes it, and neither source describes a compaction step that treats a poisoned message differently from any other.

His proposal is to make lifetime an explicit design parameter. A coordinator agent lives 24 hours: it loads its preferences at the start of that window, delegates for its lifetime, writes what it learned to disk, and terminates. Specialist agents live about 30 seconds.

Durable state moves to disk. Durable state moves to disk: the lasting preferences are written to a preferences.md file and the conversation that produced them is discarded. Tunguz puts the rule plainly: “throw away the conversation; keep the rules in a file to keep your agent and its garden healthy.”

Same Operation, Two Names

Osmani is deleting lines from a file. Tunguz is deleting a running process. Both are removal, and neither is on anyone’s calendar.

Additions have an obvious trigger. The agent does something wrong, you add a rule, the wrongness stops. The feedback loop closes in minutes. Removal has no trigger at all. No incident announces that a rule has expired. The cost of keeping it is diffuse, spread across every future session as slightly worse attention allocation, which is precisely the kind of cost an organization never assigns to anyone.

We described a version of this in the governance deficit around self-improving agents: systems that learn continuously without a mechanism for unlearning. Config accumulation is the low-tech version of the same failure, and it is happening in repositories that have no learning system at all. Passive context has the same exposure. Context that loads automatically is context nobody re-reads.

The Removal Test

The useful thing about Osmani’s essay is that it gives you a test rather than an opinion. Disable all local skills, retry the task with the raw model, and see what breaks. If the output is the same, the instruction was not earning its place.

That test is falsifiable in a way that “is this rule still relevant?” never is. Reading a rule and judging its relevance produces a yes almost every time, because the rule reads as sensible in isolation. Running the task without it produces evidence.

The tooling covers part of this. Osmani’s audit list for /doctor is unused skills, MCP servers, over-specification, and slow hooks. Auto-memory is reviewed separately, with /memory. Recommended cadence: every two to four weeks, monthly at minimum.

Two to four weeks is a recommendation, not a measured decay point. Nothing in either source tells you the week a config goes stale. What both sources establish is that decay is real and invisible, which makes an arbitrary cadence better than the alternative of waiting for a signal that never arrives.

Do This Now

Three things, in order of how much they cost you.

Put the audit on the calendar. Every two to four weeks, monthly at the floor. It is a recurring event with an owner, not a task in a backlog, because backlog items about invisible costs never get pulled.

Run the removal test on your five largest instruction blocks. Disable, retry with the raw model, compare. Delete what survives the comparison unchanged. Expect to be wrong about which ones those are.

Set a lifetime for your long-running agents and let them die. Write the durable part to a file first. If your coordinator has been running since last month, its standing rules have been through compaction repeatedly, and you have no record of what came out.

The default assumption is that agent state appreciates. The measurements point the other way. A config and a session both have a half-life, and the only maintenance operation that addresses it is the one nobody schedules.

---

This analysis synthesizes Audit your agent files (Addy Osmani, August 2026), How long should an AI agent live? (Tomasz Tunguz, August 2026), and Victorino Group’s prior work on context budgets and agent governance.

Victorino Group builds the audit and removal discipline that keeps agent configs and sessions from silently rotting in production. Let’s talk.