Bourdon vs Mem0: two answers to "why doesn't my agent remember"

The question underneath the question

"Give my agent memory" turns out to mean different things depending on what you're actually trying to fix. If the problem is one assistant forgetting your codebase's conventions between sessions, you want extraction and recall. If the problem is that Claude Code learned something on Monday and Cursor still doesn't know it Tuesday, you want sharing, and sharing is where these two tools genuinely part ways.

Mem0 is the incumbent here: an open-source memory layer with roughly 62,000 GitHub stars, a hosted platform, and a well-documented extraction pipeline. Bourdon is newer, self-hosted-first, and built around a different bet: that recognition should be near-instant, and that memory should follow you across your machines and accounts, not just between processes on one box.

How each one decides what to remember

Mem0's pipeline is LLM-driven: you send it messages, it distills them into discrete facts, links entities, and issues ADD, UPDATE, DELETE, or NOOP against existing memory so the store doesn't just grow forever. Storage is a mix of vector, graph, and key-value backends, scoped by identity markers (user_id, agent_id, run_id, app_id) so you can keep a user's memory separate from an agent's inferred facts. Mem0 publishes benchmark numbers for this pipeline: 92.5 on LoCoMo and 94.4 on LongMemEval, with single-pass retrieval latency around 0.88–1.09 seconds.

Bourdon skips the extraction-then-query round trip for the common case. Its model is three stages (recognition, hydration, archive descent), where recognition is a near-zero-latency lookup against a hot cache (Bourdon's own figures: 0 ms recognition vs. roughly 406 ms for a traditional search-first system), full context hydrates in parallel, and a deeper archive search only runs when recognition comes up empty. Memory itself is a directory of plain YAML files on disk, in a published schema, rather than rows in a vector or graph database.

Neither number was measured against the other tool, on the same task, by a neutral party, so treat them as each project's claim about itself, not a head-to-head result. What they do tell you honestly: Mem0 is optimized for rich, structured recall; Bourdon is optimized for the recognition step being fast enough that the agent doesn't visibly pause.

Where "shared" stops meaning the same thing

This is the part worth reading closely before you pick one. Mem0 ships OpenMemory, a local MCP server that multiple MCP-compatible clients (Claude Desktop, Cursor, Windsurf, VS Code) can all point at. If you run one OpenMemory instance on your machine, every agent that connects to it reads and writes the same local memory. That's real sharing, and it's simple to set up. What it isn't, per Mem0's own docs, is federation: there's no described mechanism for syncing that memory to a second machine or a second account.

Bourdon's federation is built for exactly that gap. A shared library federates across accounts and machines, opt-in only: nothing loads from a peer without an explicit flag, and inbound data is quarantined and validated before it touches your local store. bourdon agents --federated shows you who's in the federation; bourdon doctor checks the health of your store and peers. If your agents run on different laptops, in different environments, or under different accounts, this is the piece Mem0's local MCP server doesn't claim to solve.

So: same machine, one server, several MCP clients: Mem0's OpenMemory does that today. Across machines and accounts, opt-in and validated: that's Bourdon's actual design center.

Running it

Mem0 gives you three deployment shapes: an embedded library for prototyping, a self-hosted server with auth on by default for team infrastructure, or the managed cloud platform for zero-ops production. It's Apache 2.0.

pip install mem0ai
# or
npm install mem0ai

Bourdon is self-hosted by default: you run the server, agents connect to it over MCP. The interoperability surface is Apache-2.0; the engine is BUSL-1.1, converting to Apache-2.0 after four years. It's also listed in the MCP Registry as ai.bourdon/bourdon, so MCP-aware tooling can discover it directly.

pip install bourdon
bourdon serve
# or the MCP server via npm:
npx @getbourdon/mcp-server --library ~/agent-library

Which one to reach for

If you want one memory store that several MCP clients on your own machine can all read and write, with a mature extraction pipeline, a graph store for entity relationships, and a hosted option so you don't run anything yourself, then Mem0 is the more finished tool today, and its benchmark suite is public if you want to check the recall quality claims yourself.

If the thing slowing you down is that your agents live on different machines or under different accounts and none of them know what the others learned, or you want memory to be a file you can grep, put in git, and walk away with rather than an account you rent, then that's the gap Bourdon is built to close, and recognition-first retrieval is the bet that makes the shared copy feel instant instead of like a lookup.

Both are still moving fast. Read the docs, not just this post, before you commit a fleet to either one.

Try it

Bourdon is free and self-hosted:

pip install bourdon && bourdon setup

Start at bourdon.ai, or read Mem0's docs at docs.mem0.ai and decide for your own fleet. If you think we got something about either tool wrong, we'd like to hear it: tell us.