Answers
Why does the AI drop a rule we agreed on five messages ago?
Because the rule only ever existed inside the conversation. Anything agreed mid-session sits in the same window as everything said since — the code that was pasted, the errors that came back, the tangent about something else — and the model's own defaults are what it falls back to as that competition gets crowded. A rule that has to survive being told once is not stored anywhere; it is being remembered by a process nobody asked to remember it. Here a rule is written down once, outside any conversation, and every assistant reads the current set before it starts. It does not depend on the session recalling it, which is also why it survives the next session, the other tool, and the teammate who was not there.
Last updated September 15, 2026
The window is a working surface, not storage
What you agreed five messages ago is not stored anywhere once the conversation ends, and it is not privileged while the conversation runs. It sits in the same stream as the file you pasted and the error you were chasing, and as that stream fills, an instruction given once carries less and less weight against patterns the model applies by default. This is why the slip so often lands right after a long or technical stretch — not because the assistant disagreed, but because the one sentence that said otherwise is now far away and surrounded.
Told once, or written down
The fix is not to repeat yourself better. A rule read at the start of every session, from a place that is not the session, does not decay as the conversation grows, because it is not competing with the conversation. It also stops being a fact about you: the formatting rule you settled on is the same one your colleague's assistant reads, and the same one your scheduled job reads at three in the morning. Told once is a property of one conversation. Written down is a property of the work.
Which is why it has to say who agreed
Once a rule outlives the conversation, the next question is whose rule it is. A preference you set for yourself and a standard the team settled on look identical written down, and only one of them should govern someone else's work. So each entry records who approved it, and an assistant can propose one but cannot enact it — a proposal stays a proposal until a person approves. That is what keeps a rule which escaped one conversation from quietly becoming everyone's.
What it looks like in practice
You start a session and ask for short commit messages: one line, imperative, no body. The first few are exactly that. Then you spend twenty minutes on a failing test, paste two stack traces and a config file, and go back to committing. The next message comes back with a three-paragraph body explaining the change. You did not change your mind and the assistant did not decide otherwise — the sentence that set the rule is now twenty messages back, behind two stack traces, and the default shape of a commit message is the strongest pattern left in view. You restate it. It holds for a while. Tomorrow you open a new session and restate it again, and so does everyone else on the team who wants the same thing, each inside their own conversation, none of them aware the others are doing it.
Questions people ask about this
- Isn't that what a system prompt or custom instructions are for?
- They are the same idea and they do help, with two limits worth knowing. They belong to one tool, so the rule stops at its edge: the other assistant, the scheduled job and the teammate's setup never see it. And they carry no notion of who agreed or when it stops applying, so a personal preference and a team standard sit in the same block, and the rule you set for one project follows you into the next.
- Some rules really are just for this conversation. Does everything have to be written down?
- No, and most of it should not be. The test is whether you would want it to hold tomorrow, in a different tool, for someone who was not in the conversation. “Use tabs in this file” is a conversation. “We write commit subjects in the imperative” is a rule. Writing down the first kind is how a store fills with things nobody meant to keep.
- What happens when a rule stops applying?
- Each one is written with the condition that ends it, so it retires when that condition is met instead of staying in force because removing it was nobody's task. A rule that turns out to be wrong is replaced by one that names it, so an assistant reads the current version and not both.
Where this is verifiable
Product documentation on this site (How it works, Install), the answer on one rule duplicated across four prompts for the team-scale version of this problem, and the sanction, provenance and expiry rules in the sanctioned product spec. Everything described here is behaviour the tools apply today, not roadmap.
https://www.arroway.app/en/answers/rules-that-slip-five-messages-later