You change the AI.
Or you open a fresh session.
The files are still there. The repository is intact. Nothing has been deleted.
And yet the project somehow feels like it has gone back to day one.
The new AI starts asking questions that were already settled. It re-checks work that was already verified. It proposes paths that were already rejected. Before it can continue, someone has to reconstruct the state of the project from chat history, commit history, notes, and memory.
That is the failure mode I kept running into.
I first thought the obvious explanation was: the AI needs a longer memory.
I no longer think that is the main problem.
The missing thing is not more conversation
Chat memory is useful for conversational continuity.
RAG and knowledge retrieval are useful for finding information.
But neither one necessarily answers the questions required to continue a piece of work:
- What task is active right now?
- What has already been completed?
- Which evidence has been verified?
- Which decisions are still valid?
- What should not be repeated?
- What is the exact next action?
Those are not really "memory" questions in the conversational sense.
They are project-state questions.
A long transcript may contain the answers somewhere. A vector database may retrieve several relevant documents. But the next worker still has to infer the current state.
That inference is where a lot of continuity gets lost.
Files are not the same as a resume point
A repository can preserve everything and still be hard to resume.
Imagine a project with:
- 200 files,
- 30 commits,
- three design documents,
- two rejected approaches,
- one partially completed migration,
- and an important test result buried in yesterday's session.
All the information may technically exist.
But the next AI still needs a compact answer to:
Where exactly do I continue from?
This is the same distinction as having all application data on disk versus having a process checkpoint.
The data is there.
The execution point is not.
What the next AI actually needs
For my own projects, the minimum useful handoff turned out to be surprisingly small:
- Current Task — what is being done now.
- Done / Skip — what has already been completed and should not be repeated.
- Trusted Evidence — what has actually been verified.
- Active Decisions — which choices still govern the work.
- Next Action — the precise place to continue.
That can be represented in a tiny machine-readable state instead of another prose summary.
For example:
@task{id:#t42|goal:#g1|state:active|done:[#e69]|next:#a7}
@msg{op:resume|task:#t42|load:[#current,#e81]|skip:[#e69]|next:#a7}
The important part is not the syntax.
The important part is that the next worker does not need to rediscover the execution state from history.
It gets told what to load, what to skip, and where to continue.
This is why I built Resume the Scene
I turned this idea into a small open-source project called Resume the Scene.
The goal is deliberately narrow:
Preserve the verified execution point of a project independently of chat history or model vendor.
It does not try to become another chat archive.
It does not require a vector database.
It does not put model identity into the core protocol.
The project files remain the source of truth. Resume the Scene stores only the project-memory layer required to resume work: selection, typed state, references, verification metadata, checkpoints, and the next action.
In v0.2, it also supports mapped layouts, so an existing repository does not need to reorganize itself just to adopt project memory. Project, state, task, evidence, and decision files can remain where they already live and be mapped through .resume/memory.rsm.
The handoff fixture is worker-neutral, and exact checkpoint/resume outputs are pinned in tests.
The validator also fails closed on things such as path traversal, absolute paths, symlink escapes, duplicate document IDs, duplicate memory entries, and missing or duplicate primary authorities.
The mental model that changed for me
I now separate three things:
Conversation Memory
"What did we say?"
Knowledge Memory / RAG
"What information exists?"
Project Memory
"What is true about the work right now, and where do we continue?"
The first two are useful.
But if the third one is missing, switching AI can still feel like restarting the project.
That is the part I think agent systems are still under-specifying.
We spend a lot of effort making models remember more.
Maybe some projects need something simpler:
a reliable resume point.
GitHub: https://github.com/louisen0o0/resume-the-scene
If you work with multiple AI agents or long-running coding sessions, I would be interested in one question:
What is the minimum state you need before you trust another AI to continue the task without rereading the whole history?
Top comments (1)
The “write for the way people talk” point is the key takeaway. Good voice-search optimization isn’t about adding more conversational keywords—it’s about answering real questions clearly and directly.