Apprendre à MadoHub à se souvenir
Au cœur du système de mémoire de MadoHub : six types de mémoire, du namespacing par persona et par projet, et pourquoi rien de ce qu'un agent apprend ne devient permanent sans qu'un humain ne l'ait d'abord regardé.
Chaque session d'agent démarre de zéro. Vous dites à Claude Code que votre projet utilise pnpm, pas npm, le lundi. Jeudi, à la session suivante, c'est oublié — sauf si vous le retapez, ou si quelque chose d'autre le retient pour vous.
Ce « quelque chose d'autre », c'est ce que nous avons construit dans MadoHub au cours des dernières phases : un système de mémoire qui se trouve sous l'historique de chat, survit entre les sessions et les projets, et donne aux agents un moyen de lire et d'écrire ce qu'ils ont appris. Ce post est sur la forme de ce système, et sur la décision de design que nous pensons la plus importante : la mémoire extraite ne devient vraie mémoire que lorsqu'un humain le dit.
Comment MadoHub gère ça
Six types de mémoire
Chaque entrée de mémoire porte un type, et l'ensemble est fermé à exactement six valeurs :
| Type | À quoi ça sert |
|---|---|
preference | Une préférence utilisateur confirmée — « aime les réponses concises » |
fact | Un fait durable et vérifiable sur le projet |
decision | Un choix qui a été fait, et souvent pourquoi — « choisi Tauri plutôt qu'Electron pour la taille du bundle » |
pattern | Un comportement récurrent qu'il vaut la peine d'encoder une fois |
postmortem | Ce qui a mal tourné, et quoi faire différemment |
event | Quelque chose qui s'est produit, dont il vaut la peine de se souvenir que ça s'est produit |
Il n'y a pas de septième option ni de champ libre. C'est délibéré : le tableau de bord de la mémoire filtre et libelle par type, et un type « fantôme » qui passerait au travers ne serait qu'une catégorie que rien ne peut rechercher ni afficher correctement.
Namespacing par persona et par projet
La mémoire est partitionnée par namespace, donc ce qu'un agent rappelle peut être restreint. Un namespace persona: lie la mémoire au persona actif ; un namespace workspace: la lie à un projet spécifique. Quand un agent écrit une mémoire sans spécifier de namespace, elle par défaut au persona actif. Au recall, il peut restreindre à un seul namespace — tirer uniquement depuis la mémoire d'un projet, par exemple, au lieu de tous les personas à la fois — afin que le recall reste pertinent au lieu de remonter du bruit de projets sans rapport.
Trois façons dont un candidat naît
Un agent qui écrit une mémoire explicitement est le chemin évident, mais ce n'est pas le seul. MadoHub surveille aussi vos conversations en arrière-plan :
- remember explicite — l'agent a décidé, en pleine conversation, que quelque chose valait la peine d'être conservé et l'a écrit.
- Après chaque tour — un passage léger de modèle scanne le dernier échange à la recherche de quelque chose de durable, parce que la plupart de ce qui vaut la peine de retenir surgit dans la conversation normale plutôt qu'à des moments « retiens ça » délibérés. Ça tourne à chaque tour, c'est donc plus bruyant par design.
- Avant compaction — juste avant qu'une longue fenêtre de conversation soit résumée pour économiser du contexte, le même type de scan tourne sur les messages sur le point d'être compressés. Celui-ci compte parce que la compaction est avec perte : une fois une plage de messages résumée, tout ce qui n'en a pas été extrait est parti de la mémoire à long terme pour de bon. Une tranche calme de conversation coûte un appel de modèle bon marché et n'ajoute rien plutôt que de remplir la file avec du bruit.
Les entrées manuelles depuis le tableau de bord de la mémoire complètent un quatrième chemin, toujours routé via la même table de candidats, juste saisi par une personne au lieu d'être extrait par un modèle.
Pourquoi une revue, pas une écriture auto
Voici le choix de design au centre de ce système : aucun de ces quatre chemins n'écrit dans la mémoire recherchable. Chacun atterrit dans une file de candidats avec un statut qui démarre à pending et passe à approved ou rejected — ou, si personne ne le révise du tout, archived après 30 jours sans activité. Seuls les candidats approuvés sont promus dans la mémoire que les agents recherchent réellement.
On pourrait penser que ça ralentit les choses, et c'est le cas, par design. L'alternative — laisser le jugement d'un modèle sur ce qui est « assez important pour retenir » écrire directement dans un store qui est tiré dans chaque conversation future — signifie qu'une mauvaise supposition ne vous coûte pas une mauvaise réponse une fois. Elle vous coûte une mauvaise réponse chaque fois que cette mémoire est rappelée à partir de maintenant, se composant silencieusement jusqu'à ce que quelqu'un remarque par hasard l'agent citant quelque chose qui n'est pas vrai. Ce risque est pire pour exactement les deux types que vous voudriez le plus croire : les entrées postmortem et decision ont tendance à être fortement pondérées par ce qui les consomme ensuite, donc une entrée périmée ou fausse fait plus de dégâts qu'une entrée manquante n'en ferait jamais.
La revue se fait dans Paramètres → Mémoire, répartie entre une file en attente — contenu, type, namespace, source, confiance, et combien de fois un candidat équivalent a été vu, avec la possibilité d'éditer avant d'approuver ou de sauter au tour originaire — et une vue approuvée groupée par namespace où les entrées peuvent être éditées ou supprimées. Il y a aussi une section Advanced avec auto-approbation opt-in : une fois qu'un candidat a été vu assez de fois à une confiance assez élevée, il peut se promouvoir sans clic manuel. Cette politique est désactivée par défaut. Laissée désactivée, chaque chose qu'un agent décide que vous pourriez vouloir qu'il retienne passe d'abord devant vous — ce qui, pour l'instant, est exactement le point.
Conseils pratiques
- Survolez la file en attente régulièrement. La mémoire n'aide qu'une fois approuvée, et les candidats qui restent intouchés 30 jours sont archivés. Un passage rapide dans Paramètres → Mémoire toutes les quelques sessions empêche la file de s'accumuler.
- Éditez avant d'approuver. Si un agent a capturé la bonne idée dans les mauvais mots — « utilise npm » alors que vous utilisez en réalité pnpm — corrigez-la dans la file plutôt que d'approuver puis de corriger plus tard. La mémoire approuvée est ce que les agents citeront.
- Restreignez avec les namespaces. Les faits spécifiques à un projet vont dans le namespace
workspace:afin qu'ils ne saignent pas vers des projets sans rapport. Les préférences au niveau du persona vont danspersona:. - Soyez prudent avec
decisionetpostmortem. Ceux-ci sont fortement pondérés quand les agents les rappellent, donc une entrée périmée ou fausse fait plus de dégâts qu'une entrée manquante. Préférez rejeter un candidat douteux plutôt que l'approuver en espérant que ça ira. - Activez l'auto-approbation seulement si vous le voulez vraiment. Le réglage Advanced peut promouvoir des candidats à haute confiance vus fréquemment sans clic, ce qui est pratique mais supprime la porte humaine. Laissez-le désactivé jusqu'à ce que vous fassiez confiance à la qualité d'extraction.