{"slug": "why-switching-ai-feels-like-restarting-the-project", "title": "Why Switching AI Feels Like Restarting the Project", "summary": "A developer has released an open-source project called Resume the Scene that preserves a project's verified execution point independently of chat history or model vendor, arguing that AI continuity failures stem from missing project-state tracking rather than insufficient conversational memory. The tool stores a compact machine-readable project-memory layer covering selection, typed state, references, verification metadata, checkpoints, and next actions, and its v0.2 release adds mapped layouts so existing repositories need not reorganize. The developer distinguishes conversation memory, knowledge/RAG memory, and project memory, contending that agent systems under-specify the third.", "body_md": "You change the AI.\n\nOr you open a fresh session.\n\nThe files are still there. The repository is intact. Nothing has been deleted.\n\nAnd yet the project somehow feels like it has gone back to day one.\n\nThe 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.\n\nThat is the failure mode I kept running into.\n\nI first thought the obvious explanation was: **the AI needs a longer memory**.\n\nI no longer think that is the main problem.\n\nChat memory is useful for conversational continuity.\n\nRAG and knowledge retrieval are useful for finding information.\n\nBut neither one necessarily answers the questions required to continue a piece of work:\n\nThose are not really \"memory\" questions in the conversational sense.\n\nThey are **project-state questions**.\n\nA 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.\n\nThat inference is where a lot of continuity gets lost.\n\nA repository can preserve everything and still be hard to resume.\n\nImagine a project with:\n\nAll the information may technically exist.\n\nBut the next AI still needs a compact answer to:\n\nWhere exactly do I continue from?\n\nThis is the same distinction as having all application data on disk versus having a process checkpoint.\n\nThe data is there.\n\nThe execution point is not.\n\nFor my own projects, the minimum useful handoff turned out to be surprisingly small:\n\nThat can be represented in a tiny machine-readable state instead of another prose summary.\n\nFor example:\n\n```\n@task{id:#t42|goal:#g1|state:active|done:[#e69]|next:#a7}\n@msg{op:resume|task:#t42|load:[#current,#e81]|skip:[#e69]|next:#a7}\n```\n\nThe important part is not the syntax.\n\nThe important part is that the next worker does not need to rediscover the execution state from history.\n\nIt gets told what to load, what to skip, and where to continue.\n\nI turned this idea into a small open-source project called **Resume the Scene**.\n\nThe goal is deliberately narrow:\n\nPreserve the verified execution point of a project independently of chat history or model vendor.\n\nIt does not try to become another chat archive.\n\nIt does not require a vector database.\n\nIt does not put model identity into the core protocol.\n\nThe 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.\n\nIn 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`.\n\nThe handoff fixture is worker-neutral, and exact checkpoint/resume outputs are pinned in tests.\n\nThe 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.\n\nI now separate three things:\n\n**Conversation Memory**\n\n\"What did we say?\"\n\n**Knowledge Memory / RAG**\n\n\"What information exists?\"\n\n**Project Memory**\n\n\"What is true about the work right now, and where do we continue?\"\n\nThe first two are useful.\n\nBut if the third one is missing, switching AI can still feel like restarting the project.\n\nThat is the part I think agent systems are still under-specifying.\n\nWe spend a lot of effort making models remember more.\n\nMaybe some projects need something simpler:\n\n**a reliable resume point.**\n\nGitHub: [https://github.com/louisen0o0/resume-the-scene](https://github.com/louisen0o0/resume-the-scene)\n\nIf you work with multiple AI agents or long-running coding sessions, I would be interested in one question:\n\n**What is the minimum state you need before you trust another AI to continue the task without rereading the whole history?**", "url": "https://wpnews.pro/news/why-switching-ai-feels-like-restarting-the-project", "canonical_source": "https://dev.to/louisen0o0/why-switching-ai-feels-like-restarting-the-project-3jck", "published_at": "2026-09-18 02:37:56+00:00", "updated_at": "2026-09-18 03:22:55.304268+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "agent-protocols", "ai-infrastructure"], "entities": ["Resume the Scene", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/why-switching-ai-feels-like-restarting-the-project", "markdown": "https://wpnews.pro/news/why-switching-ai-feels-like-restarting-the-project.md", "text": "https://wpnews.pro/news/why-switching-ai-feels-like-restarting-the-project.txt", "jsonld": "https://wpnews.pro/news/why-switching-ai-feels-like-restarting-the-project.jsonld"}}