Objective Drift

The agent never stops working. It just quietly starts solving a slightly different problem — and every step after looks productive.

Why this, for you: the failure that bites long-running sessions hardest. There's no error, no crash, no obvious tell — the agent "completes," and the thing it completed isn't what you asked for. The defense is a single structured file that survives compaction.

You give a clear task with a constraint. Dozens of tool calls later the context is compressed. The summary keeps the goal and drops the constraint. From there the agent builds, coherently and confidently, toward a target that is subtly wrong.

1 What it looks like

Task: "Refactor UserService to use dependency injection. Do not change any public method signatures." After compaction the prose summary retains "refactor UserService for DI" but loses the signature constraint. The agent renames get_user_by_id to find_user — perfectly coherent with the refactor goal, and a direct violation of the original instruction.

After context compression, agents can keep working productively on a subtly wrong objective — the original intent lost in summarisation, with no internal signal that anything is off.

2 Why it happens

Summarisation favours high-frequency content. A constraint stated once looks like noise next to a goal that recurs across dozens of messages, so it gets discarded. A second trigger is instruction fade-out: models deprioritise initial instructions as history grows, even when those instructions are still present in context.

3 The fix

Write intent into a structured file before the agent starts, and re-read it at decision points. A named field survives compression better than prose, and the system prompt anchors it:

// session_intent.json — written first, re-read after compaction { "objective": "Refactor UserService to use dependency injection", "constraints": ["Do not change any public method signatures"], "completion_criteria": "All tests pass; no public signatures changed" } # system prompt: before each action, re-read this file and # confirm the planned step satisfies every constraint listed.

Reinforce with event-driven reminders (re-inject the objective at decision points) and bounded tasks — a loop that re-reads the original spec from disk on each restart can't accumulate drift.

When anchoring backfires

Short sessions that never reach compaction don't need a session_intent.json — it's pure overhead. Exploratory tasks suffer under strict anchoring, which blocks legitimate mid-session course corrections. And structured summaries only help if your compressor actually preserves named fields — many paraphrase them away anyway.

↪ Your win: pin the intent, survive the squash

Drift is silent — the agent looks productive while solving the wrong problem.
Two triggers: summarisation drops rare constraints; instructions fade as history grows.
Write a structured intent file — named fields survive compression better than prose.
Anchor in the system prompt and re-read before each action.
Skip it for short or exploratory tasks — anchoring blocks legitimate corrections.

Retrieval practice — recall, don't peek

Question 1Objective drift typically becomes visible when…

Question 2Summarisation drops a once-stated constraint because it…

Question 3A named session_intent field helps because it…

Question 4Strict intent anchoring backfires on…

Question 5 · spaced recall from Lesson 04The yes-man fix adds…

Ask me anything. Want the system-prompt anchor written out, or how this pairs with goal recitation in the recency tail? Next in Part 2: Token Preservation Backfire — the instruction that makes agents refuse ambitious work.