Moerae — memoire agents hierarchique en Rust, local-only, inspiration Kafka¶

Resume¶

Noa (@Akanoa) publie le 2026-04-09 Moerae, un "queryable hierarchical AI memory system for AI agents" ecrit en Rust, entierement opensource et local. Deux primitives : put et search. Architecture :

• Storage : SQLite en mode WAL + index vectoriels usearch HNSW (768 dimensions)
• Embedding : inference locale via llama.cpp avec le modele embeddinggemma-300m
• Lifecycle segments : les segments se ferment a capacite ou sur staleness, eviction automatique des vieux segments, promotion des segments "valuables" vers le scope projet
• Scoping : conversation-level (default) ou project-level
• Interfaces : CLI + REPL + library Rust
• License : MIT
• Maturite : v0.1.0, 4 stars sur GitHub, benchmark BEAM "strong retrieval performance" (0.86 mean cosine similarity)

La philosophie annoncee par Noa : "HNSW index grouped by logical definition inspired from Kafka, called segment. This allows the conversation to grow without loss of relevance even with big chunks of data."

Le pitch personnel est sympa : "I'm not as famous as Milla Jovovich, I'm not coding at night, but I'm engineer and her idea of room and hall give me an idea. [...] It's my first finished project of my life make it shine." La reference a Milla Jovovich est opaque — peut-etre un inside joke, peut-etre une reference au palais de memoire (cf. MemPalace, fiche 2026-04-08). L'auteur est deja connu dans notre corpus : la fiche 2026-03-30-akanoa-lsystem-grammaire-test-generation.md le cite pour ses travaux sur les L-Systems en generation adversariale de contre-exemples formels. Profil d'ingenieur francais independant, solide, qui publie des outils concrets en Rust.

Analyse critique¶

Ce qui est interessant¶

L'inspiration Kafka appliquee aux memoires d'agents est une idee neuve. Les systemes de memoire LLM existants (MemGPT, MemPalace, mem0) raisonnent en termes de "chunks" ou "palaces" ou "chains". Moerae importe explicitement le concept de segment de Kafka : une unite append-only qui se ferme au bout d'un moment, puis qui peut etre promue vers une couche superieure (conversation → project) si elle est jugee valuable. C'est un modele de durabilite progressive emprunte aux systemes de log distribues.

Ca a deux consequences architecturales pratiques :

1. Les vieux segments ne polluent pas l'index. L'HNSW ne cherche que dans les segments actifs du scope demande. La taille du corpus peut grossir sans degradation de la latence, parce que l'index est partitionne logiquement.
2. La promotion est un mecanisme de compounding natif. Un segment conversation-level qui a ete frequemment retrieved avec succes est promu au niveau projet. C'est l'equivalent Kafka d'une operation "compaction avec selection" — on garde ce qui a demontre son utilite.

