How to give your AI agent persistent memory across sessions

Every agent you run starts from zero. You spend an hour teaching it your stack, your naming conventions, the fact that you deploy on Fridays and never touch prod on weekends. Next session: gone. The model kept nothing. That gap is the whole problem, and giving your AI agent persistent memory is the fix. This post covers why stateless agents forget, the three ways to add durable memory, and how to wire a local memory server into Claude Desktop or Cursor so recall actually survives a restart.

Why stateless agents forget: context window vs a durable store

An LLM has no memory of its own. What looks like memory is the context window: the tokens you feed it on each call. Close the session and the window is discarded. The weights never change. So an agent that “remembered” your API key format last Tuesday only remembered it because that text was still in the prompt.

There are two separate things people conflate here. The context window is working memory: fast, bounded, wiped on every fresh run. A durable store is long-term memory: it lives on disk, outlives the process, and gets loaded back into context when relevant. AI agent persistent memory means adding the second thing and connecting it to the first. The model stays stateless. The store around it does the remembering.

Three options and their tradeoffs

There are three common ways to give an agent durable memory, and they trade off differently on cost, privacy, and quality.

Prompt-stuffing. Dump everything you want remembered into a system prompt or a CLAUDE.md file and prepend it every run. Dead simple, zero infra. It breaks the moment the file outgrows the window, and you pay input tokens for the entire blob on every single call, even the parts irrelevant to the current task. Fine for a page of preferences, useless as a real knowledge base.

Cloud RAG. Push memories into a hosted vector database, embed each query, retrieve the top-k chunks. Scales to large corpora and retrieval is decent. The cost: your data leaves the machine, and you pay per embedding call plus per query plus monthly storage. For an agent that reads and writes memory hundreds of times a day, that bill compounds fast. We broke down the math in local-first memory economics; the short version is that per-query billing punishes exactly the access pattern agents have.

Local semantic memory. Run the vector store and the embedding model on your own machine. You get semantic retrieval without the network round-trip, without the per-query invoice, and without shipping private context to someone else’s server. This is the approach behind EngramMCP: SQLite for structured records, LanceDB for vectors, and Ollama running nomic-embed-text for embeddings, all local. The tradeoff is you host it yourself, which for a dev machine is a non-issue.

Wiring an MCP memory server into Claude Desktop or Cursor

Memory becomes AI agent persistent memory only when the agent can call it as a tool. That is what MCP is for: a standard protocol that lets a client like Claude Desktop or Cursor talk to a local server. If MCP is new to you, start with what is MCP.

You register the server in the client config. For Claude Desktop, edit claude_desktop_config.json:

{
  "mcpServers": {
    "engram": {
      "command": "engram-mcp",
      "args": ["serve"]
    }
  }
}

Cursor uses the same shape under its MCP settings. Restart the client and the memory tools show up. The three you will use constantly:

• remember: write a fact, decision, or preference to the store.
• recall: semantic search over everything written, returns the relevant records.
• recent: pull the last N memories, useful for picking up where the last session ended.

EngramMCP exposes 21 tools total (ingest, relate, watch, and more), but remember, recall, and recent are the loop you run every day.

What to store versus what to skip

The failure mode is remembering everything. A store full of noise retrieves noise. Be deliberate.

Store: durable facts (the prod database is Postgres 16), decisions and their reasons (we dropped Redis because the cache hit rate was under 20 percent), and stable preferences (run tests before every commit). Skip: transient state, anything already in the repo, and anything the agent can recompute.

One rule that saves you real pain: make writes idempotent. If an agent remembers “user prefers tabs” on every turn, you get the same fact fifty times and recall returns fifty duplicates. Check before you write, or key memories so a repeat write updates instead of appends. Without this, an autonomous agent can loop and flood its own store.

Retrieval quality: tags, importance, relations

Writing memories is easy. Getting the right one back at the right time is the hard part, and raw vector similarity alone is not enough.

Tags scope retrieval so a query for deployment notes does not surface database trivia. Importance lets you weight a memory so a load-bearing decision outranks a passing remark with set_importance. Relations connect memories into a graph: link a decision to the bug that caused it and the fix that followed. Then recall_chain walks those links and returns the whole thread instead of one isolated fragment, which is what you want when the agent needs the full story, not a single sentence.

Combine the three and retrieval stops being a lucky-dip. You get the memory that matters, with its context attached.

Cost and privacy: why local beats per-query billing

Agents are chatty with memory. They read before acting and write after. Under cloud RAG, every one of those is a metered call, so the more useful the memory the higher the bill. Local flips that: embeddings and search run on hardware you already own, so read and write as often as the agent needs. The marginal cost is zero.

Privacy lands the same way. Your decisions, your client details, your architecture all stay on your disk. Nothing is embedded on a third-party server, nothing is retained under someone else’s policy. For anything covered by an NDA or touching credentials, local is the only version that passes review.

EngramMCP is source-available and in invite-only early access. If you want in, DM @LeRaviole_ on X for access, drop the config above into your client, and your agent stops starting from zero.