Why Switching AI Feels Like Restarting the Project

Louis Wu — Fri, 18 Sep 2026 02:37:56 +0000

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?

Project memory is not chat history: a tiny handoff layer for AI agents

Louis Wu — Thu, 17 Sep 2026 16:05:02 +0000

I kept running into the same failure mode when switching between AI workers, browser sessions, or machines: the files were still there, but the exact working point was gone.

Conversation memory can tell a model what was said. RAG can retrieve relevant documents. Neither one is a durable answer to four operational questions:

What is true now?
Why is that state trusted?
What is already complete and should not be repeated?
What should happen next?

I built Resume the Scene as a very small, model-agnostic project-memory layer for that gap.

GitHub: https://github.com/louisen0o0/resume-the-scene

Update — v0.2.0 is now released: mapped layouts for existing repositories, worker-neutral handoff fixtures, and fail-closed path/memory integrity checks. Release: https://github.com/louisen0o0/resume-the-scene/releases/tag/v0.2.0

The idea

The project keeps the handoff in files that live with the repository. A task state can look like this:

@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 another worker can deterministically recover what to load, what to skip, and what to do next without replaying the prior chat.

What v0.2 does

Resume the Scene is intentionally thin:

selects the project files that form the active memory set;
gives project documents explicit semantic roles;
validates deterministic .rsm frames;
produces checkpoint fingerprints;
emits a compact resume message for the next worker;
keeps project files as the source of truth instead of building a second knowledge base.

There is no vector database requirement, no model-specific identity in the core protocol, and no requirement to archive prompts or responses.

v0.2 also adds:

mapped layouts through .resume/memory.rsm, so existing repositories do not need to move their project/state/task/evidence files;
exact worker-neutral handoff outputs pinned in tests;
fail-closed rejection of absolute paths, traversal, symlink escapes, duplicate document IDs, duplicate memory entries, and missing or duplicate primary authorities.

A small cross-agent fixture

The repository now includes a handoff example where one worker has already completed evidence #e2, and the next worker resumes from the same task state:

resume-scene checkpoint examples/handoff
resume-scene resume examples/handoff

The resume result tells the next worker to skip completed evidence and continue with the next action. That fixture is executed in CI on Python 3.11, 3.12, and 3.13.

Why I am sharing it this early

The implementation is small enough to change. The state model is the part I want challenged before it grows.

If you regularly hand work between coding agents or long-lived AI sessions, I would especially like feedback on this question:

What state would you need to trust before allowing a different agent to continue a real project without replaying the previous conversation?

The project is MIT licensed and the roadmap is public in GitHub Issues.

DEV Community: Louis Wu