You wrote the rules down. The agent followed them yesterday. Today it skips a check, repeats a decision you already settled, or reaches for an approach you ruled out three sessions ago.
When you build with AI, that is frustrating in a particular way. You already did the work of explaining. Now you are spending time checking whether the explanation stuck.
My instinct is to add another line to the instructions. Sometimes that is the right fix. But an instructions file is being asked to do several jobs: guide the work, preserve its history, and stop mistakes. Those jobs need different kinds of support.
A loaded rule is still a rule the agent has to follow
Coding tools have different ways of loading project instructions, skills and saved context. The details change with the tool and version. Before diagnosing a missed rule, check whether the relevant file was loaded, whether it applies to the current task, and whether another instruction contradicts it.
Then there is the work around it. A long session can contain old plans, revised plans, code, logs and instructions that no longer apply. Keeping that context focused makes the job clearer. There is no universal token count at which instructions stop working, and elapsed time alone does not tell you why a particular rule was missed.
The practical distinction is simpler: having an instruction available does not make compliance automatic. If your rule says to run the tests, you still need evidence that the tests ran and passed.
Saved instructions and session history are different things
Some tools summarize a long conversation to make room for more work. Some reload instruction files, retrieve saved notes, or combine those approaches. A summary can leave out a decision or the reason behind it. That does not mean every project rule has been replaced by a paraphrase.
For a concrete example, Claude Code currently documents that it reloads the project-root CLAUDE.md after compaction. That is useful behavior, but it does not preserve every detail of the conversation. Check your own tool's current behavior rather than assuming all agents handle memory the same way.
A rule such as “run tests before merging” belongs in your working instructions. Why you rejected a particular design belongs in a durable project record. A test result belongs in the evidence for the change. Keeping those separate makes it easier to see what is missing.
Four changes I would start with
1. Keep the everyday instructions focused. Put the conventions and constraints that apply across the project where the agent will load them. Make them specific enough to check. Remove duplicates, resolve contradictions, and move historical discussion into project notes. Do not remove an important rule just because it has not been broken recently. It may be doing its job.
2. Load detailed procedures when they are needed. Where your tool supports skills or scoped instructions, use them for work such as deployments, database changes or design reviews. Keep the trigger clear and verify that the procedure actually loads. Moving a document out of the default context only helps if the agent can find it when the task calls for it.
3. Save decisions, and bring the relevant ones back. Write down what was decided, why, and what would justify revisiting it. Keep that record somewhere durable and accessible to the next session. Before a consequential step, bring the current constraints into the work: which branch to deploy, which behavior must stay, which checks must pass. Retrieval needs to be specific enough to avoid replacing one crowded context with another.
4. Turn critical requirements into checks. A linter can catch formatting problems. A test can protect behavior you have already approved. A permission boundary can limit what a tool is allowed to do. Keep the instruction that explains the requirement, and add a mechanism that detects or blocks the violation.
Pay attention to where that mechanism runs and who can bypass it. A local check may be skippable. A failing CI job only blocks a merge when the repository requires it. On a protected branch, require the checks that matter and review bypass permissions. If the agent can edit the check itself, that change needs review too.
Start with the two or three failures that would actually hurt. There is work involved in maintaining good checks, and some decisions still need human judgment. The point is to make routine compliance visible so your review can spend more time on whether the change is good.
Where external memory helps
This is part of why I am building NASC. I want the project's decisions and history to remain available when a session ends, a conversation is shortened, or the work moves to another agent.
Storing that record outside the conversation gives you something durable to return to. It still has to be accurate, current, retrieved at the right time, and used correctly. External memory does not make an agent obey a rule, and it does not replace tests or permissions.
You can start with a decision log in your repository. Keep the everyday instructions clear, save the reasoning you will need again, and require evidence for the things you cannot afford to miss. That is useful regardless of which coding agent you use next month.
Revision and sources
Updated September 10, 2026. The original version focused on CLAUDE.md and overstated both a 100k-token threshold and the loss of instruction files during compaction. This revision separates instruction loading, session history and enforcement, and broadens the advice across coding agents. The original link is retained.
Tool-specific details checked against Claude Code's memory documentation and GitHub's protected-branch documentation. Check current documentation for the tools and versions you use.