AutoMem: a graph plus vector memory service for AI assistants

The problem: context that dies with the chat window

Assistants forget. A decision made in one session, the alternatives weighed, the principle behind the choice, all of it disappears when the window closes, and the next session starts from nothing. AutoMem targets exactly that gap. Its README frames the product as a memory that survives the chat, so the next time you open Claude, Cursor, Codex, ChatGPT, or another connected assistant, it can bring back the right details instead of making you repeat yourself. The intended user is someone running an assistant across more than one client and wanting the same stored context available in each. The README's own example query is "Why did we choose PostgreSQL?" and the promise is that recall returns the decision, the alternatives considered, the principle behind it, and the work that followed, rather than a pile of similarly worded snippets. That distinction, why versus what, is the whole reason a graph sits next to a vector index here.

Two stores, one API: how the graph and vector layers split the work

The architecture is a Flask service in front of two databases. FalkorDB stores memories as nodes with 11 typed relationships between them, and the README calls the graph the canonical record. Qdrant stores an embedding for every memory. Recall is described as a hybrid query combining semantic similarity, graph traversal, temporal alignment, tag overlap, and importance, ranked by a 9-component score. The README also states plainly that no LLM call sits in the middle of recall: AutoMem looks up memories directly through the graph and vector index, which keeps normal retrieval fast and avoids an extra generative-LLM charge per context fetch. Embeddings still come from Voyage, OpenAI, or a local provider, and the diagram labels the vectors as 1024-d. The multi-hop bridge example is the clearest illustration of what the graph adds. Ask "why boring tech for Kafka?" and a seed memory about migrating to PostgreSQL for operational simplicity plus a seed about evaluating Kafka versus RabbitMQ both carry an EXEMPLIFIES edge to a bridge memory about preferring boring technology. AutoMem ranks the bridge above the seeds and returns it, so the assistant answers with the reasoning rather than isolated facts. A pure vector search would have matched the word Kafka and stopped there.

The 11 edge types are the actual data model

Most memory tools expose one relation: this chunk is near that chunk. AutoMem makes the relation type part of the schema, and the README lists eleven authorable ones with use cases. RELATES_TO is a general connection; LEADS_TO is causal; OCCURRED_BEFORE is temporal; PREFERS_OVER captures user preferences such as PostgreSQL over MongoDB; EXEMPLIFIES links an example to a pattern; CONTRADICTS marks conflicting information; REINFORCES marks supporting evidence; INVALIDATED_BY marks outdated material; EVOLVED_INTO tracks knowledge evolution from initial design to final design; DERIVED_FROM tracks provenance from implementation back to spec; PART_OF is hierarchical, feature to epic. Three further types, SIMILAR_TO, PRECEDED_BY, and DISCOVERED, are added automatically by the enrichment pipeline and the consolidation engine rather than authored by hand. This is the part of the design that asks something of you. Someone or something has to decide that a new memory CONTRADICTS an old one or that a decision EVOLVED_INTO a later one. The README points to an enrichment pipeline that adds structure over time, but it does not describe how conflicts are detected, so treat the automatic enrichment as an area to inspect in docs/API.md rather than assume.

Getting it running: Docker, Railway, or your own infrastructure

The README offers three deployment shapes: run AutoMem locally with Docker, on your own infrastructure, or as a small Railway service group, and there is a Deploy on Railway badge in the header. Clients connect two ways. A local MCP bridge, published on npm as @verygoodplugins/mcp-automem, covers Claude Desktop, Cursor, Claude Code, Codex, and Copilot. Remote MCP connects the same service over HTTPS to ChatGPT Developer Mode, Claude.ai, and ElevenLabs for cloud agents. Alongside MCP there is a REST API for the memory lifecycle, with endpoints named in the README such as GET /recall and operations described as Store, Recall, and Associate in the diagram. Recall tuning is done with three query parameters on GET /recall: expand_relations, relation_limit, and expansion_limit. Those control how far the graph walk goes from the seed memories and how many related nodes come back. The README does not print a full docker compose file or the environment variables for database hosts and embedding keys in the material available here, so verify those against the repository before you plan a deployment.

