Module 1 introduced context drift as a concept — you now know why it happens. This lesson is about the practical skill of catching it in real time, inside a live conversation, and correcting it without starting over. Instruction drift is the specific, recognizable form of drift where a rule you explicitly set — a tone, a format, a constraint — quietly stops being followed. Learning to spot it in one or two messages instead of ten is what separates someone who fights their tools all day from someone who runs them smoothly.
What Instruction Drift Actually Looks Like
Drift rarely announces itself. It shows up as small slippages that are each individually easy to excuse:
- You said "always answer in under 100 words." Message 30 is 220 words.
- You said "never use the word 'delve.'" It shows up again, quietly, in message 18.
- You set a persona ("respond as a blunt, no-nonsense editor"). By message 25, the responses are polite and hedging again.
- You specified a table format. The model reverts to paragraphs "because it read better this way," unasked.
None of these are the model malfunctioning. They're the practical result of your original instruction losing weight relative to everything said since — exactly the mechanism Lesson 1.2 explained, now showing up as a specific, fixable symptom.
The Three-Step Fix
You do not need to restart the thread. Drift correction is a three-step in-conversation move:
- Name the drift explicitly. Don't just repeat the rule — point out that it slipped. This helps the model treat the correction as a priority reset, not just one more instruction in the pile.
- Restate the original rule exactly, word for word if possible, rather than paraphrasing it loosely.
- Ask for a fresh output under the restated rule, so you immediately confirm the fix worked before moving on.
Drift correction message:
You've drifted from the format rule. Original instruction was:
"Always respond in under 100 words, no exceptions."
Your last two responses were both over 200 words.
Please redo your last response, strictly under 100 words this time,
and confirm you'll hold this for the rest of the thread.
This works far better than a vague "shorter please" — vague corrections tend to produce one compliant response before the model drifts right back, because you haven't re-anchored the actual rule, just nudged the symptom.
Building a Personal Drift Checklist
The fastest way to catch drift is knowing your own most common rules well enough to notice violations quickly. Before a long working session, jot down the 3-5 rules that matter most for this task — the ones you'd be annoyed to see broken. Glance back at that list every 15-20 messages.
| Your rule | Quick check every ~15 messages |
|---|---|
| Word/character limit | Does the last response respect it? |
| Banned words/phrases | Scan for them |
| Format (table, bullets, JSON) | Did it revert to paragraphs? |
| Persona/tone | Does it still sound like the character you set? |
| Language mix (English/Roman-Urdu ratio, etc.) | Did the ratio shift? |
Preventing Drift Before It Starts
Correction is a skill you'll always need, but you can reduce how often you need it:
- State rules as absolutes, not preferences. "Always" and "never" hold up longer than "try to" or "ideally."
- Repeat critical constraints every several exchanges, proactively, rather than waiting for a violation. A single sentence — "reminder: still under 100 words, no persona changes" — costs you nothing and resets the weighting.
- Use system-level instructions where available (a Claude Project's custom instructions, a Custom GPT's configuration — covered in Module 3) instead of relying purely on conversational memory. Instructions set at the system level tend to hold up longer than ones buried in message history.
🇵🇰 Pakistan Angle
Drift correction is a direct client-trust issue for anyone delivering ongoing work — a WhatsApp Business auto-reply script, a weekly Urdu/English bilingual newsletter, a long client-editing thread. A client who set a tone requirement ("keep it formal, no slang") on day one and gets a slangy draft on day twelve doesn't think "the AI drifted" — they think you weren't paying attention, and on Upwork that shows up as a lukewarm review, not a private complaint. The professional habit costs thirty seconds: before sending any client deliverable pulled from a long thread, re-scan your own rules checklist first, catch drift yourself, and correct it before the client ever sees it. That thirty-second discipline is worth more to your repeat-client rate than almost any prompting trick in this course.
Do This Now — Module 2 Integration Exercise
This exercise pulls together everything from Module 2. Using one real, ongoing task (a report, a content series, a client project):
- Architect it (Lesson 2.1): open a fresh thread, name it properly, and write a one-line scope statement plus 3-5 standing facts.
- Set two explicit rules you'll hold for the whole session — one format rule (e.g., "always answer in a numbered list") and one content rule (e.g., "never mention pricing").
- Work the thread for at least 15-20 real exchanges on the actual task.
- Deliberately check for drift: scan the last five responses against your two rules. If you find drift, run the three-step fix and confirm the correction held.
- Run summarize-and-carry (Lesson 2.2): generate the four-part handoff summary, correct anything wrong in it, and save it as a reusable brief.
You should end this exercise with: a properly scoped thread, at least one documented drift-catch-and-fix (even a minor one), and a saved carry-forward summary ready for next time.
Common Mistakes
- Correcting the symptom ("make it shorter") instead of naming and restating the actual original rule.
- Waiting for drift to become severe before addressing it, instead of doing periodic 15-message checks.
- Forgetting that stated rules decay over time even when nothing "went wrong" yet — proactive restatement beats reactive correction.
- Treating a single successful correction as permanent instead of expecting to reinforce it again later in a long thread.
Key takeaway: Instruction drift is specific and fixable: name it, restate the exact original rule, and confirm the fix with fresh output — no need to restart the thread. Combined with deliberate thread architecture and regular summarize-and-carry, you now have a complete system for keeping any long-running AI conversation reliable from day one to day sixty.