Un développeur communautaire (Claudio Drews) a livré Memory OS aujourd'hui, une pile mémoire à 6 couches sous licence MIT qui s'assoit par-dessus le framework Hermes Agent de NousResearch. Les couches mappent à des purposes mémoire distincts : fichiers workspace (MEMORY.md, USER.md, CREATIVE.md injectés dans le system prompt), historique de sessions (SQLite + FTS5 full-text search), faits structurés (SQLite + HRR + trust scoring avec boucles de feedback), Fabric (extraction de sessions par LLM, forké de Icarus Plugin), base de données vectorielle (Qdrant avec vecteurs cosinus 4096-dimensionnels plus BM25 sparse), et un Wiki LLM auto-curé qui est ré-ingéré dans Qdrant. Tout roule localement via Docker (Qdrant + Redis + ARQ Worker + Python 3.11+) ; les appels LLM vont au provider que Hermes supporte (OpenRouter, OpenAI, Anthropic, Ollama).
L'architecture est un système de récupération en cascade. Sur pre_llm_call, quatre sources (Fabric, Qdrant, Sessions, Facts) sont interrogées avec hybrid search d'abord, puis dense vectors, puis lexical, puis SQLite en fallback. La déduplication per-session arrête le même contexte d'apparaître deux fois dans une fenêtre, et un threshold de pertinence filtre avant que rien n'atteigne le modèle. Sur post_llm_call et on_session_end, la capture écrit de retour dans les couches. L'oubli est explicite : un scanner de decay hebdomadaire vieillit les entrées stale, et la dédup sémantique fusionne les mémoires quasi-identiques quand la similarité cosinus dépasse 0,92. Le trust scoring (couche 3) maintient une boucle de feedback qui ajuste la crédibilité des sources dans le temps. Ce qui manque matter : pas de benchmarks publiés sur la qualité de rappel, la latence, ou les économies de tokens, et pas de résolution formelle de conflit d'écriture pour la consistance multi-agents. Le repo est à github.com/ClaudioDrews/memory-os, tout neuf avec peu de commits, un seul développeur. Traite comme scaffolding early-stage pour l'idée des couches, pas comme un composant production-hardened pour l'instant.
Deux fils d'écosystème. Premièrement, l'architecture est une articulation explicite community-built de ce que la plupart des builders d'agents finissent par assembler ad-hoc : un pipeline mémoire en couches où des purposes différents (contexte système, rappel de session, stockage de faits, recherche sémantique, extraction structurée, accumulation de connaissances) obtiennent des mécanismes distincts au lieu d'être collapsés en un seul pattern "vector DB et prier". Cette mise en couches est la leçon de design qui vaut la peine de garder même si tu ne touches jamais à Memory OS directement. Deuxièmement, le positionnement : Memory OS se contraste explicitement avec les services cloud comme mem0, Zep, et Letta en étant entièrement local. Ça s'inscrit dans la vague plus large de "je veux la mémoire de mon agent sur mon disque, pas dans la base de données de quelqu'un d'autre," qui est une posture légitime pour les builds privacy-sensitive ou air-gapped. Le trade-off est opérationnel : une pile Docker avec Qdrant + Redis + ARQ Worker c'est plus d'infrastructure que d'appeler mem0 via API. Pour les builders qui décident entre mémoire cloud-managed et self-hosted, ça met une vraie option du côté local du ledger, quoique framework-bound à Hermes.
Lundi matin, si tu construis déjà sur Hermes Agent : Memory OS vaut l'essai comme drop-in upgrade de la mémoire native de Hermes, surtout si ton agent bénéficie de rappel sémantique à travers de longs historiques. Fais ta propre évaluation sur la qualité de rappel et l'usage de tokens avant de parier dessus ; pas de benchmarks publiés veut dire que tu es le benchmark. Si tu n'es pas sur Hermes, la décomposition en 6 couches est le takeaway, pas le code : workspace + sessions + faits + extraction + vecteurs + wiki curé mappe à des purposes distincts dont tu as probablement déjà besoin, séparément, dans quel que soit ton stack. Si tu déploies un agent privacy-sensitive ou air-gapped et que tu ne veux pas d'un provider de mémoire cloud, c'est une option fraîche à évaluer contre les alternatives établies. Single-developer plus few-commits-old veut dire appuie-toi dessus avec précaution ; la valeur en ce moment c'est l'architecture comme documentation, pas le code comme dépendance battle-tested.