If your AI agent forgets context between sessions, the root cause is usually stateless model calls plus session-scoped memory. Fix it by moving durable facts, decisions, and source-linked notes into a persistent MCP memory server, then requiring new sessions to read that scoped memory before answering.
Last updated: June 20, 2026.
Why does my AI agent forget context between sessions?
Your agent forgets because the model does not automatically inherit yesterday’s working state. Most agent apps rebuild each answer from the current prompt, active session messages, tool results, and whatever external memory the app explicitly retrieves.
LangChain’s memory documentation draws the same boundary: short-term memory is thread-scoped, while long-term memory is stored across sessions and recalled from a namespace or store (LangChain memory overview). Anthropic’s context-engineering guidance also treats persistent notes outside the context window as a separate technique for long-horizon work (Anthropic context engineering).
That distinction explains the common failure pattern:
| What the developer expects | What the agent actually has |
|---|---|
| ”It should remember the decision from last Friday.” | The new session only has today’s prompt unless memory is retrieved. |
| ”It should know the repo convention I taught it.” | The convention lived in a previous chat transcript, not durable memory. |
| ”It should pick up where the old run stopped.” | The old run’s task state was not written to a persistent store. |
| ”It should know the current source.” | The agent has no source-linked recall path for the new session. |
This is not a personality flaw in the model. It is an architecture issue: the model can reason over context it receives, but the application owns what survives across sessions.
Why isn’t a bigger context window enough?
A bigger context window gives the agent more temporary workspace; it does not create a memory lifecycle. If the app never writes durable state, the next session still starts cold.
Long contexts also introduce their own failure modes. LangChain notes that long conversations can exceed model limits or distract the model with stale or off-topic content (LangChain memory overview). Anthropic makes the same point in a different way: long-horizon agents need compaction, structured note-taking, and retrieval patterns because context windows remain finite and vulnerable to context pollution (Anthropic context engineering).
The durable fix is not “paste the whole history again.” It is:
- decide what deserves to persist;
- save it with source and scope;
- retrieve the relevant subset in the next session;
- expose enough trace information to inspect misses.
That is why the Agent Memory guide treats memory as a write, store, retrieve, inspect, and delete loop rather than a longer prompt.
What should become persistent memory?
Persist facts that will still matter after the current chat ends. Do not persist every message.
Good memory candidates include:
- product decisions with a source document or meeting note;
- project conventions that multiple agents should follow;
- user or team preferences that are stable and consented;
- source-linked facts from docs, tickets, pages, or transcripts;
- unresolved task state that a future session must continue.
Weak memory candidates include:
- transient tool output;
- one-off brainstorming;
- raw scratch work;
- unsupported guesses;
- sensitive values that do not belong in an agent memory layer.
Recent memory research frames this as a data-management workload, not a generic pile of notes. A 2026 arXiv paper on long-term agent memory argues that memory needs state-level operations such as ingestion, revision, forgetting, and retrieval, not just record storage (Is Agent Memory a Database?).
How do you fix it with an MCP memory server?
Use MCP to deliver the same memory tools to the agent client, then keep the memory outside the chat session. The Model Context Protocol defines a standard client-server pattern for connecting AI applications to external systems (MCP introduction). Its architecture docs describe MCP servers as programs that provide context to MCP clients through tools, resources, and prompts (MCP architecture).
For Answer Engine, the install shape is the same one used in the Claude Code and Cursor guides. Paste this into the relevant MCP config and replace the key and library id:
{
"mcpServers": {
"answer-engine": {
"command": "npx",
"args": ["answer-engine-mcp"],
"env": {
"ANSWER_ENGINE_API_KEY": "ae_live_your_key_here",
"ANSWER_ENGINE_API_URL": "https://engine.answeragent.ai",
"ANSWER_ENGINE_LIBRARY": "your-memory-library-id"
}
}
}
}The runnable command behind that config is npx answer-engine-mcp; the JSON form splits it into command and args so MCP clients can launch the server process correctly.
Use Add persistent memory to Claude Code for the .mcp.json placement and Add persistent memory to Cursor for the .cursor/mcp.json placement. Both use the same memory server, which keeps the memory portable instead of trapping it inside one client.
What should the agent do at the start of a new session?
The new session should perform an explicit recall step before it answers from memory. A simple instruction is enough to make the behavior inspectable:
At the start of a new task, use the answer-engine MCP tools to search the
scoped memory library for durable project facts, prior decisions, and current
source notes relevant to the user's request. Cite the retrieved source or say
that no relevant memory was found.That instruction is not magic. It just makes the expected read path visible. A durable store still needs good retrieval, source metadata, and sane write rules. The point is to stop assuming the agent will remember a previous session without being given a retrieval path.
How do you verify the fix?
Run a fresh-session test with a harmless fact:
Save this memory in Answer Engine: the escalation label for this repo is
ae-support-critical. Source: C35 memory wiring test on June 20, 2026.Then start a new agent session and ask:
Use Answer Engine memory to find the escalation label for this repo.A good result does three things:
- calls the
answer-engineMCP server; - returns the saved fact;
- names the source or memory item that supported the answer.
If the agent guesses without calling the server, the problem is not persistence yet; it is tool-use policy. If the server is not connected, debug the MCP config. If the server returns many irrelevant items, move to the retrieval failure checklist in RAG returns wrong results.
What should you avoid?
Avoid the tempting quick fixes.
Do not paste the full transcript into every prompt. That raises noise and cost while still leaving no write policy. Do not store every chat turn as a memory. That creates memory bloat and makes later retrieval worse. Do not commit real API keys in .mcp.json or .cursor/mcp.json. Keep placeholders in shared config and load secrets locally.
Most importantly, do not treat “memory” as only a vector search box. Cross-session memory needs persistence, source lineage, scope, supersession, and inspection. The narrower you make the memory contract, the easier it is to prove why the agent remembered or missed something.