The session opened with one file. The agent read it, noted a function near the top, and moved on to orchestrate other changes across the repo. Twenty turns later a teammate merged a fix to that same file through the normal PR path. The agent kept going, quoted the old implementation back in its reasoning, argued that the suggested approach duplicated code that had since been removed, and wrote a patch against the line numbers it remembered. The patch applied cleanly to its own reconstructed text and failed the moment someone compared it to the working tree.
Nothing here was malice or laziness. The agent never lost the file; it never re-read it either. The buffer captured early became the permanent definition of that file, and the disk moved on without telling the cache.
A context snapshot is a cache, not a binding
When an agent opens a file, it copies the content into the conversation. That copy saves a round trip on the next turn, which is the whole point of caching. The failure mode is that the cache has no invalidation rule: nothing tells it the file changed on disk, on another branch, or during a concurrent merge.
One read, forever trusted. The first snapshot looks current because it was current at turn one. As turns accumulate, the agent treats that stored text as the present rather than a picture taken earlier.
External edits never enter the loop. A teammate merge, a parallel agent, a rebase that resolved the file, or a check that regenerated a section all happen outside the conversation. The in-memory copy has no event to react to, so it simply stays where it was.
The agent reasons against the remembered version. When it quotes a function signature or a condition that no longer exists, it reads as a confident technical objection rather than a stale observation, because the buffer itself looks like evidence.
The patch targets reconstructed text. Editing from memory means the diff is built against a hypothetical file, not the bytes in the tree. It can look coherent and still land on a shape that changed.
What it usually looks like in the thread
It defends code that was deleted. The agent points to a block, warns against duplicating it, or explains why a behavior must stay a certain way, and that block no longer exists in the file.
Line references drift. A suggestion references a function that moved down, a condition that flipped, or a comment that was rewritten, while the surrounding context on disk disagrees.
The patch no longer matches the surrounding code. The edit inserts a call where the surrounding function signature changed, or assumes a variable that a teammate renamed.
The report says it checked the file. It describes the current implementation accurately according to its memory, which makes the stale claim hard to catch from the summary alone.
It repeats the same objection across multiple turns. Once the wrong snapshot is fixed in context, the agent restates the same argument each time the topic comes up, even though the premise was removed earlier in the session.
The gate: invalidate the snapshot and re-read before the edit
Treat the buffer as a cache with a short life. A file read from twenty turns ago is not a live copy. The default should be to re-open the file immediately before changing it, especially after any merge, rebase, branch switch, or teammate commit.
Invalidate on any external change. A merge, a conflict resolution, a generated file overwrite, or a parallel edit should drop the cached snapshot, not update it blindly. The next turn that needs the file reads it fresh.
Edit against bytes on disk, not against the conversation. Build the diff from a current read. A coherent patch built on a remembered buffer is still a patch aimed at a file that changed.
Quote the current text before arguing with it. Before the agent objects to a condition or duplicates a block, it should pull the live section and compare. An objection against deleted code reads well in the thread and contributes nothing.
Surface the read timestamp. When the summary claims a section still behaves one way, note which turn that read happened on and whether the file changed since. A twenty-turn-old read deserves a refresh before it carries weight.
The same drift when a contract changes underneath
This pattern generalizes past source files. An agent that read an OpenAPI spec early and keeps the old section in memory will argue against a field that was renamed, generate a request against the old path, and call the result correct, because the memory says the spec still looks that way. The reliable habit is to let the current artifact on disk or in the spec outrank the conversation's copy of it, and to re-pull before relying on any detail. That source-of-truth refresh is the loop we keep in Powerduck: the live spec and the recorded request outrank the buffer, and a remembered version never counts as proof.
Before you accept the patch
- When was this file last read in the session, and has anything merged or rebased since?
- Does the agent quote a block or condition that still exists on disk, or only in its memory?
- Was the diff built from a fresh read, or from a buffer captured earlier?
- Does the objection reference behavior that a teammate already removed or renamed?
Caching a file for speed is reasonable. Trusting that cache as the current state, across a long session with real changes happening elsewhere, is how an agent ends up arguing against a file it has not seen in twenty turns. Re-read, compare, then edit.
