A long-running code generation agent starts a session by deciding to use PostgreSQL as the database layer. After processing 80,000 tokens of code context, the agent begins generating SQLite queries in new modules, contradicting its earlier decision. No errors occur. What is causing this behavior?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Long LLM context windows are like short-term memory — detailed at the beginning, but decisions made 80,000 tokens ago start fading as newer content pushes them out of the effective attention window. The fix is to promote critical architectural decisions into a persistent structured memory (a 'decisions log') that is injected at the start of every reasoning step.
Full explanation below image
Full Explanation
Context drift occurs in long-running agent sessions when early decisions or constraints are effectively lost because the context window is filled with newer content and the attention mechanism gives decreasing weight to distant earlier tokens. LLMs do not have perfect recall of all tokens in a very long context; information at the start of a long context is less reliably attended to than information near the current position.
The architectural solution is to promote critical decisions — such as technology choices, architectural constraints, and scope boundaries — into a persistent 'decisions log' that is maintained outside the agent's main context and re-injected into the context at the beginning of each reasoning step or periodically throughout a long session. This ensures foundational decisions remain in the high-attention portion of the context window regardless of how much other content has been processed.
Option A (memory store cleared mid-session) would produce a distinct symptom: the agent would lose all session context, not just the database choice. The scenario describes selective forgetting of an early decision while continuing to function correctly otherwise — consistent with context drift, not a memory wipe.
Option C (SQLite file overriding through in-context learning) is a possible contributing factor if a large SQLite-specific file appeared late in the session, but the root cause is the architecture's failure to reinforce the foundational PostgreSQL decision — the SQLite file is an opportunistic trigger, not the root cause.
Option D (tool allow list forcing SQLite) would produce errors or refusals when PostgreSQL tools are invoked, not silent use of a different database. The scenario says no errors occur.
Decisions logs with periodic context re-injection prevent context drift in long-running agent sessions.