After deploying an agent that assists with sprint planning, your team notices it is referencing tickets and decisions from a previous sprint as if they are still active. The agent's long-term memory store was populated during the last sprint and was never cleared. Which strategy best corrects this context drift?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Context drift is what happens when your agent is still living in the past — like a new employee who keeps referencing the old company policy. The fix is a deliberate reset boundary: at the start of each sprint, scope-specific memory should be cleared or expired. Durable memory is valuable, but it needs lifecycle management tied to the task scope it serves.
Full explanation below image
Full Explanation
Context drift occurs when an agent's memory store contains stale information from a prior task scope — in this case, a previous sprint — and that information bleeds into the current session. The agent has no built-in mechanism to distinguish 'last sprint' from 'this sprint' if both live in the same memory store without expiration or scoping.
Option B is correct because it directly addresses the lifecycle of sprint-scoped memory. Implementing a reset at sprint boundaries — triggered either by a calendar event, a CI/CD hook, or an explicit workflow step — ensures the agent starts each sprint with a clean context. Alternatively, memory entries can carry expiration timestamps so the retrieval layer filters them out automatically.
Option A is incorrect: a larger context window does not solve stale data — it just allows the model to see more of it. The agent would still reference old tickets; it would just be able to reference even more of them at once.
Option C is partially tempting but overcorrects. Switching entirely to short-term in-context memory solves the stale data problem but sacrifices all the legitimate long-term memory benefits (user preferences, team norms, cross-sprint insights). The right answer preserves long-term memory while adding scope-aware lifecycle management, not eliminating persistence altogether.
Option D is incorrect and potentially harmful. Feeding all historical sprints into retrieval gives the model the opportunity to confuse historical decisions with current ones. The agent must reason about which sprint is active — a burden better handled by proper memory scoping than by asking the model to make a judgment call at runtime.
The core principle: every piece of durable memory should be tagged with its scope and a TTL (time-to-live) or reset trigger so it is pruned when the task context it serves is no longer active.