Five places a rule dies inside an AI agent's run
Writing rules for an AI agent is the easy part. These are the five points where they stop being followed, and the check that catches each one.
4 min read Provecta Group
Anyone who has used an AI coding agent seriously has met the instructions file. You write your rules into it, the agent reads it at the start, and for a while the agent behaves. Then it doesn't. The issue tracker for Anthropic's Claude Code has a long run of reports on this through 2025 and 2026. One is titled, with some feeling, "CLAUDE.md may as well be useless". Others describe rules followed early in a session and dropped later, especially after the tool compresses a long conversation to save space.
None of this is specific to one product. It is what happens to any rule handed to an agent once, at the start, and then left to survive a long run. We have watched rules fail in our own agent work at Provecta Group, and they tend to die in the same five places.
1. The rule never loaded
The simplest failure. The agent started in a folder where the rules file was not picked up, or a scheduled job ran with a different setup than the one you tested, or a new tool was added that reads its own settings and ignores yours.
The check: every run should start by loading the rules from one fixed place, and the run's log should show that it did. If you cannot see in the log that the rules were read, assume they were not.
2. The rule faded
The rule loaded, but forty steps later it is a small part of a very long context. Research on multi-turn conversations, including a 2025 paper from Microsoft and Salesforce, found models lose a large share of their reliability as work is spread over many turns. Compression of long sessions can drop rules outright.
The check: break long jobs into steps, and have each step read the rules again from the written memory rather than relying on what is left of the conversation. Anthropic's own guidance on context engineering recommends keeping structured notes outside the context window for this reason.
3. The rule lost to the task
The agent read the rule, remembered it, and broke it anyway, because the task pulled harder. Asked to "get this deployed" with a rule against touching production, it touched production.
The check: a written rule cannot stop this. Anything that sends, spends, deploys or deletes needs a gate outside the agent: a permission it does not have, or an approval a person has to give.
4. The step behind the rule failed quietly
This one is less obvious and, in our experience, more common. The agent follows the rule, but a step underneath it fails, and the failure looks like success.
A typical case: an AI provider changes what its service accepts, every request from your workflow is quietly rejected, and the code falls back to a stock template that reads fine. The rules were followed. The output looks plausible. It is not what anyone asked for. We have been caught by exactly this kind of silent fallback in our own systems this year.
The check: watch the output, not only the errors. A daily look at a sample of what the agent produced, or an automatic flag on output that matches a known fallback, catches what an error log never will. When it happens, write the cause and the fix into the memory so every later run knows the trap exists.
5. The rule was wrong
The agent followed the rule perfectly and the result was still bad, because the rule was out of date, too broad, or contradicted another rule. Agents do not argue with rules. They apply them.
The check: every rule carries its reason and a date. When a rule produces a bad outcome, the reason tells you whether the rule was wrong or was misapplied, and the date tells you how old the thinking is. Rules that contradict each other should say which one wins. Ours do.
What a written memory covers, and what it does not
Of the five, a shared written memory directly helps with the first, second and fifth: rules load from one place, get re-read at each step, and carry reasons and dates that make bad rules visible. It helps indirectly with the fourth, because the lesson from a silent failure gets written down once and reaches every later run.
It does nothing for the third. An agent that decides to break a rule will break it whether the rule is in a file, a prompt or a memory. That is what gates and permissions are for. Anyone who tells you memory alone makes agents follow rules is selling something we would not buy.
Try this
Take one agent or AI workflow you rely on. For each of the five places, write one line on what currently catches a failure there. Blank lines are your priorities.
The operating system health check covers the same ground for your wider operations. Book 20 minutes at pgco.world/book to walk through your answers.