Pourquoi les agents IA ont besoin de 4 couches de mémoire (et pas d’une seule)

Neto Pompeu with Koda —

Pourquoi les agents IA ont besoin de 4 couches de mémoire (et pas d’une seule)

Et comment nous avons créé une solution 100 % locale et gratuite

---

Le problème dont personne ne parle

Votre agent IA oublie tout.

Chaque conversation, chaque décision et chaque leçon difficilement apprise disparaissent dès que le contexte est compacté. Vous payez 200 $ par mois pour un agent incapable de se souvenir de ce que vous lui avez dit hier.

Je le sais parce que je l’ai vécu. Je dirige un studio de développement web en Guyane française, avec trois agents IA qui travaillent quotidiennement à mes côtés. Lorsque Lossless Claw, de Martian Engineering, est sorti, cela a été une véritable avancée : la compaction permettait enfin de préserver le contexte. Mais je me suis rapidement heurté au même problème : la compaction préserve le texte, pas la connaissance.

Un agent peut se rappeler que vous avez parlé d’un bug. Mais peut-il relier ce bug à la correction appliquée deux semaines plus tard ? Peut-il détecter qu’une nouvelle information contredit ce qu’il « sait » déjà ? Peut-il retrouver ce fait pertinent enfoui dans 3 000 lignes d’historique ?

Non. Pas avec une seule couche de mémoire.

---

Pourquoi une seule source de mémoire ne suffit pas

Imaginons que vous recherchiez « problèmes de déploiement ». Voici ce que chaque type de mémoire peut trouver :

| Type de mémoire | Ce qu’il trouve | Ce qu’il peut manquer | |---|---|---| | Base de faits | « Le déploiement Vercel échoue lorsque les variables d’environnement manquent » | Le fait peut être ignoré si les mêmes mots ne sont pas utilisés | | Embeddings vectoriels | Des passages sémantiquement proches parlant de problèmes de déploiement | Les termes techniques exacts peuvent manquer | | Recherche plein texte | Les correspondances exactes pour « deployment » | « deploy », « mise en production » ou « publier » peuvent ne pas apparaître | | Graphe de connaissances | « Vercel → dépend de → variables d’environnement → provoquent → échec du déploiement » | Une extraction structurée est nécessaire au préalable |

Chaque source est aveugle là où les autres voient. La solution n’est pas de trouver une meilleure source unique, mais d’utiliser les quatre en parallèle.

---

L’architecture : 4 couches, une seule requête

Voici ce qui se passe lorsque vous posez une question à Agent Memory Tools :

``` Votre question │ ▼ ┌─────────────────────────────┐ │ unified_recall │ │ (requêtes parallèles) │ ├─────────┬──────┬──────┬─────┤ │ Faits │Vector│ BM25 │Graphe │ │Embed │ FTS │ │ ├─────────┴──────┴──────┴─────┤ │ Fusion → Score → Reclassement │ (pondération + déduplication) ├─────────────────────────────┤ │ Synthèse par le LLM │ │ (réponse sourcée, ~3 s) │ └─────────────────────────────┘ ```

Couche 1 : base de faits — Des faits structurés et classés par catégories : connaissances, erreurs, chronologie, préférences et outils. Chaque fait possède un niveau de confiance et fait l’objet d’une détection de contradiction. Si vous enregistrez « Next.js 15 utilise Turbopack par défaut », puis plus tard « Next.js 15 utilise Webpack par défaut », le système le détecte.

Couche 2 : embeddings vectoriels — Une recherche sémantique grâce à nomic-embed-text-v2-moe, exécutée localement avec Ollama. Les 768 dimensions sont calculées sans aucun coût d’API. Le système retrouve un contenu pertinent même lorsque vous employez des mots complètement différents.

Couche 3 : BM25 / recherche plein texte — Une recherche classique par mots-clés. Lorsque vous avez besoin de retrouver un terme technique exact, un nom de fonction ou un code d’erreur, c’est cette couche qui intervient. Elle complète parfaitement la recherche vectorielle.

Couche 4 : graphe de connaissances — Des entités et leurs relations sont extraites automatiquement : « application Bureau → utilise → backend Convex → déployé sur → Vercel ». Cette couche permet un raisonnement multi-étapes et relie des problèmes issus de conversations différentes.

---

L’élément clé : la détection des contradictions

C’est ce qui distingue un véritable système de mémoire d’un simple moteur de recherche amélioré.

Chaque nouveau fait est comparé aux faits existants de la même catégorie :

  1. Déduplication par empreinte du contenu ;
  2. Comparaison de similarité des mots-clés ;
  3. Distance de Levenshtein pour les faits courts ;
  4. Vérification sémantique des contradictions par un LLM.

