Nous avons créé `memorize`, qui permet aux agents IA de partager la mémoire d’un projet — et nous avons besoin d’aide

Tout est parti d’un problème que je rencontrais chaque jour en développant seul. Les éditeurs sortent sans cesse de meilleurs modèles, et chaque fois que je changeais de modèle pour poursuivre le développement avec lui (par exemple d’Opus 4.7 à GPT 5.5), la mémoire de travail du projet ne suivait pas. Pendant que chaque agent accumulait son propre silo de mémoire, je devais à chaque fois reconstituer manuellement un contexte fragmenté. Les premières fonctions de mémoire des agents étaient bien trop limitées : une fois la session terminée, le contexte mourait, et comme tout restait enfermé sur une seule machine, le travail commencé sur desktop ne se poursuivait pas sur laptop.

Un projet a besoin d’une mémoire de projet. Alors nous l’avons créé : un outil open source local-first qui donne une mémoire au projet lui-même.

Points techniques dont nous sommes fiers

• Mémoire à deux couches inspirée du système d’apprentissage complémentaire (CLS) du cerveau — pendant le travail, seules des observations sont capturées à faible coût sans LLM (hippocampe), puis une consolidation en arrière-plan a lieu aux frontières de session (néocortex). L’oubli ne se fait pas par suppression, mais uniquement par compétition de score au moment de la récupération (importance × récence avec demi-vie de 14 jours × pertinence pour la tâche), et aucun souvenir n’est jamais effacé.

• Zéro clé API — aucun LLM dédié n’est nécessaire pour la consolidation. Nous relançons simplement les sessions déjà connectées de claude -p / codex exec. L’agent utilise sa propre instance pour organiser sa propre mémoire, et la récursion infinie que cela pourrait provoquer (consolidation → déclenchement de hook → consolidation → …) est interrompue par une garde via variable d’environnement.

• Consolidation sans perte — le watermark n’avance qu’après la persistance des événements ; en cas de timeout du LLM ou d’échec du parsing, la frontière suivante réessaie la même plage. Même si le watermark lui-même est perdu, une déduplication basée sur la provenance empêche les consolidations en double.

• Convergence cross-machine sans serveur — en synchronisant un journal d’événements append-only, toutes les machines convergent vers le même état à l’aide de règles déterministes basées sur le contenu, sans synchronisation d’horloge. Même si deux machines consolident simultanément la même plage, toutes les répliques choisissent le même gagnant.

• Pas de confiance aveugle dans les embeddings pour détecter les contradictions — la similarité cosinus est aveugle à la négation (« merge-le » et « ne le merge pas » donnent presque le même vecteur). Nous n’utilisons donc la similarité que pour récupérer des candidats, et c’est le LLM qui tranche. Les souvenirs perdants ne sont pas supprimés : leur période de validité est simplement fermée, ce qui permet de restaurer le « à ce moment-là, c’était vrai ».

• Partage en temps réel entre sessions parallèles — les sessions exécutées sur le même projet voient le travail des autres, et une alerte de conflit apparaît si elles touchent le même fichier.

• Faire évoluer le schéma par instrumentation plutôt que par théorie — la décision de modifier ou non la taxonomie des souvenirs se prend à partir de données collectées sur plusieurs semaines : durée de vie d’observation attachée à chaque souvenir et télémétrie comportementale (quand a-t-il été injecté, quand a-t-il été invalidé). Toute cette discussion est publique dans les Discussions du dépôt.

Pourquoi le publier maintenant

Pour être honnête, j’aurais préféré sortir quelque chose de plus mûr. Mais voir OpenAI lancer des fonctions de mémoire comme dreaming m’a fait changer d’avis : si un grand éditeur commence à creuser le même problème, c’est que la direction est probablement la bonne, et je pense qu’il faut une alternative neutre vis-à-vis des éditeurs avant que la mémoire enfermée chez les vendors ne devienne la norme. C’est pour cela que nous le publions maintenant.

Jusqu’où nous voulons aller

Avec l’arrivée de modèles de niveau Fable 5, les agents sont désormais capables de collaborer entre eux, mais il n’existe pas d’infrastructure partagée pour cela. À long terme, nous voulons construire une plateforme d’intérêt général qui apporte à la mémoire et à la collaboration des agents ce que Git a apporté au code. Faute de moyens, nous ne pouvions pas commencer par un serveur — et cette contrainte nous a au contraire conduits à une architecture local-first convergente sans serveur. Pour l’instant, la première brique, « partager la mémoire d’un projet en local », fonctionne déjà entièrement. En pratique, une grande partie des discussions de conception, de l’implémentation et même du déploiement de ce matin très tôt de ce projet ont été menées avec des agents — exactement le mode de collaboration que cet outil veut permettre.

