MemoryBear: a graph-first memory layer for AI agents, reviewed

The problem MemoryBear targets: memory that outlives one context window

The README frames the problem in three parts. First, single models forget: context windows of 8k to 32k tokens push early messages out, training data is a static snapshot, and self-attention overweights recent input. Second, multi-agent setups fragment: consulting, after-sales and recommendation agents keep isolated memories, so users repeat themselves and agents can contradict each other, with the README's own example being a recommendation for a product the user is allergic to. Third, semantics drift: jargon, colloquialisms and cross-language references get encoded loosely.

That framing tells you who this is for. It is not a library you drop into a notebook. It is infrastructure for teams shipping assistant products where the same user meets several agents over weeks, and where a wrong memory has a business cost. The repository layout matches that ambition: gateway-service, identity-service, mem-knowledge, sandbox and web sit side by side, which is a platform, not a package.

How MemoryBear works: extract, store in Neo4j, retrieve with two engines, then forget

The pipeline the README describes has four stages. Perception and extraction parse unstructured conversations and documents into core declarative statements and structured triples, for example MemoryBear to core function to knowledge extraction, with timestamps attached for time-based tracing. Storage is graph-first: extracted triples sync into Neo4j, which the README says covers 12 relationship types including hierarchical, causal, temporal and logical, and which it sizes at millions of entities and tens of millions of edges.

Retrieval is a fusion of two engines. Elasticsearch handles keyword matching, described as millisecond-level exact matching of structured information, while BERT embeddings handle semantic vector search for synonyms and implicit intent. The README describes the order as semantic retrieval widening the candidate set, then keyword retrieval filtering it precisely, and states 92% retrieval accuracy, 35% above single-mode retrieval. Those numbers come from the project's own documentation, not from independent measurement, and the README does not describe the evaluation set behind them.

The forgetting engine is the part with the most distinctive design. Each knowledge item gets an initial strength that usage frequency and association activity update, and when strength drops below a threshold the item moves through dormancy, decay and clearance. The README states redundant knowledge is maintained below 8% and waste is reduced by over 60% compared with systems without forgetting. A scheduled daily reflection pass then checks consistency across related knowledge, scores value by invocation frequency and association contribution, and adjusts relationship weights. Treat the percentages as design targets published by the project rather than as results you can assume on your own corpus.

Installing MemoryBear and running a first extraction

The README points to a Quick Start and Installation section, and the repository ships a .env.example that the README says holds shared infrastructure configuration, with service-specific values belonging in each service's own .env file. Start by copying it and setting the community deployment mode plus the datastore endpoints.

cp .env.example .env

The file opens with the deployment mode, then PostgreSQL, Redis and Celery, Elasticsearch, storage and model runtime blocks. The defaults assume everything runs on localhost, so a single-machine setup needs no host changes, only credentials:

DEPLOYMENT_MODE=community
DB_HOST=127.0.0.1
DB_PORT=5432
DB_USER=postgres
DB_PASSWORD=change-me
DB_NAME=redbear-mem
REDIS_HOST=127.0.0.1
REDIS_PORT=6379
REDIS_DB=1

Elasticsearch defaults to HTTPS on port 9200 with certificate verification off, which is convenient locally and something to revisit before any shared deployment:

ELASTICSEARCH_HOST=https://127.0.0.1
ELASTICSEARCH_PORT=9200
ELASTICSEARCH_USERNAME=elastic
ELASTICSEARCH_VERIFY_CERTS=false

Storage is selected with STORAGE_TYPE, whose documented values are local, oss, s3 or minio. The model runtime is configured through SPEEDBEAR_BASE_URL, which the example points at https://testspeedbear.redbearai.com, and SPEEDBEAR_AUTH_KEY, which is empty and must be filled before extraction can call a model. The README does not give the exact command that starts the FastAPI services, so check the Quick Start section for the current entry points rather than guessing one.

The operational cost the README does not hide

MemoryBear is honest about its dependencies and they are heavy. A working install wants PostgreSQL for relational state, Redis with separate logical databases for the Celery broker and backend, Elasticsearch for keyword retrieval, Neo4j for the graph, and a reachable model endpoint. That is five moving parts before a single memory is written. For a team already running this stack, the marginal cost is configuration. For anyone else, the first day is infrastructure work.

The forgetting engine is the second source of friction, and it is a genuine trade-off rather than a defect. Automatic decay means answers change over time even when the underlying conversation does not. A memory that was correct last month may be dormant this month because nobody referenced it. The README exposes strength, thresholds and the three-stage lifecycle as concepts, but it does not document how to pin a memory so it never decays, nor how to inspect why a specific item was cleared. If your product needs auditable, immutable memory, this design fights you.

There is also a licensing boundary to read carefully. The repository is Apache-2.0, but the example configuration points SPEEDBEAR_BASE_URL at a hosted endpoint and includes an internal LiteSkill admin interface with its own token. The licence covers the code in the repository; it says nothing about the terms of the hosted model service those variables reach. That is a question for your own legal review, not something the README settles.

MemoryBear compared with a plain vector store

The obvious alternative is a vector database plus an embedding model, which is what most teams reach for first. The difference in approach is structural. A vector store keeps chunks and returns the nearest ones by cosine similarity; it has no notion of a relationship between two facts, no timestamp semantics beyond metadata you add yourself, and no decay. MemoryBear stores triples in Neo4j so that a question can traverse causal or temporal edges, and it runs two retrieval engines instead of one.

That buys you the multi-agent case the README describes, where a shared graph lets a recommendation agent see what the after-sales agent learned. It costs you the graph database. If your memory is a document corpus with a search box on top, a vector store is smaller, faster to operate and easier to reason about, and MemoryBear's forgetting engine would be an unwanted source of nondeterminism. The honest split is: pick MemoryBear when relationships between facts matter and memories should age; pick a vector store when they do not.

Release cadence, upgrade cost and licence implications

The project is active. The last push to the default branch was on 2026-09-20, and the release notes show v0.4.6 on 2026-09-18, v0.4.5 on 2026-09-11 and v0.4.4 on 2026-09-06, which is roughly a release a week at the 0.4 line. Fast iteration at that pace cuts both ways: fixes arrive quickly, and the shape of the extraction and reflection engines can change between minor versions. The release titles themselves, from Trace Every Path through Forged Foundations to Insight, Crystallized, suggest feature-level changes rather than patch-only drops.

Upgrade cost is dominated by schema and configuration rather than by code you write. A new release can add keys to .env.example, and because service-specific values live in each service's own .env file, a key added to the shared file is not automatically present where a service reads it. Diff .env.example against your own files on every upgrade. The README does not document a rollback procedure or a data migration path for the Neo4j graph, so plan to snapshot the graph and the PostgreSQL database before pulling a new tag.

On licensing, Apache-2.0 permits commercial use and modification and requires that you keep the licence and notice files. It grants no rights to the hosted model endpoint referenced in the configuration, and the LiteSkill internal admin token in the example is an integration detail, not a licensed component. Confirm with your own counsel how the hosted service is governed before you depend on it in production.

Editorial conclusion

Adopt MemoryBear if you run several agents that must share one evolving memory and you already operate PostgreSQL, Redis, Elasticsearch and Neo4j, since the repository assumes all four. Do not adopt it for a single-chatbot prototype, where a vector store plus a prompt is cheaper to run, or if you need a documented rollback path, because the README does not describe one. Before committing, check the two API surfaces the README lists, confirm which one the community DEPLOYMENT_MODE exposes, and read the community release notes for v0.4.6 to see what changed in the extraction and reflection engines.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. SuanmoSuanyangTechnology/MemoryBear on GitHub