Lorsqu’une contradiction est détectée, vous pouvez remplacer l’ancien fait, conserver les deux ou refuser le nouveau. La connaissance ne se dégrade donc pas silencieusement.

Dans notre système en production, un agent avait enregistré « Le contrat de Pierre a été renouvelé », alors que la base contenait déjà « Le contrat de Pierre n’a pas été renouvelé ». La contradiction a été détectée immédiatement. Sans ce mécanisme, l’agent aurait pu donner une réponse erronée selon le fait retrouvé en premier.

---

Zéro coût. Zéro cloud. Zéro excuse.

| Composant | Coût | |---|---| | Ollama (gemma3:4b) | 0 $ — fonctionne avec 8 Go de mémoire | | Embeddings (nomic-embed-text-v2-moe) | 0 $ — exécutés en local | | Stockage des faits | 0 $ — fichier JSON local | | Graphe de connaissances | 0 $ — fichier JSON local | | Recherche BM25 | 0 $ — index local | | Total | 0 $ par mois |

À titre de comparaison, Mem0 Pro coûte 249 $ par mois pour la mémoire graphique, tandis que l’auto-hébergement de Supermemory s’adresse principalement aux entreprises.

La seule condition est de disposer d’une machine capable d’exécuter Ollama avec un modèle de 8 Go. Il peut s’agir d’un Mac Mini à 500 $ ou de la plupart des ordinateurs portables récents.

---

Comment cela fonctionne au quotidien

Je suis développeur web. Je ne construis pas des outils d’IA pour en faire mon activité principale. J’ai créé celui-ci parce que mes agents en avaient besoin.

Ingestion automatique : chaque fois qu’un fichier Markdown change dans l’espace de travail, auto_ingest.py extrait les faits, vérifie les contradictions, met à jour les embeddings et reconstruit le graphe de connaissances. Aucune intervention manuelle n’est nécessaire.

Rappel unifié : lorsqu’un agent a besoin de contexte, il exécute unified_recall.py. Les quatre sources sont interrogées en parallèle, les résultats sont fusionnés selon un score pondéré, reclassés par un LLM, puis synthétisés en une réponse sourcée. Le temps total est d’environ trois secondes.

Raisonnement multi-étapes : à la question « Quel est l’impact du pipeline de déploiement sur le module CRM ? », le système enchaîne les recherches : pipeline de déploiement → Vercel → webhook GitHub → application Bureau → module CRM. Il peut ainsi répondre à des questions qui traversent plusieurs documents et conversations.

Déclin temporel : les faits récents obtiennent un score plus élevé. Les erreurs sont protégées de ce déclin : il ne faut jamais oublier un bug critique. Les connaissances importantes conservent un score stable. Le fonctionnement s’inspire de la mémoire humaine : les informations récentes sont plus pertinentes, mais les leçons apprises restent disponibles.

---

Premiers pas

```bash

Installation depuis ClawHub (pour les utilisateurs d’OpenClaw)

npx clawhub install primo-studio/agent-memory-tools

Ou clonage direct

git clone https://github.com/Primo-Studio/agent-memory-tools cd agent-memory-tools

Téléchargement des modèles

ollama pull gemma3:4b ollama pull nomic-embed-text-v2-moe

Vérification de l’installation

python3 scripts/selftest.py

Première requête

python3 scripts/unified_recall.py "Que s’est-il passé la semaine dernière ?" ```

C’est tout. Aucune clé API, aucun compte cloud et aucune configuration complexe.

---

La suite

Il s’agit de la version 1.0. Voici les prochaines évolutions prévues :

  • Un backend SQLite pour le graphe de connaissances, actuellement stocké en JSON ;
  • Le partage de mémoire entre plusieurs agents ;
  • Une suite de benchmarks comparant l’outil à Mem0 et Supermemory sur le jeu de données LoCoMo ;
  • Un plugin OpenClaw permettant l’appel et la capture automatiques de souvenirs, entièrement en local.

---

Pourquoi l’open source ?

Nous aurions pu commercialiser cet outil. Le marché de la mémoire pour agents IA connaît une croissance rapide.

Mais la mémoire devrait rester locale. Les connaissances de votre agent sur votre code, vos clients et vos décisions ne devraient pas être stockées sur le serveur d’une autre entreprise. Elles ne devraient pas non plus coûter 249 $ par mois.

Nous avons donc choisi de publier le projet sous licence MIT-0. Vous pouvez l’utiliser, le modifier, l’améliorer ou même le commercialiser. Donnez simplement à vos agents une véritable mémoire.

---

→ ClawHub : https://clawhub.ai/primo-studio/agent-memory-tools → GitHub : https://github.com/Primo-Studio/agent-memory-tools

Créé par Primo Studio en Guyane française 🇬🇫 — un petit studio de développement avec de grands agents.