AI Context Drift: Bring an Assistant Back to the Agreed Goal

AI context drift is a practical name for a session gradually moving away from its agreed goal, constraints or evidence. Recover by stopping the current action, comparing the work with the approved task, and resuming from a short, verified account of what still applies. An apparently helpful suggestion should not silently become a new requirement.

Keeping approved decisions in fenbs gives you a record to check when the conversation becomes confused. It does not make an assistant infallible. It makes the difference between the agreed work and a new assumption easier to identify before more work follows that assumption.

How do you reset a drifting session?

1. Pause the current action. Preserve useful changes and record what is still running before restarting anything.
2. Restate the approved goal and the outcome that would count as success. Name the specific point where the latest work diverges.
3. Read the applicable rules and decisions from their current source. Separate those from suggestions made during the conversation.
4. Keep only verified progress, unresolved questions and the evidence needed for the next action in the continuation summary.
5. Ask the assistant to explain its next step and the rule that governs it. Resume when that explanation matches the approved scope.

Correct one misunderstanding at a time. If the assistant has started rewriting a whole proposal when you asked for a revised opening paragraph, return to the paragraph and its acceptance criteria. Do not bury that correction under a second request for a new outline, tone and research direction.

Which signs show that the goal has changed?

Look for a mismatch between the latest output and the task, rather than trying to infer what the model remembers. A repeated factual error may need better evidence. Drift concerns the direction of the work: the assistant is now solving a different problem or treating a rejected approach as approved.

• The deliverable changes: a short revision becomes a full rewrite.
• The audience changes: a client explanation becomes an internal technical note.
• A boundary disappears: a draft is treated as ready to publish without the required review.
• A proposal becomes a fact: an option discussed earlier is described as the chosen approach.
• Completed and unverified work merge: the assistant calls something finished because an edit exists.

Use a specific comparison: “We agreed to revise only the opening; this changes the pricing section too.” That gives the assistant something it can check. “You have lost context” describes your frustration without identifying the corrective action.

Why can drift happen before the window is full?

The available information can be ambiguous even in a short conversation. Two contradictory instructions, an outdated project note or an unstated business exception can send a session in the wrong direction. Check the actual inputs before attributing every failure to conversation length.

Long inputs introduce another possible problem. The primary study Lost in the Middle↗ (opens in a new tab) found that information position affected performance on the retrieval tasks and models it evaluated. That does not diagnose every modern assistant, but it is a reason to test whether the relevant constraint is being used rather than assume its presence is enough.

The related guide to AI context rot covers reliability problems in long sessions. Here the immediate check is narrower: what was agreed, what action is proposed, and where do they differ? More background text may obscure that comparison instead of helping it.

What should a useful correction contain?

Give the assistant the goal, the governing constraint, the verified state and the next permitted action. Add the source of any decision it previously misunderstood. This creates a concrete restart point and makes it harder for an unapproved suggestion to enter the summary as settled work.

Goal: revise the opening paragraph for a small business audience.
Approved scope: keep the offer, pricing section and terms unchanged.
Verified state: the first draft exists; no client review has happened.
Drift observed: the latest draft changes the payment terms.
Next action: restore the approved terms and revise only the opening.
Before editing: explain which paragraph you will change and why.

Keep the correction independent of the assistant’s earlier explanation. You do not need to prove why the mistake happened before fixing the scope. Anthropic recommends early course correction and specific task context in its Claude Code best practices↗ (opens in a new tab); apply those ideas by pointing to an observable mismatch and a checkable result.

When a person changes the scope, record the new decision explicitly. In fenbs, Decisions and rules keep that change available to the next connected assistant. A correction for this task does not need to become a rule for every future project.

When is a fresh session the better choice?

Start fresh when repeated corrections keep reviving the same rejected approach, or when the conversation now contains several incompatible versions of the task. Save the verified state first. Carry forward the current decision and the reason for it, without copying every failed attempt.

For the proposal example, keep the approved offer, the unchanged terms, the latest acceptable opening and the remaining review. Exclude exploratory language that you rejected. If a factual question is unresolved, label it unresolved rather than allowing a summary to choose an answer.

Use AI context optimization when the main task is removing irrelevant material from otherwise sound inputs. For drift recovery, the priority is to restore the agreed direction. A shorter session can still repeat the mistake if its starting record contains the same false assumption.

How do you check that the recovery worked?

Review the next small result against the original acceptance criteria. In the proposal example, compare the revised opening with its audience requirement, then confirm that the offer and payment terms stayed as approved. A statement that the assistant understands is less useful than an output you can inspect.

If the same misunderstanding returns, check whether the source record is ambiguous, outdated or unavailable. Record a lesson about the specific failure and the better starting instruction. The broader context engineering guide for AI assistants explains how repeatable inputs support this loop.

How to do this with fenbs

1. Create a free account. Add the project and one task with an observable definition of success.
2. Record decisions made by the responsible person in Decisions and rules. Keep proposals or unanswered questions distinct from approved choices.
3. Connect a supported AI app using Integrations. Ask it to read the project context, compare its next action with the task plan and flag conflicts.
4. After the correction, update the task with verified results and save Where we left off. Add a lesson if the mistake exposed a repeatable problem with the starting information.

fenbs is free for one person, no credit card. For a one-off question, a clear correction in the same chat may be all you need. Use a maintained project record when decisions must survive repeated sessions; the context engineering topic hub covers the surrounding practices.