Context buys continuity, and it also lets an early misunderstanding keep shaping later output

What it is

In turn two the user says “don’t talk price yet.” In turn twelve they ask for a quote; the system still writes prices as “discuss as needed,” because that ban is still a live constraint in the context. Continuity means the dialogue does not have to restate background every sentence. The same pipe lets an early misunderstanding or expired instruction stick. What sticks is not memory as such. It is a span that has expired and was never declared dead.

Continuity is the gain. This entry is the other face of that gain: once a wrong common ground is written into context, every later turn builds on it.

Why it happens

Autoregressive conditioning treats the dialogue so far as true. There is no separate layer for “is this still in force.” People use conversational convention: a later line can cancel an earlier one (“we can talk price now”). The model treats both as simultaneously true constraints, or worse, lets the earlier, more explicit ban outweigh the later, more implicit request. A misunderstanding (hearing “we” as a family of three) is likewise filled in as fact in later turns.

People rarely notice the stick, because the current reply is locally fluent. An expired constraint shows up as style or policy, not as an error. Users then fight their own throwaway line from several turns ago with stronger wording, spending effort against a ghost constraint.

Studying it

Plant a constraint that will expire (a temporary price ban, a wrong headcount, a wrong role). Several turns later, give a new goal that conflicts with it. Offer no clear action. Dependent variables: whether the expired constraint still dominates after the conflict, turns until the user notices the stick, whether failure is attributed to “I did not say it clearly.” Independent variables: how blunt the conflicting instruction is, turn-distance of the expired constraint, whether unrelated small talk is inserted.

Small talk matters. Real sessions go off-topic; going off-topic is not a revoke, but people misread it as “the topic changed, so the old constraint should die.” If stick rate is unchanged after small talk, the system has no topic boundary and the person does.

Where it stops holding

In a short session where the constraint stays valid, stickiness is correct memory, not a fault. A long-term preference the user explicitly marked “from now on” is not covered by expiry. State from a tool call (an order placed, a row written) is not dialogue context; reversing it is a transaction rollback, not forgetting a sentence. When several people share one context, stickiness becomes crosstalk — an isolation problem whose mechanism is still a pipe with no expiry mark.

Applying it

• Make still-live constraints visible, dismissable objects (“still honouring: no prices”), not only buried in a hidden prompt.
• Detect a new request that conflicts with a live constraint, and ask which one dies. Do not silently let the old ban win.
• Allow a single constraint to expire without throwing the whole dialogue away.
• Check: write a temporary ban, then six turns later give a task that can only be finished by violating it. If the output still honours the ban and the UI shows no “still in force” cue, log a stick incident. After adding “expire this,” the same task should finish in one turn, with the rest of the background intact.

Related

• Same group: L2.14.2 People usually cannot tell what the system actually remembered; the context needs an inspectable view · L2.14.3 Clearing needs an explicit act; opening a new session is only an implicit convention · L2.14.4 Memory across sessions hardens a one-shot preference into a standing setting · L2.14.5 When overlong context is truncated, what the user sees is unexplained capability loss
• Nearby: L2.15 Ambiguity and Clarifying Follow-ups · L2.12 Iterative Edits and Local Regeneration · L2.07 Prompt History and Reuse
• Search terms: sticky misunderstood context · context contamination · expired constraint