Does what you need an AI to remember shift as you move from starting a task to picking it up again later?

This explores whether what people need from an AI's memory shifts as they move through the stages of a task, and how often that happens. The direct answer is that the collection doesn't measure frequency. No study here tracks users across task stages and counts how often their memory needs change. What the corpus does show is that memory needs are layered by how long each kind of information stays useful, and that this layering is where the stage-by-stage shifts come from.

The clearest user-side evidence is that people already sort memory into tiers. They put general knowledge at the top, then personal details, then task-specific information How should AI agents organize their memory for users?. The task-specific tier is the one that changes most as work moves forward. The general tier barely moves. Tools don't expose this hierarchy, so users handle the shifts by hand: they start a new chat thread for a new phase, write custom prompts, or even keep separate accounts. Those workarounds are a rough, indirect sign of how often needs change. Each time someone opens a fresh thread to keep context clean, they're marking a stage boundary the product didn't notice. Users also want control at the moment memory is captured, not later Do users prefer controlling what gets remembered over auditing what was stored?. Prompts that ask where a memory should go, and boundary settings, beat reviewing a log after the fact. That points to stage transitions as the moments where users want a say.

Research on the agent side gives the same picture from the machine's point of view. One framework splits an agent's working memory into parts that last for the whole conversation (history, a scratchpad) and parts that change every turn (examples, the current task trajectory). Each kind has its own update rules and fails in its own ways How should agent memory split across time scales?. Web-agent work goes further: memory indexed by the agent's exact current state (what's on screen right now, what to click next) beats memory stored as high-level workflow summaries Does state-indexed memory outperform high-level workflow memory for web agents?. At the execution level, then, the useful memory can change with every step. Big-picture plans are too coarse to help with the click-by-click part.

The less obvious lesson is that the right memory isn't only a question of what's relevant. It depends on what job the memory is doing at that moment. Memory that clarifies a request improves accuracy, while loosely related memory actively makes answers worse Does retrieved memory quality depend on its functional role?. Long multi-turn agents break down from weak control over what gets written down and kept, not from missing knowledge. Separating temporary recall from permanent memory writes prevents drift Can agents fail from weak memory control rather than missing knowledge?. If memory has to be filtered differently by role and by permanence, then a change of stage is really a change in which roles matter.

One design response is to make stages visible instead of guessing at them. A shared canvas puts prompts, references, versions and feedback on screen as typed objects that both the user and the agent can see. That lets someone resume unfinished work or update one piece without re-explaining the whole task Can a shared canvas serve both human and agent memory?. It also matters that which memories get surfaced is a product decision, not a property of the model How do AI products decide what to remember between conversations?. So 'how often do needs change' is partly a question about how often the product notices a change. Today, users mostly do that noticing themselves.