What you’ll be able to do
- Recognize when instruction drift, not a bad model response, is the actual cause of a failure
- Decide which constraints need periodic re-injection and which don’t
- Design and test prompts against realistic session length
What you need to know
Salience fades with distance, not with importance
An instruction given once at turn 1 has to compete for attention with everything that happens between then and turn 40. It doesn't disappear from history, but its practical influence on the model's next output can fade — especially for subtle constraints buried in a long system prompt rather than stated as an obvious rule.
This is not a flaw to "fix" once; it's a property of long sessions that architecture has to account for, the same way statelessness is a property of the API that architecture has to account for.
Not every constraint needs restating — some structurally survive
Constraints split into two categories that need different handling:
- Identity-level constraints — "never reveal internal system details," "always respond in the user's language." These belong in the system prompt, are structurally present on every turn, and rarely need active re-injection.
- Task-level constraints — "for this specific request, only use data from the attached document," "in this phase of the workflow, don't call the refund tool yet." These are tied to a moment in the task and are exactly the ones that can quietly lose salience as the session moves on.
Re-injecting every constraint on every turn is wasteful and also has a cost beyond tokens: a model conditioned to see the same boilerplate every turn tends to skim it, which undermines the constraints that genuinely are new or urgent. Re-inject task-level constraints at natural checkpoints instead — when a new phase of a workflow begins, or right after a compaction event.
Compaction is a common, quiet place to lose a constraint
Automatic context compaction and manual history pruning summarize or drop older turns to keep a session within budget. A task-level constraint given informally mid-conversation — not in the system prompt — is exactly the kind of detail a summarization pass can compress away without anyone noticing until the agent violates it several turns later.
Architecturally: anything that must survive compaction belongs in the system prompt, or needs to be explicitly re-asserted immediately after a compaction event, not assumed to have carried through.
Test at the length you’ll actually run at
A prompt validated only against a five-turn happy-path conversation tells you almost nothing about turn 40 behavior. Reliability testing for a long-running agent needs to include realistic-length sessions, deliberately including a compaction event if the deployment will hit one, before the architecture ships.
Key concept
Instructions don’t expire, but their influence on the model’s next output fades with distance from the current turn — architect for which constraints must structurally survive and which need active re-injection at the right checkpoints.
When a scenario describes an agent that "used to follow a rule but stopped after a while," the cause is almost always instruction drift or a compaction event, not the model becoming unreliable.
Practice scenario
Work it through, then open this
This is a task-level constraint that was stated once, informally, mid-conversation rather than placed somewhere structurally durable. It has lost salience over 25 turns of unrelated exchange, and it may also have been compressed away by an intervening compaction event. The fix is to re-assert it at natural checkpoints — after compaction, or at the start of each new troubleshooting phase — rather than relying on a single early mention to hold for the whole session.
Build exercise — Audit a long session for instruction drift
Intermediate · 25 min
What you’ll learn
- Classifying constraints as identity-level or task-level
- Spotting where compaction could silently drop a constraint
- Designing a re-injection checkpoint strategy
-
List every constraint given to an agent across a real long session and classify each as identity-level or task-level.
- Why: Only task-level constraints are realistic candidates for drift; identity-level ones should already be structurally stable in the system prompt.
- You should see: A shorter list of task-level constraints than the total, each one a candidate for re-injection design.
-
Identify where in the session a compaction or history-pruning event occurs, and check whether any task-level constraint was given before it.
- Why: That’s the exact place a constraint can be silently summarized away.
- You should see: Either no exposure, or a specific constraint that needs re-asserting right after that point.
-
Design re-injection checkpoints for the task-level constraints you found — not every turn, but at phase changes or after compaction.
- Why: This holds reliability at long session length without the cost and skim-inducing effect of restating everything every turn.
- You should see: A small number of deliberate checkpoints, not a blanket re-statement policy.
Exam traps
Assuming a constraint stated once at turn 1 stays in effect at turn 40
Salience fades with distance from the current turn, even though the instruction is still technically in history.
Re-stating every constraint every turn, bloating cost for no reliability gain
Wasteful, and it can train the model to skim boilerplate — which undermines the constraints that are genuinely new.
Not noticing when compaction or history pruning silently dropped an earlier constraint
A summarization pass can compress away an informally-stated task-level constraint with no error or warning.
Treating a long session as just “more of the same turn” rather than its own reliability regime
Long-session reliability needs its own testing and architecture, the same way statelessness needs its own handling.
Failing to distinguish stable identity constraints from constraints that change as the task shifts
Identity-level constraints belong in the system prompt and rarely need re-injection; task-level ones often do.
Only testing prompts against a short happy-path conversation before shipping
A five-turn test tells you nothing about behavior at turn 40 or after a compaction event.