Why does your agent keep following a rule you retired?

Your agent keeps importing from a module you deleted two months ago. You tell it not to. It stops for a session, then does it again.

The instinct is to add a rule: "Do not import from legacy_utils." Which works, until the next time, and meanwhile the file is one line longer.

The structural problem

An instruction file is a flat list of statements in one voice. Nothing in it carries a date, a status, or a priority. The rule written this morning and the rule written in March look identical to a reader who was not there for either.

So when a file contains a rule that has quietly stopped being true, the agent has no mechanism to notice. It reads a clear instruction, and it follows it — competently, which is what makes this expensive. A more capable model follows the stale rule more thoroughly.

The failure is not that the agent forgot. It is that it remembered something it should not have.

Why the corrective rule backfires

Adding "do not do X" alongside the old rule that says to do X leaves both in the file. There is no ordering. Depending on where each lands in the context and how the question is phrased, either can win — which produces intermittent behaviour, the hardest kind to debug, and the kind most likely to be blamed on the model.

Every correction added this way also makes the next one harder, because the file grows and the contradictions multiply. Files that go this way end up as a record of everything the team ever worried about, which is not the same as a description of how the project works.

Delete, do not append

The discipline is unglamorous: when a rule stops being true, remove it. Not comment it out, not annotate it, not contradict it further down. Remove it.

This feels risky because the rule was written for a reason. Two things make it safe. First, the reason is usually gone — that is why the rule became stale. Second, if it was not gone, you will find out quickly, and re-adding a line is cheap. A stale rule is more expensive than a missing one: the missing rule makes the agent ask, the stale one makes it act.

Stop the two kinds from mixing

Most staleness comes from one root cause: plan-shaped material living in a conventions file.

"We are currently migrating to Postgres" is true for six weeks. Sitting in a file that also says "run make test before committing" — true indefinitely — it is indistinguishable from a permanent fact, and six months later the agent is still writing migration code.

The test for any line: could this be wrong next month? If yes, it belongs in a plan file, which is expected to change and gets read as current state. Conventions files should contain only what would still be true after the current work finishes.

An audit that actually converges

Do not read the file top to bottom looking for problems; you will not spot them, because each line looked right when written.

Work backwards from behaviour instead. Take the last three things the agent did that were confidently wrong. For each, ask: which line did it read that was no longer true? That question finds stale rules quickly, because misbehaviour points straight at them, and it produces a short list of deletions rather than a vague sense that the file needs tidying.

Then check the obvious tell: anything containing "currently", "for now", "this sprint", "as of", or a date. Those phrases are staleness with a timestamp attached.