Memoire agents : fichiers Markdown, compounding, pas de vector DB¶
Resume¶
Trois sources convergent vers la meme architecture de memoire pour agents IA :
| Source | Approche | Apport specifique |
|---|---|---|
| Karpathy (12M vues, 78K bookmarks) | Wiki Markdown auto-maintenu par LLM, pipeline 5 etapes, Obsidian frontend | "Every answer compounds" — persister enrichit le systeme. Lint+Heal detecte inconsistences proactivement |
| Claude Code leak (803K vues, 8.2K bookmarks) | 3 couches : MEMORY.md (index) → topic files (on-demand) → transcripts (grep) | Principes de design : index-not-storage, staleness-first, skeptical retrieval, autoDream (consolidation background) |
| ByteRover (arXiv 2604.01599, 4K stars) | Context Tree hierarchique (domain > topic > subtopic > entry), YAML frontmatter | Benchmarks formels (LoCoMo 96.1%, LongMemEval 92.8%), lifecycle adaptatif (importance scoring, maturity tiers, temporal decay) |
| obsidian_vault_pipeline (@fakechris) | Pipeline Python complet : ingestion → deep reading LLM → quality gates → extraction evergreen → index maintenance | WIGS (5 couches de verification d'integrite), audit JSONL, backlink maintenance auto, mode autopilot, quality gates sur documents (pas seulement code) |
| Karpathy gist "LLM Wiki" (05/04) | Architecture 3 couches : sources brutes (immutables) → wiki LLM-genere (markdown + wikilinks) → schema de configuration | Workflows explicites (ingestion, requetes, lint). Distribue comme "idea file" — un markdown d'une page, pas de code. "Prompt requests" au lieu de PRs. Obsidian + qmd (BM25/vecteurs) |
Les cinq sources rejettent les vector DB au profit de fichiers Markdown inspectables, editables, git-diffables. Le LLM curate et retrieve sa propre memoire plutot que de deleguer a un pipeline d'embeddings.
Analyse critique¶
Ce qui converge (5/5 sources) :
- Fichiers Markdown > vector DB a l'echelle d'un agent ou d'un projet. L'inspectabilite (git diff, edition humaine, grep) bat les black-box vectorielles pour le debugging et la confiance.
- Index leger toujours en contexte + contenu charge a la demande. Pas de dump integral.
- La memoire se reecrit, pas juste s'appende. autoDream (Claude Code), Lint+Heal (Karpathy), curation agent (ByteRover) — tous convergent vers une maintenance proactive.
- Ne pas stocker ce qui est derivable du code, de git, ou de l'etat courant.
Ce que le gist LLM Wiki ajoute (05/04) :
- Architecture 3 couches explicite : sources brutes (immutables, source de verite) → wiki LLM-genere (pages interconnectees, reecrites par l'agent) → schema (configuration, conventions, workflows). Notre pipeline veille suit deja ce pattern sans le formaliser : bookmarks X (sources brutes) → fiches veille MD (wiki) → skill
/veille(schema). - Le concept "idea file" : distribuer un markdown d'intention plutot que du code. L'agent de chaque utilisateur instancie localement. Karpathy : "PRs should become prompt requests." La communaute (@SynabunAI) : "spec quality is the new engineering". C'est la formalisation de ce que font deja les skills Claude Code — un markdown qui decrit le comportement, pas le code.
- Lint periodique : verification proactive des contradictions, concepts orphelins, references manquantes dans le wiki. Absent de notre pipeline veille et learnings.
Ce que ByteRover ajoute :
- Des benchmarks academiques reels (LoCoMo, LongMemEval) — les deux autres sont du workflow personnel ou du reverse-engineering.
- Un lifecycle formel : importance scoring, maturity tiers (seed → growing → mature → archival), temporal decay, access tracking.
- Un outil concret avec CLI et MCP. Mais : Elastic License 2.0 (source-available, pas open-source) et cloud sync obligatoire pour certaines features.
Limites communes :
- "No RAG" fonctionne sur un corpus de niche curate manuellement. Sur un corpus large et heterogene (93+ learnings, 50+ specs, 30+ plans), FAISS/RAG reste necessaire.
- La curation humaine (quoi stocker, quoi pruner) reste le bottleneck. Le gist LLM Wiki le formalise avec un "lint" mais ne resout pas le probleme de la qualite de curation a long terme.
- Aucune source n'aborde la memoire multi-agents (plusieurs agents partageant un meme vault avec conflits d'ecriture).
Pertinence ProbatioVault¶
Impact modere. Ces trois sources valident notre architecture existante et identifient des manques precis :
| Concept | ProbatioVault aujourd'hui | Gap |
|---|---|---|
| Index leger en contexte | memory/MEMORY.md (200 lignes max) | OK |
| Topic files on-demand | memory/*.md avec frontmatter | OK |
| Compounding knowledge | /gov-compounder (metriques + learnings post-story) | OK |
| Recherche semantique | FAISS + Ollama (/learnings, /specs, /contracts) | OK |
| Coherence proactive | /coherence (Prolog inter-EB) | OK |
| Importance scoring + decay | Pas d'equivalent | TODO #25 (confidence scoring learnings) |
| Maturity tiers | Pas d'equivalent | A considerer pour les learnings |
| Access tracking (quels learnings sont utiles) | Pas d'equivalent | Lie au TODO #25 |
| Session transcripts grep (Layer 3 Claude Code) | terminal.log enregistre mais jamais relu | TODO #27 (injection terminal.log dans REX) |
| Lint+Heal (detection proactive gaps/inconsistences) | Pas d'equivalent | Idee a explorer pour /gov-compounder et corpus veille (~100 fiches) |
| Quality gates sur documents (min lines, metadata, WIGS) | Gates sur artefacts governance uniquement | A considerer pour la base de connaissances (learnings, veille) |
| Extraction evergreen (concepts atomiques depuis artefacts) | Learnings par story, pas par concept | Enrichirait /gov-compounder |