Degraded mode when Qdrant is down, hard failure when FalkorDB is

The failure behaviour is stated directly and it is asymmetric. If Qdrant is unavailable, the graph still serves recall in a degraded mode. If FalkorDB is down, the API returns 503, because the graph is the source of truth. That is a defensible choice, but it means your availability floor is FalkorDB's availability, and Qdrant is the component you can lose without an outage. The second real constraint is operational surface. You are running two databases plus a Flask service, and the README lists automated backups as optional, wired to both stores. Optional backups on a canonical graph store is a gap worth closing yourself. The third is the wrong-tool case: if your need is a single-user assistant on one machine with a short history, a two-database service group is more moving parts than the problem justifies. AutoMem earns its complexity when history grows long enough that retrieval precision, not storage, is the bottleneck.

How it differs from a plain RAG stack over a vector database

The obvious alternative is a vector store alone, for example Qdrant by itself with a chunking pipeline, which is what most retrieval-augmented setups do. The difference is in what gets indexed. A vector-only stack embeds text and returns the nearest neighbours; it has no representation of the fact that one memory invalidated another or that a decision derived from a spec. AutoMem keeps the graph as the canonical record and treats the vector index as one input to a composite ranking, which is why the README can claim recall returns the why and not just the words. The cost of that difference is schema discipline. With a plain vector store you can dump text in and move on. With AutoMem, the value comes from the typed edges being populated, and the README's own framing of the graph as source of truth means an under-linked graph degrades toward ordinary semantic search while still requiring two databases to operate. If your corpus is flat notes with no decisions, preferences, or causal chains in it, the graph layer has little to attach to and the simpler stack wins.

Benchmarks and what the published numbers do and do not cover

The README reports 57.4% on BEAM 10M long-context tests on the independent Agent Memory Benchmark, while giving the answerer an average of roughly 2.6 to 4.8k retrieved tokens. It also cites 85.1% on LoCoMo (AMB) and 87.0% on LongMemEval full, and the badge for LongMemEval explicitly notes that run used AutoMem's internal harness, while the LoCoMo and BEAM badges point to the neutral benchmark. That distinction matters when you compare numbers: one figure comes from the project's own setup, and the README says the full picture, including test setup, raw outputs, methodology, historical runs, and reproduction commands, lives at automem.ai/benchmarks and in benchmarks/EXPERIMENT_LOG.md. The token-efficiency claim is the more interesting one for capacity planning, because it describes how much context the answerer receives rather than only whether the answer was right. None of these figures tell you how the system behaves on your data, and the README does not report latency numbers, so benchmark your own recall queries through GET /recall before sizing anything.

Licence, maintenance cadence, and upgrade cost

AutoMem is MIT licensed, which permits commercial use and modification with the licence and copyright notice retained; that is a statement about the licence text, not legal advice, so read LICENSE and your own obligations. Maintenance looks active on the evidence given: the default branch is develop, the last push is dated 2026-09-10, and the release list shows v0.16.0 in June 2026, v0.16.1 in July, and v0.16.2 in August, a steady minor cadence rather than a frozen project. The upgrade cost that follows from the architecture is schema and data migration across two stores. A change to edge types, to the enrichment pipeline, or to the 1024-d embedding configuration can require touching both FalkorDB and Qdrant, and the README lists backups as optional, so a rollback path is something you build rather than inherit. Pin the npm bridge package @verygoodplugins/mcp-automem and the service version together, and read the release notes for each minor bump before upgrading a running deployment, since pre-1.0 versioning signals that interfaces can still move.

Editorial conclusion

Adopt AutoMem if you already run Docker or a small hosted service group and you want assistant memory that is not tied to one chat client, with the graph as the canonical record. Do not adopt it if you cannot operate FalkorDB and Qdrant together, because the README states the API returns 503 when FalkorDB is down. Before committing, verify two things yourself: that your embedding provider (Voyage, OpenAI, or a local one) is reachable from the deployment, and that the 1024-d vector configuration matches whatever Qdrant collection you provision, since the diagram fixes that dimension.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. verygoodplugins/automem on GitHub