Every rule in AGENTS.md and every skill showed up for a specific reason. The agent got something wrong, we worked out what it was missing, and wrote it down so it wouldn’t happen again. That’s the right loop, and the whole environment rests on it. But it has a side effect: it only adds. Rules appear after every hard task, and nobody ever comes back to remove them.
And we wrote them for a specific model at a specific moment. The skill that teaches the agent how to lay out migrations properly was an answer to the fact that the model couldn’t do it six months ago. Since then, one or two model generations have shipped. Maybe it’s been able to do this for a while, and the skill keeps sitting there, loaded into context on every task.
No rule is free. Each one eats context, and the more instructions there are, the less attention each of them gets. It’s worse when a rule encodes a workaround for an old limitation: the new model would solve the task its own way and better, and we force it to do it the old way. An environment that helped six months ago starts quietly getting in the way, and it’s nearly impossible to notice from the inside, because everything still seems to work.
You can’t look at the rules and decide which ones are dead weight. Each one looks reasonable on its own, and each has a real story behind it. The only way to find out whether a rule is load-bearing is to remove it and see what breaks. So every six months I take the team’s typical recent tasks and hand them to the agent without our skills, rules, or AGENTS.md. Same tasks, same repository, bare model.
Then you compare more than “did it or didn’t.” What matters is how many review fixes it needed, where it went the wrong way, which decisions had to be rolled back. The results usually fall into two piles.
The first pile is what the model now handles on its own. The rules for those tasks can go. They no longer teach the agent anything, they just take up space and sometimes argue with how the model would have done it. Like old feature flags: needed once, now they just make the system more complicated.
The second pile is where the bare agent still falls apart. This is the interesting part. It’s usually not about general programming skill, it’s about knowledge the model doesn’t have and never will: how your product works, which domain invariants can’t be broken, which architectural decisions were made and why, where the security boundaries are. That is the real value of your environment. No future model generation will learn it for you, because it isn’t on the internet. Only you have it.
So a run without skills answers two questions at once. What you can throw out to make the environment lighter and faster. And where to invest next, because that’s exactly where the model is helpless without you. It’s also a check on the environment itself: if the bare agent does as well as it does with your skills, your skills aren’t working, and that’s worth knowing too.
Six months isn’t arbitrary. That’s roughly how fast models are changing right now, and roughly how long it takes an environment to accumulate rules nobody remembers adding. Checking more often is expensive and pointless; less often, and the dead weight piles up.
An agent environment has to shrink as well as grow. The loop that adds something after every task is necessary, but without a regular check it turns into sediment, where you can no longer tell what’s useful from what’s obsolete.