Why I Built a Persistent Memory System for AI

Every morning I open Claude Code and start a new session. And every morning, I repeat myself. What project am I working on. What decisions I already made. What patterns I follow. The model is brilliant — but it has no memory. After months of this friction, I decided to fix it. I built a persistent memory system — a knowledge graph with semantic search, deployed as an MCP server — that gives my LLM workflows cross-session context. This post is about why I built it, how it works, and what I learned. --- ## The Problem: Stateless Intelligence Large language models are the most capable reasoning tools we have ever built. But they start every conversation from zero. They do not remember that yesterday you decided to use DynamoDB instead of PostgreSQL. They do not know that your team convention is to put business logic in service classes, not controllers. They do not remember debugging that obscure CORS issue for two hours. This is not a limitation of the model — it is a limitation of the interface. The model can reason about anything you give it. The bottleneck is what you give it. > The model does not matter as much as the context you feed it. ## The Architecture I built the Memory MCP Server as an AWS-native system with three core components: ### 1. Knowledge Graph (DynamoDB) Entities (Projects, Decisions, Bugs, Patterns, Sessions) stored as nodes with typed edges between them. When I make an architecture decision, I save it as a Decision entity linked to the relevant Project. When I fix a bug, I save the root cause and link it to the Session. ### 2. Semantic Search (Bedrock + Knowledge Bases) Every entity is embedded using Amazon Bedrock and indexed in a vector store. This means I can search by meaning, not just keywords. Searching for "database choice" finds my Decision about DynamoDB even if the word "database" never appears in the entity. ### 3. MCP Protocol The system exposes tools via the Model Context Protocol — memory_write, memory_search, memory_graph_query, memory_get_context. Any MCP-compatible client (Claude Code, Claude Desktop) can use these tools natively. ```python # Example: Getting context at the start of a session tool_memory_get_context(topic="authentication system", project="my-app") # Returns: related decisions, patterns, recent sessions, and connected entities ``` ## What Changed The difference is immediate and compounding: - No more repeating project conventions — the model reads them from memory - No more contradicting past decisions — it checks before suggesting - No more losing debugging insights — root causes are saved and searchable - Context accumulates across sessions like compound interest The most surprising effect: it changed how I think about AI collaboration. Before, every session was transactional — ask question, get answer, move on. Now it feels like working with a colleague who actually remembers our shared history. ## The Technical Decisions A few choices worth sharing: **DynamoDB over Neo4j:** I considered a dedicated graph database, but the access patterns are simple (single-hop and two-hop traversals). DynamoDB with GSIs handles this efficiently, and I was already deep in the AWS ecosystem. Simplicity won over specialization. **Bedrock over OpenAI embeddings:** Staying within AWS means lower latency (no cross-cloud calls), simpler auth (IAM roles), and one fewer API key to manage. The embedding quality difference is negligible for this use case. **MCP over custom API:** The Model Context Protocol is becoming the standard for tool integration. Building as an MCP server means any compatible client gets the memory system for free — no custom integration needed. ## What I Would Do Differently - Add automatic memory extraction — right now, writes are manual (triggered by CLAUDE.md instructions). An async process that extracts entities from conversation transcripts would reduce friction. - Better conflict resolution — when a new decision contradicts an old one, the system should surface the conflict explicitly and ask which to keep. - Session summarization — automatically generate session summaries instead of relying on the model to write them. ## The Bigger Idea I think persistent memory will become a standard layer in AI tooling, the way databases are a standard layer in web applications. Every serious AI workflow will have a context store — a place where decisions, patterns, and knowledge accumulate over time. The models will keep getting smarter. But the teams and individuals who build better context systems will get disproportionately more value from them. Your context is your moat. --- The Memory MCP Server is open source on GitHub. If you are building LLM workflows and want cross-session memory, check it out and let me know what you think.