Instructions do not get forgotten, they get diluted. What context drift is, and how to structure a session so a rule set at the top still holds.
Published
You start a session. The first three answers are good. By the tenth message the model has gone
back to writing the way it writes by default — longer, blander, with the em dashes and the
tricolons you explicitly told it to drop eight messages ago.
The usual conclusion is that the model got worse, or got tired, or that the good run at the
start was luck. None of those is what happened.
The failure looks like the model getting worse
It is worth being precise about the symptom, because the diagnosis depends on it.
What you see is not random degradation. It is a specific, repeatable drift back toward the
default: the constraints you set early stop being applied, one at a time, roughly in the order
you set them. The tone rule goes first. The length limit goes next. The format usually survives
longest, because you keep restating it without noticing.
That pattern is the tell. Random quality variation would not walk in one direction, and it
would not walk in the same direction every time.
What is actually happening: dilution, not forgetting
The model has not forgotten your instruction. In almost every case the instruction is still
right there in the context window, and if you ask directly — what tone did I ask for? — it
will tell you correctly.
The problem is weighting. An instruction given in an ordinary user message is one piece of
context among many, and as the conversation accumulates, that one message becomes a smaller and
smaller share of what the model is attending to. It competes with everything that came after
it, including several turns of output written in the style you were trying to suppress.
Prompt Engineering Masterclass puts it plainly: a
rule stated once early in a long conversation gets diluted as more content piles up, and
weighting is not guaranteed the same way it is for a system-level instruction.
That distinction — between what the model can see and what the model is weighting — is the
whole of it. Everything below follows from it.
Pair one: the restated preamble
The instinctive fix is to repeat yourself. It is also the most common way people make the
problem worse, because a wall of restated rules at the top of every message is itself more
context competing for the same attention.
Bad · the restated preamblePrompt Engineering Masterclass, Ch. 8
Retyping your entire style guide at the top of every single message in a long
conversation, then being surprised when a later message forgets a rule from
three messages ago.
The fix is not repetition, it is placement. Standing rules belong in a layer the model treats
as standing: Custom Instructions, a Project, or a Gem, depending on which tool you are in. The
per-task brief then stays short and says only what is true for this piece.
Good · rules in the system layer, brief in the turnPrompt Engineering Masterclass, Ch. 8
[System / Project instructions]: You are my content editor. Always: flag
unverified stats, keep sentences under 25 words, avoid corporate jargon, use
markdown headers.
[User turn, this task only]: Edit this specific draft for a technical audience
of DevOps engineers — technical jargon is fine here, override the 'avoid
jargon' default for this one.
Note the second half. The system layer sets the default and the user turn overrides it
explicitly for one task. Neither layer is doing the other’s job, and the override is stated as
an override rather than as a contradiction the model has to resolve on its own.
The rule of thumb worth stealing: if the same preamble appears in more than three prompts a
week, it belongs in a system layer. It is a five-minute setup that pays for itself the same day.
Free · no card
Twenty prompts that survive a long conversation
The free guide is fifteen pages, and every prompt in it is printed in full.
Pair two: the correction that gives nothing to correct
The second failure is not about drift at all. It is what people do once they notice drift.
Bad · a reaction, not a diagnosis
This isn't quite right, try again.
That gives the model nothing to aim at. It will regenerate something in the same general
direction with random variation, which is why the second attempt so often feels like a
sideways move rather than an improvement.
Good · a diagnosis
The tone is right but it's too long, and the third paragraph repeats the
second — cut both issues.
Treat feedback the way you would with a colleague: specific, not vibes-based. Name what is
working as well as what is not, because otherwise the correction throws away the part that was
already fine.
Pair three: the compounding-error trap
The third one is the expensive one, and it is a direct consequence of the first two.
When an output is wrong and you correct it in place, the wrong output stays in the context. If
you do that four or five times, the conversation now contains five versions of a thing that
missed, and one instruction saying so. The model is being shown, repeatedly, the shape of the
answer you rejected.
Bad · correcting on top of a bad draft, repeatedly
Not quite. Try again.
Still not right, make it shorter.
Closer, but the tone is off.
Almost — can you make paragraph two less formal?
Good · re-anchor and restate once
Stop. Here is the brief again, and it supersedes everything above:
[brief]
Ignore the four drafts in this conversation — none of them is a useful
starting point. Write it fresh against the brief. If anything in the brief
is ambiguous, ask before writing.
The counter-intuitive part is knowing when not to do this. Opening a fresh chat at the first
imperfect output is the opposite mistake — it throws away context the model already has, and
rebuilding it costs more than a targeted correction. Correct in place until the conversation
has genuinely gone off the rails, then re-anchor rather than restart.
How to tell dilution from a task that is simply hard
Not every disappointing output is drift, and treating a hard problem as a filing problem wastes
an afternoon. Two checks separate them, and both take under a minute.
The cold-start test. Open a new conversation. Paste the same request with the standing rules
stated once, cleanly, and nothing else. If the output is good, the problem was dilution and the
fix is in this post. If it is the same kind of bad, the problem is the request — usually that it
is under-specified, or that it requires something the model does not have.
The direct question. In the drifting conversation, ask what constraints are currently in
force. A model that lists them correctly and then ignores them is a weighting problem. A model
that lists them wrongly, or lists constraints you never set, means the context has genuinely
become confused and re-anchoring will not be enough — start clean.
There is a third case worth naming because it looks exactly like drift and is not. If you have
been narrowing your requests over a long session — each one a small correction on the last —
the model is now optimising for a target you have moved twenty times, and the output is a
compromise between all of them. That is not decay. That is you having failed to state the final
version of what you want, and the fix is to write it out in full, once, as though for a
colleague who has just walked in.
Where a standing rule actually belongs
Three layers, and putting a rule in the wrong one is most of the problem:
System / Project / Custom Instructions. Things true for every task: voice, formatting
defaults, what to always flag, what to never do. Set once, checked occasionally.
The project’s reference material. Facts the model should treat as ground truth — your
brand brief, your pricing, your product names. Attached, not pasted.
The user turn. What is true for this task only: audience, length, the specific input, and
any deliberate override of a default.
There is a maintenance job here that nobody does. A system layer you set up four months ago and
have not checked is a system layer you are trusting blind — tools update, settings occasionally
reset. Send a test prompt with no restated context every so often and check the standing rules
are still being applied. It takes a minute.
What to put in the system layer, concretely
“Move your standing rules into the system layer” is easy to agree with and hard to act on,
because most people do not have their rules written down anywhere. Here is what actually belongs
there, in the order worth adding it.
Things you correct more than once a week. Go through your last ten sessions and look for the
correction you keep typing. Shorter.Drop the bullet points.British spelling. Each one of
those is a rule you have been paying for repeatedly.
Your non-negotiables. Not preferences — the things that make an output unusable. Never
invent a statistic. Never write in the first person. Always flag where a claim needs checking.
State these as absolutes, because a hedged rule gets treated as a preference.
What the model should do when it does not know. This is the most valuable line in most
system layers and almost nobody includes it. If information I have not given you is needed to
answer well, ask for it before writing rather than assuming. Without that instruction the
default behaviour is to fill the gap plausibly, and a plausible invented detail is much more
expensive to catch than a question.
What does not belong there: anything task-specific, anything longer than a page, and any rule
you have not actually tested. A bloated system layer has the same dilution problem as a bloated
conversation, one level up.
The five-minute setup
If you take one thing from this: open whichever tool you use most, find its standing-instruction
feature, and move your three most-repeated rules into it. Then delete them from your prompts.
Your prompts get shorter, which by itself reduces the dilution. The rules stop competing with
your actual request. And the drift you were blaming on the model turns out to have been a
filing problem.
If you want the reasoning underneath this rather than the fix —
why constraints change an output, where an instruction belongs, how to build a prompt library
that stays navigable — that is the
Prompt Engineering Masterclass, twenty chapters and
150 templates. If you would rather skip the theory and start from prompts that already have
their constraints written in,
200 AI Prompt Templates is two hundred of them, numbered so
you can find one again.
And if you are still deciding which tool to set all this up in,
the comparison by task type is the other half of this
question.
Fifteen pages, twenty prompts, no card. Then about one email a week on getting usable work out of these tools.
Cookies
We use analytics and advertising cookies to understand which pages sell and which do not. Nothing loads until you choose. Reject keeps the site working exactly as it is.Cookie policy
