memweave, une librairie Python open-source signée Sachin Sharma, est apparue sur Towards Data Science cette semaine, se vendant comme de la mémoire d'agent sans infra — pas de Pinecone, pas de Weaviate, pas de base vectorielle managée. Juste un dossier de fichiers markdown pis un index SQLite. Le timing est intéressant : la plupart de l'infrastructure de mémoire d'agent sur le marché a couru après l'échelle — stockages vectoriels, bases de graphes, embeddings distribués — alors que la plupart des agents en pratique ont pas besoin d'échelle. Ils ont besoin de persistance, d'inspectabilité, pis d'un signal de récupération qui se plante pas sur les requêtes par correspondance exacte. memweave parie que le défaut a été mauvais.

L'architecture tient en trois morceaux. Des fichiers markdown dans un dossier sont la source de vérité, lisibles pis modifiables par les humains comme par les agents. SQLite contient un index dérivé avec FTS5 pour le matching BM25 par mots-clés, l'extension sqlite-vec pour la similarité d'embeddings accélérée SIMD, pis un cache d'embeddings indexé par SHA-256 du contenu pour que les réécritures déclenchent pas d'appels API redondants. La récupération est hybride par défaut à 0.7 × vectoriel plus 0.3 × BM25, suivie d'un re-classement MMR pour la diversité. Une décroissance temporelle pondère à la baisse les mémoires plus anciennes selon l'âge du fichier, avec les fichiers persistants (sans préfixe de date) qui vieillissent différemment de ceux datés genre YYYY-MM-DD.md. Les namespaces d'agents viennent des sous-dossiers. Le readme pointe vers des notebooks exécutables — un démo de club de lecture pis un agent de notes de réunion — mais pas de benchmarks publiés, ce qui vaut la peine d'être souligné : la librairie est nouvelle pis pas encore éprouvée à l'échelle.

Sous la librairie, il y a un vrai argument sur ce dont la mémoire d'agent a réellement besoin. La plupart des agents opèrent sur des milliers d'entrées, pas des millions ; SQLite plus sqlite-vec gère ça sans saut réseau. Le défaut hybride BM25+vectoriel est aussi probablement correct : les embeddings tout seuls ratent les cas de correspondance exacte genre "c'est quoi ma clé API pour le service X" où l'utilisateur a littéralement écrit la chaîne ; BM25 tout seul rate la formulation sémantique. Mais le levier opérationnel, c'est celui sur lequel il faut porter attention : faire git diff memory/ montre ce que l'agent a appris entre deux exécutions, commit par commit. C'est une primitive de débogage qu'aucune base vectorielle te donne, pis c'est exactement ce que tu veux quand t'essaies de reconstituer pourquoi un agent a pris une décision précise à 3 h du matin. Le contrôle de version comme opération de première classe sur la mémoire, pas comme pensée après-coup collée via des exports de base de données.

Le patron est copiable même si la librairie elle-même te convient pas. Pour n'importe quel agent dont la mémoire est pas fondamentalement à l'échelle du million d'entrées — ce qui est la plupart des agents que les développeurs livrent pour vrai — le modèle à voler est : traiter un dossier de markdown comme source de vérité, dériver un index qu'on peut reconstruire de zéro n'importe quand, récupération hybride plutôt que vectoriels purs, pis versionner la mémoire pour pouvoir auditer ce qui a changé. La mise en garde honnête : à l'échelle où les bases vectorielles gagnent vraiment leur place — corpus de documents massifs, production multi-tenant avec des millions de mémoires par utilisateur — cette approche casse probablement, pis l'auteur a pas roulé les benchmarks pour montrer le mode de défaillance. Pour les agents personnels, les agents de recherche, l'outillage interne — la majorité plate-mais-réelle de ce qui se construit — le patron lo-fi est le bon point de départ. Lis les deux démos de notebooks, décide si ça fite, pis vole l'idée de toute façon.