Picking up where we left off with AI

We might start exploring an idea in ChatGPT, ask Claude for a second opinion, then hand part of the work to an agent. What we discussed in the first tool is not necessarily available in the next. If we change our mind along the way, that change needs to carry over too.

This is not just a matter of how many models we use. We can switch models within a project, or scatter our conversations across separate chats with the same model. What matters is whether each tool can access the information it needs when we ask it to continue.

When work is spread across tools, each memory may preserve its own part accurately without making the whole easy to reconstruct. A decision changed in one conversation can remain unchanged in another. If several people are working separately, we also need to know what they have shared and agreed on together.

There are already ways to address this. A shared reference document, kept up to date, may be enough. Connectors can make some sources available to several tools. Claude also supports importing and exporting memory between providers, with documented limitations on how imported memories are incorporated.²

But transferring a memory at one point in time does not tell us how later changes will be carried across. We need to look at what is accessible, what gets updated and which decision takes precedence when versions disagree. Files and working habits can support this, as can a shared memory.

Consider a consultant preparing a proposal with an AI assistant. The consultant sets a price, then the client asks for a discount. Unsure how to respond, the consultant talks it through with the AI and explores several options. They eventually agree on a discount with the client, record the exchange and the reasons for the agreement in the AI conversation, then move on to other projects.

A few months later, the client comes back with more work. The consultant finds the discounted quote but no longer remembers why they offered that price. Searching the tool may lead to the right conversation but the wrong passage: the original price, rather than the one actually charged.

The consultant could instead open a new conversation and ask the AI: “Why did we agree on that price for this client?” If the tool retrieves the final agreement and the reason behind it, the consultant can move on. If it returns the original price or an option that was later rejected, it has found something that was actually discussed, but not what was ultimately agreed. It might even get the amount right and the explanation wrong.

Rereading the exchanges could recover the reasoning and the decision, but that takes time and energy when the consultant simply wanted to continue the work. This is the reconstruction effort we would like to avoid: we want to recover the decision that superseded the earlier one, when it changed and why, without having to investigate everything again.

Coding agents introduce another challenge. An agent may override a technical choice we had specified, without recording why. Asked to explain, it may then reread the code, context files and available conversations to reconstruct what might have happened. That takes time, can use a lot of tokens and does not guarantee that it will recover the original reason.

Treating it as an established fact could lead us to undo a justified change and reintroduce the very problem it solved. The issue is not only whether the agent made the right choice. It is whether we can check why it made it.

The two overlap. A good memory system can provide continuity.

To understand what may be missing when we resume work, we propose distinguishing four functions.

To make work continuity more concrete, we also need to describe the state someone needs in order to resume. We propose the following definition.

We should distinguish between the conversations we keep, the information we organize into memory and what we supply when we resume work. We can retain the sources, maintain a summary and consult particular passages when needed.

One difficulty remains: people do not always say “I have decided.”

A system that detects these phrases needs to preserve uncertainty or ask a focused question, rather than turn every idea into a decision. Search matters, then, but so does how choices are recorded. The question is how to preserve decisions, their reasons and subsequent changes without asking the user to restate everything at every step.

A long conversation, an extensive knowledge base or a detailed history may contain the information we need without making clear which version still applies. Adding more context can help, but it can also mean more to read or bring an abandoned decision back into consideration.

The first design question is therefore: what does a person or agent need to act appropriately now? The answer may include the history, but it is not limited to it.

A memory system can add a note, a memory or a document. To help us resume work, it also needs a way to mark information as:

Dates and provenance help us understand where a claim came from and the circumstances in which it was made. They do not guarantee that it still holds: a well-sourced statement can become false, while a current decision may not yet be documented. The system must accommodate corrections and uncertainty, as well as new information.

Research has long shown that people draw on several resources to pick up where they left off. The need to recover the thread did not begin with LLMs.

Our hypothesis is that LLMs may change the pace and scale of the problem. We explore more possibilities, move between topics and delegate tasks that continue without us. The work can advance faster than our understanding of what has changed. Saving time on production does not necessarily remove the time needed to understand, check and resume it.

These studies address different, complementary aspects: how people resume work, memory across sessions and how an agent maintains state. We bring them together to understand the problem, not as a single evaluation of work involving several tools and people.

LongMemEval connects directly to the pricing example. Finding a price mentioned in a conversation is not enough: the system needs to distinguish a proposal from the final agreement.

Context engineering involves selecting, organizing and maintaining the information supplied to a model. It already includes ways to support continuity, such as searching sources, keeping persistent notes and producing summaries.⁸

In the pricing example, there are two options: search the earlier exchanges ourselves, or ask the AI to recover what was agreed. Built-in features give us a starting point for resuming work. Reusing information from previous conversations can save us from explaining everything again. What can they retrieve, and what limitations are documented?

We can find the passages and supply them ourselves. That may let us continue, but we still have to select the material and put it back into context. An exploratory study from 2025, based on six interviews and 54 Reddit threads, describes practices such as transferring information between sessions.¹²

These developments do address continuity. The announcements alone, however, are not independent evaluations of how well the tools support every kind of return to work.

Before switching tools or adopting a new system, it helps to identify what makes it difficult to resume our work. A disappointing search result, an unrecorded decision and a file containing conflicting information call for different responses.

A plugin might propose a checkpoint after an exchange. Its usefulness will depend in part on whether it can flag uncertainty, preserve sources and allow corrections. Recording more often does not, by itself, settle which information should be treated as authoritative.

The material reviewed gives us reason to take the difficulty seriously. It does not show that a new memory layer is always necessary, or that it is preferable to a well-maintained existing approach.

Work continuity matters for an individual, and extends to a team when people think, discuss and act using their own AI tools.

A memory that is useful to one person does not automatically become an organizational memory.

Depending on the task, a maintained reference, shared files, connectors or a handover process may be enough. The right approach will depend on the maintenance effort, how it fits the actual work and how much separation is needed between people’s information.