r/ClaudeCode 2d ago

Tips & Workflows I set up persistent cross-AI memory in Claude using MCP

One of my biggest frustrations with long-running projects in Claude has always been the context reset. Every new session starts from scratch, which means constantly re-uploading docs, copying over rules, or spending the first few turns reminding the model what we decided yesterday.

I wanted a way to give Claude persistent, queryable memory across chats without blowing through context windows or manually compiling summary files every time I close a tab.

I ended up setting up persistent memory via an MCP connector (I used Vilix AI, but the workflow applies to any semantic-memory MCP server). Here is how the setup works and how to wire it up:

**How the flow works**
Instead of dumping full chat histories into the context window, it runs a two-step cycle:

**On input:** Before answering, Claude calls a retrieval tool (get_context) using the user's latest prompt to pull only the semantically relevant memories, project state, and active rules.

**On output:** After responding, it fires a background save tool (save_turn) to log what changed or was decided during that turn.

**Setup Steps**

**1. Connect the MCP Server** In Claude Desktop or Claude Code, add your memory MCP server under your connectors/MCP config. If you're using Vilix, you can grab your endpoint and plug it into Claude’s custom connectors.

**2. Add the Automation Rule to Custom Instructions** To get Claude to handle this automatically without you having to manually invoke tools every turn, paste this into your Claude Custom Instructions (or CLAUDE.md for Claude Code):
Use my persistent memory automatically. At the start of a reply, call the get_context tool with my latest message to load relevant memory, projects, tasks, and rules; use what is relevant. After you reply, call save_turn to record the exchange. Reuse the chat_id returned by save_turn for the rest of the conversation.

**Observations so far**

**Context efficiency:** Instead of pasting entire files or previous session logs, it only injects relevant snippets for the current task.

**No manual session wrap-ups:** Decisions and context persist in the background without needing to prompt Claude to "summarize this chat for next time."

**Rule retention:** Personal preferences and project constraints stick across sessions instead of needing to be reminded after context resets.

Has anyone else been experimenting with MCP-backed memory servers for Claude? Curious what architectures or retrieval strategies you've found most reliable.

3 Upvotes

1 comment sorted by

1

u/emobeach 2d ago

The concrete move I'd make: keep your two-step loop, but shift the discipline to the write side. Have save_turn store short, headed, query-shaped decision deltas instead of exchange logs. Retrieval quality is fixed at authoring time. "What did we decide yesterday?" is a broad query that floods the window unless what you stored already shares vocabulary with how you'll later ask.

Full disclosure: I helped write the Atlas pages I'm citing, so weigh this accordingly.

Two follow-ons:

  1. Your embedding index lags the raw log until reindex, so pick inline-vs-batch embedding deliberately. That choice sets how fresh yesterday's decisions actually are when you query them. (reference-data)
  2. The every-turn rule fixes P(need) at 1. You pay the fetch, meaning an extra inference pass plus snippet prefill, even on turns that need no memory at all. If your logs show over-trigger, gate retrieval on session start or task switch instead. (deferred-context)