ADR-0174 : Mémoire des agents IA : Mem0 et Cognee installés par le Navin Manager, contrat Navin Memory Provider

• Statut : accepté
• Date : 2026-11-03
• Portée : catalogue du Navin Manager (navin-manager/catalog/services/mem0.yaml, cognee.yaml et leurs modèles), interface du Manager (logos, cartes du catalogue, consoles), Memory Manager du Control Plane (services/control-plane/src/eai/domains/memory), contrats contracts/v1/memory-*.schema.json, portail Enterprise
• Documents liés : ADR-0101 (politique de licences), ADR-0166 (haute disponibilité déclarée par service), ADR-0171 (installation durcie pour la production bancaire), brique E (Memory Manager)

Contexte

Le client demande deux moteurs de mémoire open source pour les agents IA : Mem0, mémoire persistante, et Cognee, mémoire enrichie par un graphe de connaissances (GraphRAG). Ils doivent s'installer sur ses serveurs, y compris privés, isolés d'Internet ou répartis sur plusieurs machines, puis servir aux agents de Navin Enterprise.

L'existant :

• Le Control Plane a déjà un Memory Manager (brique E) : éléments du Memory Contract avec ACL, durée de vie, conservation légale, versions, recherche hybride et classification, portées session, agent, user, project et tenant (eai/domains/memory, contracts/v1/memory-contract.schema.json, migrations V062 et V101). Ses vecteurs passent par la passerelle de modèles.
• Le catalogue du Manager installe déjà PostgreSQL (pgvector selon la méthode), Qdrant, Redis, LiteLLM, vLLM, Ollama, Keycloak, OpenFGA, OPA, OpenBao, Prometheus, Alertmanager, Alloy, OpenSearch, le collecteur OpenTelemetry, NATS et SeaweedFS. Il n'a ni Mem0 ni Cognee.

Sources officielles relevées le 2026-11-03 :

Produit	Version stable	Licence	Livraison amont
Mem0 (mem0ai/mem0)	v2.2.1 (2026-09-25)	Apache-2.0	serveur REST FastAPI (server/) avec authentification, migrations alembic, limites de débit et dashboard Next.js (server/dashboard) ; l'image Docker Hub mem0/mem0-api-server n'a qu'une étiquette latest de 2025, antérieure à la v2, et le dashboard n'a pas d'image publiée
Cognee (topoteretes/cognee)	v1.6.6 (2026-10-29)	Apache-2.0	moteur et API FastAPI (/api/v1), images cognee/cognee, cognee/cognee-ui et cognee/cognee-mcp, paquet Python cognee
LadybugDB (LadybugDB/ladybug)	v0.22.1 (2026-10-28)	MIT	base de graphe embarquée, issue de Kuzu

Décision

1. Deux plans, des interfaces explicites

Qui	Fait quoi	Par quoi
Navin Manager	catalogue, préflight, artefacts, installation, configuration technique, démarrage et arrêt, mises à jour et migrations, rollback, sauvegardes, supervision, HA quand elle existe	agents Navin, méthodes podman et python existantes, unités systemd du Manager
Navin Enterprise	choix du moteur par agent, politiques de mémorisation et de rétention, droits, consultation et gestion des mémoires autorisées, utilisation à l'exécution	API REST officielles de Mem0 et de Cognee derrière le contrat Navin Memory Provider

Il n'y a pas de second système de déploiement ni de Docker : les fichiers Compose amont servent seulement de référence pour écrire le déploiement Podman.

2. Services du catalogue

Service	Sous-catégorie	Composants	Méthodes
mem0	mémoire persistante des agents	serveur REST, dashboard en suiveur facultatif	python (environnement virtuel, source officielle de la version épinglée), podman seulement avec une image de cette version épinglée par digest
cognee	graphe de connaissances et GraphRAG	API, UI et serveur MCP en suiveurs facultatifs	podman (images officielles épinglées par digest), python quand il suit les conventions des services Python du catalogue

Le catalogue reçoit la catégorie memory (« Mémoire IA ») et un champ facultatif subcategory affiché sur les cartes.

3. Dépendances réutilisées, jamais installées d'office

• PostgreSQL existant : une base dédiée et un rôle technique à privilèges minimaux par service, avec l'extension vector.
• Modèles par LiteLLM (compatible OpenAI), vLLM ou Ollama du catalogue. Aucun modèle n'est téléchargé au démarrage.
• Une dépendance facultative n'est jamais installée automatiquement. Une version incompatible est refusée avec sa cause, en français et en anglais.
• Grafana et Loki ne sont pas utilisables (AGPL-3.0, ADR-0101). La supervision passe par Prometheus, Alertmanager, Alloy, OpenSearch et OpenTelemetry.
• Neo4j n'est jamais installé. La mémoire graphe de Mem0 reste désactivée tant qu'aucun backend sous licence autorisée n'est validé.

