agentmemory: Une mémoire persistante pour les agents IA

rohitg00/agentmemory

Le problème qu'il résout

Les agents harness comme Claude Code ou Codex CLI ont des mémoires intégrées qui évoluent lentement, parmis toutes les autres features d'un agent harness complet. C'est pourquoi agentmemory est né: un projet dédié à la gestion mémoire.

agentmemory se positionne comme le fichier système manquant : une base de données mémoire, 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'outil
• SessionStart — injecte le contexte pertinent dans la conversation
• SessionEnd — compresse la session en mémoire structurée
• PreCompact — 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és
• memory_save — sauvegarder manuellement une décision ou un pattern
• memory_sessions — lister les sessions récentes
• memory_recall — rechercher des observations passées
• memory_governance_delete — supprimer avec trail d'audit

Utilisations avancé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.

Sur chaque poste de développeur, dans la configuration MCP de l'agent:

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

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).

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é.

Conclusion

agentmemory propose une véritable base de mémoire, structurée en quatre niveaux calqués sur la cognition humaine, interrogeable par recherche hybride, et compatible avec la quasi-totalité des agents de code du marché. Au-delà de l'usage standard avec un seul agent, il convient aussi pour des scénarios plus ambitieux : mémoire partagée entre plusieurs développeurs sur un même projet, injection de contexte métier depuis un pipeline CI/CD, ou coordination de plusieurs agents travaillant en parallèle. C'est cette polyvalence, plus que la seule fonction de "mémoire persistante", qui explique l'adoption rapide du projet dans l'écosystème open-source.

rohitg00/agentmemory