Le local-only est serieux. Embedding via llama.cpp + embeddinggemma-300m signifie zero appel reseau, zero API key, tout tourne sur la machine. Compatible avec une utilisation dans des contextes sensibles RGPD / juridiques — ce qui est exactement notre profil sur certaines taches. Ollama + BGE-M3 (ce qu'on utilise actuellement pour mail-search-mcp et learnings) joue dans le meme registre.

Le code est en Rust. Pas un detail : pour un systeme qui doit etre embarquable dans d'autres processus (CLI, REPL, library), Rust offre des garanties memoire + perf + portabilite que Python ne peut pas egaler. C'est coherent avec le choix de sqlite-vec et usearch qui sont aussi des projets C/Rust.

Ce qui limite le verdict a "veille"¶

Quatre frictions concretes :

1. 4 stars GitHub, v0.1.0. Projet fresh, pas de communaute, pas encore de retours en production. Noa dit explicitement "first finished project of my life". C'est a la fois sympa et un signal de maturite basse.

2. Pas de comparatif serieux contre l'existant. Le benchmark BEAM avec "0.86 mean cosine similarity" est honnete mais insuffisant pour positionner face a MemGPT, mem0, LangChain memory, MemPalace, GBrain. On ne sait pas ce que Moerae fait mieux ou pire que le paysage existant.

3. Pas d'integration MCP aujourd'hui. Pour etre adoptable par Claude Code / un agent workflow, il faut un wrapper MCP. Moerae offre CLI + REPL + library Rust — pas de protocole d'integration natif agents. Un pont MCP est a ecrire.

4. La philosophie "segment + promotion" est belle mais elle suppose que le modele (ou un orchestrateur) sache decider quand un segment est "valuable" pour promotion. Sans critere explicite, la promotion peut etre arbitraire. Le code GitHub a des "thresholds de promotion" mais je n'ai pas verifie leur heuristique.

Le vrai signal faible¶

C'est la troisieme fiche memoire agent en 72 heures :

Trois projets independants, trois langages differents, trois angles differents. Tous apparus en une semaine. C'est le signal que l'industrie converge sur le pattern "memoire agent local + fichier/DB + vecteurs + scoping/lifecycle" — pas encore stabilise, mais clairement la prochaine brique architecturale que les agents ont besoin. Ca merite une fiche meta de type "convergence memoire agents 2026-04" une fois qu'un ou deux projets se seront stabilises.

Pertinence ProbatioVault¶

Impact modere — pas de migration, mais un candidat a tester en POC et une piece a suivre dans la watchlist memoire agent.

Comparaison directe avec notre existant¶

Notre "memoire" agent actuelle est un assemblage heterogene :

Le mecanisme de promotion automatique conversation → projet est la seule vraie nouveaute qu'on n'a pas. Aujourd'hui, decider qu'un learning est assez robuste pour passer de "REX story unique" a "invariant global" est une operation manuelle faite par /gov-compounder Phase 5 (learnings-as-invariants). L'heuristique de Moerae pourrait inspirer une version automatisee.

Pourquoi on ne migre pas¶

Memes raisons que pour GBrain (cf. fiche 2026-04-10-gbrain-thin-cli-sqlite-knowledge-base.md) :

1. Notre stack actuelle fonctionne et est inspectable via git
2. Moerae est en v0.1.0 avec 4 stars — risque operationnel eleve
3. Pas d'integration MCP, il faudrait ecrire un pont
4. Notre volume actuel ne justifie pas le cout de migration

Ce qu'on peut en tirer immediatement¶

L'heuristique de promotion segment conversation → projet. C'est la seule brique directement applicable sans migrer l'infra. Concretement :

• Ajouter un score "frequence de reutilisation effective" a chaque learning dans learnings.jsonl (combien de fois il a ete retrieved en step 0 par /gov-learnings-inject, combien de fois la story a eu Gate 8 GO apres cette injection)
• Quand le score depasse un seuil (ex : 5 reutilisations avec Gate 8 GO), marquer le learning comme "promu" — ce qui le rend injectable cross-domaine, pas seulement sur son domaine d'origine
• Inversement, un learning jamais reutilise apres N stories peut etre archive (pas supprime)

C'est exactement ce que Moerae fait automatiquement avec ses segments, applique a notre corpus learnings. Ca rejoint directement le TODO #25 (confidence scoring des learnings) et le TODO #28 (mesure efficacite compounding). Moerae est une reference d'implementation pour ces deux items.

Action recommandee¶

Pas d'adoption directe. Deux actions concretes :

1. Cloner Moerae et lire le code (300 lignes Rust, une apres-midi max) pour comprendre l'implementation concrete de la promotion segment → projet. Extraire l'heuristique et l'appliquer a notre learnings.jsonl dans le cadre du TODO #25. Noa est bon et son code sera probablement propre.

2. Ouvrir un issue sur le repo Moerae pour demander un pont MCP ou evaluer si son architecture s'y prete. Si Noa le construit, on aura une option drop-in plus serieuse pour la memoire agent dans 6-12 mois. Sinon, on continue sur notre stack.

3. Ajouter Moerae a la watchlist "memoire agents" dans le TODO.md, a cote de MemPalace et GBrain. Reevaluer trimestriellement si un des trois se detache.

Note personnelle a ne pas perdre¶

Noa est un cas interessant : deja cite dans notre corpus pour L-System generation (TODO #23), maintenant pour memoire agents. Profil de dev francais independant qui produit regulierement des outils interessants et rigoureux. A suivre en priorite dans les veilles futures — le signal-to-noise de ses posts est bon.