4. Profils de Cognee

• Standard : PostgreSQL relationnel, pgvector et LadybugDB embarqué sur un volume persistant, en mono-instance.
• Avancé : un backend de graphe externe seulement s'il est pris en charge par la version retenue, sous une licence autorisée, avec une isolation des tenants validée par un test.
• Le backend de graphe PostgreSQL n'est jamais présenté comme prêt pour la production bancaire tant que le projet le décrit comme expérimental.
• L'authentification et le contrôle d'accès par tenant sont actifs en production. Aucun utilisateur par défaut ne garde un mot de passe connu.

5. Artefacts

• Images épinglées par digest, archives et wheels par SHA-256, portées par le hub et le bundle hors ligne existants. Aucune étiquette latest, main ou de développement.
• Les artefacts de la version précédente restent disponibles pour le rollback.

6. Cycle de vie et validation

• L'état healthy exige les contrôles de santé et un test fonctionnel réel (smoke). Mem0 crée, recherche, modifie puis supprime une mémoire dans un espace de test. Cognee crée un dataset, ajoute des éléments, construit le graphe, cherche, puis nettoie.
• Mise à jour : sauvegarde, puis migrations alembic du produit. Le rollback restaure la sauvegarde et les artefacts précédents.
• Sauvegarde : pg_dump des bases dédiées et copie cohérente des fichiers LadybugDB et du répertoire de données (service arrêté ou point de contrôle).
• Les télémétries externes sont coupées (MEM0_TELEMETRY=false, télémétrie de Cognee désactivée).

7. Haute disponibilité

Elle est déclarée par service (ADR-0166) d'après le code réel de la version installée :

• Mem0 n'est réplicable que si tout son état est dans PostgreSQL ; sinon il reste mono-instance.
• Cognee, profil standard : mono-instance, car sa base de graphe est embarquée.
• Aucune capacité ni aucune HA n'est annoncée sans test.

8. Contrat Navin Memory Provider

Il est construit sur la brique E, sans la dupliquer :

• capacités déclaratives : remember, recall, search, update, forget, list, get, purge, get_health, get_capabilities, et pour Cognee ingest_knowledge, build_graph, search_graph, get_relations, delete_dataset ; un fournisseur n'annonce que ce qu'il exécute vraiment ;
• fournisseurs : builtin (la brique E, inchangée), mem0, cognee et hybrid (Mem0 pour les faits, Cognee pour les relations, fusion et déduplication par Navin) ;
• modes : mémoire de session (mécanismes existants, jamais Mem0 ou Cognee pour chaque message), long terme, agent, partagée et graphe ; la mémorisation suit des politiques explicites et n'écrit jamais toutes les conversations dans les deux moteurs ;
• seuls les endpoints réels des versions épinglées sont appelés.

9. Isolation et gouvernance

• Le contexte (tenant, organisation, projet, utilisateur, agent, session, portée) est dérivé de l'identité validée par le serveur, jamais des paramètres envoyés par un agent. Une correspondance contrôlée le traduit en identifiants des moteurs. Quand un moteur ne garantit pas la séparation exigée, une instance dédiée est requise (banque).
• OpenFGA pour les autorisations, OPA pour les politiques, OpenBao pour les secrets, OpenTelemetry pour la trace. Chaque opération sensible produit un événement d'audit sans le contenu des mémoires.
• Les mémoires restituées sont des données non fiables, jamais des instructions. Les permissions sont contrôlées avant toute restitution au LLM. Les secrets, mots de passe, jetons et clés ne sont jamais mémorisés.

10. Interfaces

Le dashboard de Mem0 et l'UI de Cognee s'ouvrent depuis le Manager par le registre des consoles et son accès sécurisé. Une iframe n'est utilisée que si leur propre sécurité le permet. Leur authentification n'est jamais désactivée.

Conséquences

• Les agents de Navin Enterprise choisissent builtin, mem0, cognee ou hybrid sans dépendre des particularités des moteurs.
• L'exploitation (sauvegarde, migration, rollback, supervision) suit les mêmes chemins que les autres services du catalogue.
• Tant que Mem0 ne publie pas d'image versionnée, sa méthode Podman dépend d'une image construite depuis la source officielle de la version et épinglée par digest.

Alternatives écartées

• Image mem0/mem0-api-server:latest : non figée et antérieure à la v2.
• Docker Compose amont en production : second moteur d'exploitation.
• Neo4j installé d'office : licence hors de la politique de la plateforme.
• Grafana et Loki : AGPL-3.0.
• Écrire toutes les conversations dans les deux moteurs : coût, risque de fuite et bruit.
• Remplacer la brique E : elle reste le fournisseur par défaut.