flmnt → compare
Most of these tools are good at recall. That isn't the problem we work on.
If your agents forget things, several of the tools below will fix that, and some of them are free. Read this page if your problem is different: your agents remember confidently, and sometimes what they remember is the version you replaced.
Every row is a question an evaluator actually asks. Where a competitor is better, it says so.
Line by line
The comparison, including the alternative most teams are actually using.
That alternative is a committed context file plus the discipline to maintain it. It is free, deterministic, diffed in git, and it is what you are really choosing between.
| Question | flmnt | CLAUDE.md | Mem0 | Zep | Cognee | Byterover | Letta | DIY RAG |
|---|---|---|---|---|---|---|---|---|
| What is the unit — one developer, or a team? | the teamOne shared record, one version each. | the repoGenuinely shared. | the userUser, session and agent ids. | the end userFor personalizing an app. | the projectShared graph in API mode. | the dev teamShares coding memories across a team. | the agentShared blocks exist for multi-agent setups. | yoursUsually starts per-user. |
| When a decision is replaced, what happens to the old one? | retiredReadable, never served. The link records what replaced what. | you edit itCorrect if someone remembers. | accumulatesExtraction is add-only. | invalidatedSuperseded facts kept as history, removed from current state. | prunedStale nodes pruned, not retired with reasons. | accumulatesSharing a pile, not agreeing a version. | overwrittenThe agent edits the block in place. | you build itThe hard part, and it's on you. |
| With no textual tell, does it still serve the current one? | yes, measuredEvery time, on a public benchmark. | yesOnly one version exists in the file. | noClosest match may be the retired one. | untestedEdges exist; benchmarks don't score it. | untestedNot a published result. | noRetrieval by relevance. | dependsOn whether the agent rewrote the block. | noNot without building this. |
| Does the reasoning travel with the decision? | part of the entryWhy it was decided, and why the last one stopped. | if you write itADRs do this well. | facts onlyRationale lost in extraction. | in relationsIntent isn't first-class. | in the graphStructure over intent. | sometimesCaptures reasoning steps, not decisions. | in the blockWhatever the agent kept. | yours |
| What's the upkeep once it's running? | noneCaptured as decisions are made. | continuousRead-only to the agent; nothing returns to the file. | noneFully managed. | noneManaged service. | someYou run the pipeline. | noneZero-config MCP server. | you run itSelf-host or their cloud. | substantialStore, reranking, evals, on-call. |
| Does it sit behind the coding agent I already run? | MCP + SDKMCP to adopt it with no rewrite; a public SDK if you're building your own product. | nativelyRead at session start. | SDK + MCPBroad integration surface. | MCPGraphiti MCP server, used behind Claude and Cursor. | MCPBuilt for Cursor and Claude Code. | MCPWide IDE coverage. | it is the stackAgents run inside Letta, not behind it. | you wire it |
| Can you show what was true when, and who acted on it? | append-onlyNever edited. Reads recorded too. | git historyHonestly good, if kept current. | audit logsRead and write logging on enterprise. | bi-temporalFour timestamps per edge; facts trace to source episodes. | mutable graphRefined in place. | no trailNot its purpose. | mutable blocksRewritten in place. | yours |
| What does remembering cost as the project grows? | flatBudget-bounded retrieval. | growsSent every session; measurable added cost. | boundedA few relevant facts. | boundedGraph retrieval. | boundedToken-budgeted context. | boundedToken budgeting. | boundedTiered context, paged by the runtime. | dependsOn your tuning. |
Why teams choose us
Four things in that table only one column does.
Recall is solved, and several tools above do it well. These are the places where the row above is ours alone.
The unit is a decision your team made
not a fact about a user
Everything else here models facts, sessions, or an agent's own state. We model the decision — with its author, its reasoning, and what it replaced. That is the thing your team actually disagrees about.
Currency, measured where it's hard
no textual tell
When a replacement never says "instead of", similarity search serves the retired decision every time. We serve the current one every time, and the benchmark and method are public.
A decision arrives as a path
history, position, trajectory
Not a point to match, but where it started, where it stands and which way the team has moved. An agent given the path can tell when a proposal argues against the direction of travel. The chain →
Append-only, and it shows its work
governed context
Nothing edited, nothing deleted, reads recorded as well as writes. Retired decisions are readable but never served — a boundary on what any agent may act on, and one you can put in front of an auditor.
Nothing to maintain
and nothing to migrate
Decisions are captured as they're made. It sits behind the agents your team already runs over MCP, with a public SDK if you're building your own product. No rewrite, no file to babysit.
You can see who is actually working from it
reads, not just writes
The chain records every read. So "is the whole team on the current version?" is a list, not an investigation — and an agent that hasn't picked up a change is visible before it builds on the old answer, not at review. Coverage →
Where we'd tell you not to botherA one-off script, a weekend project, or anything that fits comfortably in one context window. Below that size the upkeep you'd be replacing costs less than the tool, and we'd rather say so here than have you find out.
On composing tools over MCPAnything on this page can be composed with anything else over MCP, and engineers building a harness will do exactly that. That is not the argument for us. The argument is that whatever you compose, every layer of it reads from one record — so the record is the part that has to be right. Ours happens to also drive domain modeling, design verification and specification if you want them. The workflow →