The agent drifts from your requirement while the context fills up

You request the agent to add a validation that stops malformed ids before they reach the handler. The agent locates the schema file, performs some searches, makes adjustments to two nearby code sections, and concludes with a passing test. However, the important validation you asked for is absent; instead, the agent has focused on refining the last part it worked on and marked the task as finished. The initial requirement has not vanished, but it has been overshadowed by the work it has done.

The agent does not retain a clear memory of your request. It records a running transcript, including fetched files, terminal output, rejected edits, and summaries of those edits. As this transcript expands, the original brief becomes less relevant to the model's future decisions, and each subsequent action relies more heavily on recent information than on the initial instructions. No one instructs the agent to pause and verify acceptance, so the last successful action becomes the main focus.

This isn't a model that has forgotten the original task; it's the context that has shifted. The brief was never repeated, acceptance criteria were not marked, and the intermediate output was never trimmed. The drift can look like competence because the diff compiles and the existing tests still pass. Be cautious of patterns such as "optimize-the-last-output," where the agent keeps polishing a recently edited function rather than returning to the original target.

Also watch for "summary-takes-over," where a recap block written during the task becomes the source of truth and presents a slightly modified version of your initial request. "Scope-creep-by-convenience" happens when the agent fixes an adjacent issue while editing, pushing your main request to the end. "Stale-tool-log" is when an early failed search or rejected draft remains in the transcript and the agent treats it as a current constraint.

Lastly, "lost-initial-criteria" occurs when you describe acceptance in prose at the beginning, but by the end, there's no way to compare the diff against your original requirements.

To prevent this drift, provide a concise acceptance block at the start of the task. Keep it separate from implementation notes and state what must change, what must remain unchanged, and the one check that proves it. For this task, the acceptance criteria are:

- Reject a malformed id at the route boundary, before the handler runs.

- Do not alter existing valid-id behavior.

- Confirm this with one negative-case test that returns the expected error.

Everything after this block is considered working material, not new requirements. When the agent finishes, ask it to restate the acceptance block and show the exact diff hunk that fulfills each bullet. If a bullet has no corresponding hunk, that means it's still an open item, not something to overlook. Reviewing and shortening the transcript throughout the task also helps, by eliminating early failed searches and superseded drafts.

A shorter, current context behaves like a focused engineer, while a long, confusing one behaves like someone reading from the middle of their notes.

At the end of each session, write a brief handoff note that includes what has been done, what is still pending, the acceptance block, and the relevant files' locations. This ensures the agent starts the next session from the anchor instead of reconstructing the intent from scratch. Keeping a local copy of the contract or spec file, which the agent can refer to in every session, helps maintain the focus.

Remember, drift is invisible until it's corrected. It's not about having a wider window; it's about having a fixed point to return to, periodic reassessments, and a current transcript instead of one that just accumulates.