// the find
topoteretes/cognee
Cognee is the open-source AI memory platform for agents. Give your AI agents persistent long-term memory across sessions with a self-hosted knowledge graph engine.
Cognee is a Python library that gives AI agents a persistent memory layer by combining vector embeddings with a knowledge graph — documents get ingested, LLM-extracted relationships are stored as graph edges, and queries can hit either the vector index or the graph depending on the question. The four-operation API (remember/recall/forget/improve) is the right abstraction level for most agent use cases. Aimed at developers building multi-session agents who need something more structured than a plain vector store.
The dual-layer approach (fast session cache backed by a persistent knowledge graph) is architecturally correct — pure vector stores lose relational structure, pure graphs lose semantic fuzzy search, and combining both is the right call for retrieval quality. The `remember/recall/forget` API is clean; it hides the underlying pipeline complexity without forcing you to think about which search strategy to use on every query. Multi-tenant isolation is built in at the data layer, not bolted on — each user/tenant gets isolated graph and vector spaces, which matters for any production agent serving multiple accounts. Backend flexibility is real and not just marketing: the storage layer has adapters for Neo4j, pgvector, Weaviate, and others, and the CI workflow has separate test jobs per adapter rather than one happy-path test that only validates the default.
The 'cognify' step — where it runs LLM calls to extract entity relationships from every ingested document — is expensive and can be slow on large corpora; the docs don't give you good guidance on cost estimation before you commit to ingesting a serious dataset. Ontology generation via LLM means hallucinated or inconsistent entity relationships will end up in your graph with no easy way to audit or clean them out after the fact — the 'improve' operation sounds like it addresses this but the behavior is underspecified. The extensive list of storage backend adapters is a maintenance surface, and backends that aren't the primary Neo4j/pgvector path likely have more edge case bugs. Self-hosted production deployment docs are thin — the README funnels you toward Cognee Cloud pretty quickly, and the 'distributed/' folder is the extent of self-host guidance for anything beyond a single container.