Aide concrète recherchée

1. Testez-le et signalez les points de rupture — installation en une ligne, puis ouverture d’une issue. Rien que pendant la validation avant la sortie d’aujourd’hui, nous avons trouvé deux bugs dans le script d’installation (guillemets sous PowerShell 5.1, Linux EACCES), donc il y en a certainement d’autres.
2. Adaptateurs pour d’autres agents — si vous connaissez la structure des hooks côté Cursor, Gemini CLI ou Windsurf.
3. Participation au débat sur la taxonomie de la mémoire — une discussion est ouverte pour décider par les données de « ce qu’est un type de mémoire ».

L’installation tient en une ligne (sur Windows, voir la commande PowerShell dans le README) :

curl -fsSL https://raw.githubusercontent.com/shakystar/memorize/… | sh

Ou une ligne dans une session Claude/Codex : « Set up memorize in this project. Follow
https://github.com/shakystar/memorize/blob/main/guides/AI_SETUP.md »

Dépôt : https://github.com/shakystar/memorize · README en coréen
(https://github.com/shakystar/memorize/blob/main/docs/i18n/README.ko.md) · Document d’architecture
(https://github.com/shakystar/memorize/blob/main/docs/ARCHITECTURE.md)

AGPL, stockage entièrement local, aucune télémétrie. Tous les retours sont les bienvenus.

[shakystar]

C’est l’auteur.

La journée juste avant le lancement de ce projet a reflété exactement le mode de collaboration que cet outil vise. J’ai mené avec l’agent une discussion de conception du type « est-ce que des tags conviennent pour classer les souvenirs, alors qu’un cerveau n’a pas de tags ? », puis le consensus a été figé dans GitHub Discussions et les issues, la PR d’implémentation a été mergée, et j’ai même vérifié le dogfooding où l’agent utilisait sa propre instance (claude -p) comme extracteur pour intégrer les traces de travail réelles dans la mémoire à long terme avant d’appuyer sur le bouton de déploiement. Tous les débats de conception de ce processus sont publiquement visibles dans les Discussions du dépôt.

Parmi ce que je n’ai pas écrit dans l’article, la question qu’on me posera souvent sera probablement : « est-ce que ça ne ralentit pas ou n’engendre pas de coûts ? » Donc j’y réponds d’avance : pendant le travail, le LLM n’intervient pas du tout. La capture repose sur un filtre de règles, donc la latence perçue est nulle, et le LLM ne tourne qu’une seule fois pour l’intégration à la frontière entre deux sessions ; en plus, c’est un processus de fond séparé, donc il ne bloque l’agent pas même une seconde. Même cet appel passe par votre abonnement claude/codex existant, donc il n’y a pas de facturation API supplémentaire. D’après le dogfooding d’aujourd’hui, 44 observations sur une session ont été intégrées en un seul appel en arrière-plan (environ 30 secondes), et l’injection au démarrage de session n’est qu’un texte dans une enveloppe de 4 000 caractères, donc la charge en tokens est quasi nulle. L’objectif était qu’on puisse l’installer puis l’oublier.

Pour partager un seul des points repérés lors de la validation sur machine réelle avant la sortie : la commande de vérification du README était npx memorize, mais le package npm memorize sans scope appartient à quelqu’un d’autre. Il y aura sûrement d’autres points de ce genre, « visibles uniquement sur machine réelle », donc vos signalements ont vraiment de la valeur.

Petite demande : j’ai validé directement sur des machines Windows et WSL/Linux, mais je n’ai pas de machine macOS. Toute la suite de tests macOS passe en CI, mais je n’ai pas pu exécuter le cycle complet sur machine réelle, de l’installation en une ligne → hook → injection au démarrage de session. Si une seule personne sur macOS peut l’installer et me dire en commentaire ou via une issue si ça marche ou si ça casse, ce serait d’une grande aide.

Les questions de conception sont aussi les bienvenues — pourquoi ne pas utiliser les embeddings pour la décision, pourquoi il n’y a pas de suppression, comment la convergence cross-machine fonctionne sans horloge — je répondrai à tout.