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
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
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.
Implementing memory expiration or a session-boundary reset that clears sprint-scoped state at the start of each new sprint 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.
Increasing the agent's context window size so it can hold both the old and new sprint data simultaneously 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.
Switching the agent from long-term memory to short-term in-context memory so old data is never persisted 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, such as user preferences, team norms, and cross-sprint insights. The right answer preserves long-term memory while adding scope-aware lifecycle management, not eliminating persistence altogether.
Adding a retrieval step that fetches all historical sprints and lets the model decide which data is most relevant 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.