AI memory: Mem0 and Cognee

The agents of Navin Enterprise can keep a memory beyond one conversation. Three engines are available: the Memory Manager built into the Control Plane (brick E), Mem0 for the persistent memory of facts and Cognee for the memory as a knowledge graph (GraphRAG). The decisions are in ADR-0174.

What the two engines are for

Engine	Catalog version	Licence	What it brings
Mem0 (mem0)	2.2.1	Apache-2.0	official REST server that extracts the facts of conversations with the LLM, stores them with their embedding in PostgreSQL (pgvector) per user, agent or run, and answers semantic searches, updates, histories and deletions
Cognee (cognee)	1.6.6	Apache-2.0	ingestion of documents and texts (add), extraction of entities and relations by the LLM into a graph (cognify), semantic, graph and GraphRAG searches; one LadybugDB graph file and one pgvector schema per dataset

Both engines call the LLM and the embedding model through the LiteLLM gateway of the platform. They are never installed by default: an administrator adds them from the catalog of the Manager, category "AI memory".

Two planes

Who	Does what	Does not
Navin Manager and its agents	catalog, preflight checks, artefacts, installation, technical configuration, start and stop, upgrades and migrations, backups, monitoring	no choice of engine per agent, no memorization policy
Navin Enterprise (Control Plane and portal)	choice of the engine per agent, memorization and retention policies, rights, browsing and management of the authorized memories, use at run time	no system command; it reaches the engines through their REST API behind the Navin Memory Provider contract

The address and the key of each engine reach Navin Enterprise through the optional bindings mem0 and cognee of the navin-enterprise service of the catalog (settings EAI_MEMORY_MEM0_URL, EAI_MEMORY_COGNEE_URL, EAI_MEMORY_COGNEE_ACCESS_CONTROL and EAI_MEMORY_ENGINES_CA_FILE, keys in the sensitive environment file).

The providers

Provider	Engine	Announced capabilities
builtin	Memory Manager of brick E, unchanged, default provider	remember, recall, search, update, forget, list, get, purge, get_health, get_capabilities
mem0	Mem0 server installed by the Manager	the same memory capabilities as builtin
cognee	Cognee API installed by the Manager	forget, list, purge, get_health, get_capabilities, ingest_knowledge, build_graph, search_graph, get_relations, delete_dataset
hybrid	Mem0 for the facts, Cognee for the knowledge and the relations	recall merged and deduplicated by Navin

A provider announces only what it really executes; any other operation is refused with the error memory_capability_unsupported (HTTP 422), with no silent switch to another engine.

Which engine to choose

• builtin: the default choice. Session memory always stays here, whatever the engine of the agent. It guarantees the separation of tenants with the row level security of PostgreSQL.
• mem0: an agent that must remember the facts and preferences of a user over time, with a history of the changes.
• cognee: an agent that reasons over a corpus of documents and over the relations between entities (people, teams, places).
• hybrid: an agent that needs both; each write goes to one engine only (memories to Mem0, knowledge to Cognee) and a recall queries both.

A policy that requires a dedicated_instance isolation (banking case) needs an instance installed by the Manager for this tenant only. See Security and isolation.

Pages of the guide

Page	Content
Installation with the Manager	prerequisites, reused dependencies, dedicated PostgreSQL database, models, methods, offline, preflight checks, functional test
Operations	start, stop, health, upgrade, rollback, backup, retention, monitoring
Security and isolation	authentication, telemetry, secrets, scope mapping, isolation, OpenFGA, audit, untrusted memories
Integration	Navin Memory Provider contract, routes /v1/memory, agent memory policy, hybrid mode
High availability and limits	real topologies, limits, what was verified
Generated catalog pages	mem0, cognee