Three Ways to Stop Your AI Agent Forgetting Between Sessions (and When Each One Works)

Quick answer: People stop their agents forgetting in three ways. Instruction files (CLAUDE.md, a personal context document) cost nothing and take minutes to set up, but you maintain them by hand and they live inside one tool. Second-brain vaults (an Obsidian vault, a connected agent workspace) give you a structured store you own and can edit directly, but you still decide what gets loaded into each session. Memory layers (a local per-project store, an MCP memory server, a hosted service) do the retrieving for the agent automatically, across sessions and tools. Pick by how much manual work you will actually keep doing, and how many tools the memory needs to follow.

Why every session starts blank

Language models are stateless. Each session opens with an empty context window, and nothing from the previous session is in it unless something puts it there. This is not a model-quality problem; it is a context-availability problem. Yesterday's decisions, the file map, the constraints you already explained — all of it sits outside the prompt until it is moved in.

So the fix is never "a smarter model." The fix is a place where context lives between sessions, plus a mechanism that moves it into the session. Every working solution is one of three answers to that question, differing only in who maintains the store and who does the moving.

Approach 1: instruction files you write and maintain

The cheapest fix is a file the agent loads at the start of every conversation. The most cited version in developer circles is CLAUDE.md: a markdown file with persistent instructions that loads automatically at session start. The more general version is a personal context document — a plain-text file with your role, current projects, key constraints, and preferences that you paste at the top of every new chat. It takes minutes to write, needs no tools, and the improvement is immediate.

The honest limitation is maintenance. Every fact the agent should know next week has to be written and kept current by you, and the file lives inside one tool: move from Claude Code to another assistant and you start again, or you maintain the file twice. If you run one tool and your memory needs are a stable set of rules, this is enough and you should not buy anything. If you run several tools, or your needs change weekly, the file becomes a chore you quietly stop doing — and the forgetting comes back the day you stop.

Approach 2: a second-brain vault the agent reads on entry

One step up is a persistent store that lives outside any single agent's context window: an Obsidian vault or structured markdown files with your standards, voice rules, key decisions, and past work. Before each run, the relevant sections get routed into the agent's prompt, so the session starts warm instead of cold. Waxell Connect takes this workspace idea further: files, state objects, and playbooks persist between sessions, and agents read them automatically on entry — a playbook is a markdown file the agent finds on its own, containing the brief and the process, so updating it once changes every future session.

This is the strongest pick for people who want to own the structure. Nothing leaves your machine unless you put it there; you can open every file, see exactly what the agent will read, and change it directly. The cost is that you are the administrator of your own memory: you design the schema, you decide what gets captured, and someone — you or the agent — still has to move the context into the prompt. It scales exactly as well as your discipline.

Approach 3: a memory layer the agent queries itself

The third answer removes you from the loop. The agent pulls what it needs, when it needs it, from a store that knows what the project has decided.

The local flavor is AIOS ContextDB: decisions, checkpoints, and searchable context stored on disk inside the project and pulled selectively instead of pasted in full, so project data never leaves your machine. The MCP-server flavor is PLUR or Mem0's OpenMemory: PLUR is an open, local-first memory engine (Apache-2.0) that exposes its engram tools over MCP, so one memory store follows an agent across Claude Code, Cursor, OpenClaw, and other MCP-compatible runtimes; OpenMemory is Mem0's equivalent, a local memory layer with standardized memory tools exposed to any MCP client. Key-value memory is the minimal version of the same idea: named facts the agent can fetch exactly, instead of re-deriving them every session.

When the memory has to follow you across tools and devices instead of staying in one project, the hosted flavor is where Vilix AI sits. It is a cloud-hosted memory layer that connects to your AI tools over MCP: point each tool at the same Vilix AI account, and what Claude learned yesterday is available to Codex today, on your laptop or your phone. The tools are get_context (recall) and save_turn (persist). What gets stored is the full user/assistant exchanges, not just extracted facts — plus derived memories, projects, tasks, personal rules, and reusable agent skills. Retrieval is semantic plus keyword, so an agent finds what it needs even when it asks differently than it was stored. Everything is exportable in a portable format, and you can delete individual memories or wipe the account instantly. The free plan is free forever, and the 7-day Pro trial asks for no credit card. Learn how Vilix AI works.

Which one answers your question

The deciding question is not "which is best." It is "which failure mode will you actually manage":

• One tool, stable rules — an instruction file is enough. Anything more is overhead.
• You want to own and inspect the store — a second-brain vault. Accept that you are its administrator.
• The memory must follow you across tools and devices — a memory layer. Local if the data never leaves your machine; hosted if the memory needs to be everywhere you are.

All three fix the same underlying problem: an empty context window is not a memory problem for the model, it is a storage-and-retrieval problem for the system around it. Put a store outside the session and a mechanism that loads from it, and the forgetting stops.