ia
agentmemory: Une mémoire persistante pour les agents IA
26 juin 2026·4 min de lecture
Le problème qu'il résout
Les agents comme Claude Code ou Codex CLI ont des mémoires intégrées qui se comportent comme des post-its : limitées à ~200 lignes, statiques, sans capacité de recherche. Dès la fin de la session, l'agent oublie les décisions d'architecture, les patterns de bugs, tes préférences de stack.
agentmemory se positionne comme le fichier système manquant : une base de données cherchable derrière les post-its, qui tourne en arrière-plan sans effort manuel, compatible avec pratiquement tout les agents (Claude Code, Cursor, Codex CLI, Gemini CLI, Windsurf, Cline, Aider...).
Comment ça fonctionne
Le cœur du projet est un pipeline mémoire inspiré de la psychologie cognitive humaine. Chaque observation passe par quatre niveaux de consolidation :
Working : Observations brutes des outils utilisés, "Mémoire à court terme" Episodic : Résumés compressés de chaque session, "Ce qui s'est passé" Semantic : Faits extraits et patterns récurrents, "Ce que je sais" Procedural : Workflows et patterns de décision, "Comment faire"
Les souvenirs qui se dégradent sont repéré, se renforcent à chaque accès, et les contradictions sont détectées puis résolues automatiquement.
Les hooks du cycle de vie
agentmemory se branche sur le cycle de vie de l'agent via plusieurs hooks :
PostToolUse— capture chaque appel d'outilSessionStart— injecte le contexte pertinent dans la conversationSessionEnd— compresse la session en mémoire structuréePreCompact— ré-injecte la mémoire avant compaction
D'autres sont à découvrir dans la documentation du projet.
La recherche hybride triple
La récupération de contexte combine trois flux fusionnés par Reciprocal Rank Fusion (RRF) :
- BM25 : recherche par mots-clés avec expansion de synonymes (zéro dépendance externe)
- Vector : similarité sur des embeddings denses (si un provider est configuré)
- Graph : traversée du graphe de connaissances (si des entités sont détectées dans la requête)
Installation et utilisation
Démarrage en 30 secondes
La démo comprend 3 sessions réalistes (auth JWT, fix N+1, rate limiting) et montre que la recherche "database performance optimization" retrouve le fix N+1 là où un grep échouerait.
Intégration avec Claude Code
Cela enregistre les hooks, les skills, et câble automatiquement le serveur MCP, exposant les outils MCP sans aucune configuration supplémentaire.
Les outils MCP essentiels
memory_smart_search— recherche hybride sémantique + mots-clésmemory_save— sauvegarder manuellement une décision ou un patternmemory_sessions— lister les sessions récentesmemory_recall— rechercher des observations passéesmemory_governance_delete— supprimer avec trail d'audit
Utilisations détournées
1. Mémoire partagée multi-agents / multi-projets
Le serveur étant un daemon local indépendant, plusieurs agents (ou plusieurs instances du même agent sur des projets différents) peuvent partager la même mémoire. En configurant AGENTMEMORY_URL pour pointer vers un serveur distant, on crée une mémoire d'équipe centralisée accessible à tous les développeurs du projet.
2. Injection de contexte métier via REST
Rien n'oblige à ce que les observations viennent uniquement des hooks d'agents. Via l'API REST, on peut injecter des observations depuis n'importe quel script externe. L'endpoint d'injection est POST /agentmemory/observe .
Un pipeline CI/CD peut ainsi pousser automatiquement les résultats de tests, les rapports de dette technique, ou les décisions d'architecture directement dans la mémoire, qui sera récupérée par l'agent à la prochaine session.
3. Base de connaissances programmatique via le SDK
Les fonctions iii (mem::remember, mem::observe, mem::smart-search, mem::forget) sont accessibles depuis n'importe quel langage :
Ce qui permet d'utiliser agentmemory comme base de connaissances pour des scripts d'automatisation, outils de documentation, ou un chatbot interne branché sur la mémoire du projet.
4. Bootstrap depuis des historiques existants
agentmemory peut importer des historiques de sessions Claude Code au format JSONL déjà existants, pour permettre l'integration à un projet déjà existant :
5. Orchestration multi-agents avec Sentinel et Signal
Les outils memory_sentinel_create et memory_signal_send/memory_signal_read permettent de créer des watchers événementiels et de la messagerie inter-agents. Combinés avec les memory_lease, on peut orchestrer plusieurs agents en parallèle : agent A réserve une tâche via un lease, agent B attend le signal de complétion avant de continuer.
Résultats attendus
Usage normal
Une fois installé et câblé, le changement est perceptible dès la deuxième session sur un projet. Le contexte injecté est limité par défaut à 2 000 tokens (configurable), contre environ 22 000 tokens si tu chargeais tout manuellement.
Concrètement, l'agent retrouve sans effort :
- Les décisions d'architecture et les choix de librairies
- Les bugs déjà rencontrés et les solutions appliquées
- Les patterns de ton codebase (naming, structure, conventions)
- Les contraintes de déploiement ou de stack spécifiques au projet
Le viewer en temps réel sur http://localhost:3113 permet de visualiser exactement ce qui est capturé et ce qui est injecté.
Intégration dans un agent harness comme ECC, une bonne idée ?
ECC a sa propre couche de mémoire persistante et le skill continuous-learning-v2. À la fin de chaque session, ECC distille des instincts (patterns comportementaux avec confidence score) et les sauvegarde dans ~/session-data/ et ~/skills/learned/. À la session suivante, ces instincts sont réinjectés dans le contexte via ECC_SESSION_START_MAX_CHARS (défaut : 8 000 chars).
ECC repose sur un stockage mixte : fichiers plats pour les instincts et un SQLite state store pour l'état de session. Les instincts sont listables via /instinct-status, mais il n'existe pas de requête sémantique du type "montre-moi tout ce qui concerne le middleware d'auth de ce projet". C'est exactement ce que memory_smart_search de agentmemory couvre.
La vraie valeur ajoutée d'agentmemory sur ECC est donc la recherche sémantique sur les observations passées.
Mais il y a là un risque d'OverEngineering. Comme ECC injecte déjà du contexte à chaque session, si agentmemory en rajoute aussi, ça peux saturer le contexte utile. Pour réduire ce risque, il faut limiter l'injection de contexte d'agentmemory en dessous des 2000 tokens par défaut, et observer si avec ou sans les sessions agentiques sont plus ou moins cohérente et efficace.
Pour des projets léger ou avec un Workflow 100% fait maison, cet outil, bien implémenté, peut réellement faire une différence sur la continuité de vos sessions. Mais si vous maitrisez déjà des Agent Harness aussi complet que ECC, l'ajout reste pertinent uniquement pour la recherche sémantique cross-projets. Autrement, sans, ECC peut couvrir déjà suffisamment la mémoire pour le pilotage quotidien de vos projets.