Back to Blog

2025-08-15

Giving Your AI a Memory It Won't Forget

#mcp#open-source#knowledge-management#python

Persistent memory networks for AI assistants

Every conversation with an AI assistant starts the same way. You explain your project. You remind it about your preferences. You re-establish context that existed perfectly well yesterday but evaporated overnight. It's like working with the smartest coworker in the world who has total amnesia every morning.

We got tired of it. So we built something about it.

The Problem Nobody Talks About

LLMs are stateless by design. Each conversation is a fresh start. That's a feature for privacy, but it's a bug for productivity. If you're using Claude as a daily tool — and we are, heavily — the re-onboarding tax adds up fast.

You find yourself keeping a notes file just to paste into new conversations. Or writing elaborate system prompts that try to encode everything the AI should "know" about you. It's duct tape on a structural problem.

What we actually needed was a way for Claude to read from and write to a persistent knowledge store. Not a vector database we'd have to manage ourselves. Not a local file system hack. Something that could organize information intelligently and retrieve it when relevant.

Why Mem.ai

We'd been using Mem.ai independently for personal knowledge management. The product does something clever — it uses AI to automatically organize and surface notes based on content rather than folder structure. You throw things in, and Mem figures out how they relate.

The moment Anthropic shipped MCP (Model Context Protocol), the connection was obvious. If Claude could read and write to Mem.ai, every conversation would have access to accumulated context. Meeting notes from last week. Technical decisions from last month. Project details you shouldn't have to repeat.

What We Built

MCP Mem.ai is a production-ready MCP server that gives any MCP-compatible AI assistant full access to Mem.ai. Six tools, clean API, async throughout.

The core tools:

mem_it is the one we use most. It takes any content — meeting notes, code snippets, research findings, random ideas — and saves it to Mem with optional processing instructions. Tell it to "extract action items" or "summarize key decisions" and it does that before storing.

create_note gives you structured control when you need it. Markdown formatting, collection assignment, explicit organization. Good for templated workflows where you know exactly where something should land.

read_note and the collection tools round it out. Claude can browse your knowledge base, pull specific notes, and organize things into collections without you ever leaving the conversation.

How It Actually Works Day-to-Day

The workflow that emerged surprised us. We didn't plan it — it just happened once the plumbing was in place.

At the end of a working session with Claude, we'll say something like "save the key decisions from this conversation." Claude uses mem_it to extract and store the important bits. Next session — could be hours later, could be days — we mention the project name, Claude pulls the relevant notes from Mem, and we pick up where we left off without the usual five minutes of re-explaining.

The compounding effect is real. After a few weeks, Claude has access to a rich context layer that grows with every interaction. It knows which tech stack you chose and why. It remembers that you tried approach X and it didn't work. It has the meeting notes from when the client changed requirements.

The Technical Bits

The server is Python, built on FastMCP. Full async/await throughout because Mem.ai's API is HTTP-based and we didn't want blocking calls slowing down the MCP communication layer. Pydantic models handle request/response validation. Custom error types give Claude actionable feedback when something goes wrong — not just a stack trace, but context about what to try differently.

The architecture is intentionally simple:

  • client.py wraps the Mem.ai API with async HTTP
  • models.py defines Pydantic schemas
  • server.py registers the MCP tools

Three files. No framework bloat. No middleware chain. The kind of server you can read top to bottom in ten minutes and understand completely.

What We Learned

Building MCP servers has a deceptive simplicity. The protocol itself is straightforward. The hard part is designing tool interfaces that an LLM can use effectively. We went through several iterations of the mem_it tool's parameter design before landing on something that Claude consistently uses well.

The key insight: LLMs are better with fewer, more flexible tools than many rigid ones. Our first version had separate tools for "save meeting notes," "save code snippet," "save research." We collapsed all of that into mem_it with an instructions parameter, and Claude's usage quality jumped immediately.

Try It

The server is open source on GitHub. If you're a Mem.ai user and you're tired of re-explaining yourself to Claude every session, this might save you more time than any prompt engineering trick.

You'll need a Mem.ai API key and about five minutes for setup. The README has everything.