wal.sh
home > fr > research > 2026-agent-memory-systems · May 20, 2026

Architectures de mémoire d'agent : JITIR face au champ

agent memoryJITIRcloudflarememgptlettazepgraphitimem0a-memlangmemcli agentsproactive retrievalremembrance agent

Architectures de mémoire d'agent : JITIR face au champ
Un exercice de découpage : Cloudflare Sessions, MemGPT/Letta, Zep/Graphiti, Mem0, A-MEM, LangMem, et ce que font déjà les agents de code CLI

Table des matières

Version originale : English

1. Ce que « mémoire » désigne

« Mémoire d'agent » désigne au moins quatre choses distinctes. 

1. Journal de conversation : trace durable des messages et des appels d'outils.
2. Scratchpad de travail :   état mutable que l'agent réécrit en cours de tâche.
3. Faits appris :            assertions extraites, indexées pour la recherche.
4. Documents de référence :  gros documents chargés à la demande.

Les quatre n'ont ni la même discipline d'écriture, ni les mêmes lectures, ni le même coût dans la fenêtre de contexte. La plupart des frameworks qui offrent une seule API « mémoire » en confondent deux ou plus, sans le dire.

L'API Sessions de Cloudflare sert ici de découpage de référence. Les autres systèmes sont décrits par rapport à elle. JITIR est sur un axe séparé, que la mémoire réactive a presque laissé vide. L'étude CLI Coding Agents Q2 2026 traite le même problème un niveau plus bas, à la frontière du harness.

2. Découpage de référence : Cloudflare Sessions

L'API Sessions de Cloudflare (Cloudflare 2026) découpe la mémoire en quatre types de blocs. Chaque type est défini par un contrat de provider. Le contrat est un ensemble de méthodes sur un objet JavaScript. La Session détecte les méthodes présentes et génère les outils correspondants.

Type de bloc Méthodes du provider Présence dans le prompt Outil généré
readonly get() contenu complet (aucun)
writable get() + set() contenu complet + budget set_context
searchable get() + search() + set() nombre de résumés search_context
loadable get() + load() + set() liste des métadonnées load_context / unload
  • Le provider est le contrat. La capacité vient de la structure, pas d'une déclaration. Un provider qui a une méthode search() devient un bloc searchable. L'outil de recherche en découle mécaniquement.
  • Le system prompt est le schéma. À chaque tour, chaque bloc déclare son type au modèle dans le prompt, par les tags [readonly], [writable], [searchable], [loadable].
  • Toute lecture vient de l'agent. search_context et load_context sont des outils que le modèle appelle. Le substrat (Durable Object, R2, SQLite FTS5) ne fait rien de lui-même.

C'est le choix de presque tous les systèmes de mémoire en production.

  • Overlays de compaction. Les anciens messages sont résumés en overlays, rangés dans une table à part, appliqués à la lecture. Les messages d'origine ne sont pas supprimés. L'identité, la conversation, reste. Une valeur dérivée, le résumé, se pose dessus.
  • System prompt gelé. freezeSystemPrompt + withCachedPrompt séparent le prompt rendu de l'état sous-jacent. Un appel set_context écrit dans le provider. Le prompt rendu en cache ne change pas avant un refreshSystemPrompt explicite, à une frontière de tour. L'écriture et la lecture ne sont plus tressées.

3. Le champ, découpé

3.1. MemGPT / Letta (Packer et al. 2023) – mémoire virtuelle pour fenêtres de contexte

Le journal de conversation et le scratchpad sont séparés (recall contre main context). Les faits appris et les documents de référence vont tous deux en archival memory. L'agent doit les distinguer par ses propres conventions. La métaphore de la pagination d'OS décrit le contrat, pas la forme du stockage.

Le coût : le page-out est volontaire. Aucun noyau n'évince une page inutilisée quand la mémoire manque. Le modèle doit écrire en archival memory avant que le fait ne sorte de la fenêtre FIFO. L'échec est un oubli silencieux. Il passe pour de l'aisance.

3.2. Zep / Graphiti (Rasmussen and Gallagher 2025) – graphe de connaissances bitemporel

Chaque arête du graphe sémantique porte quatre horodatages : t_created, t_expired (temps de transaction) et t_valid, t_invalid (temps de l'événement). Un nouvel épisode peut invalider une arête en posant t_invalid. L'ancienne arête n'est pas supprimée.

Le traitement est orienté valeur : les faits s'accumulent et sont invalidés, jamais modifiés sur place.

Le coût : l'extraction des entités et l'invalidation des arêtes sont des jugements de LLM. Le graphe sort d'un extracteur qui peut se tromper.

3.3. Mem0 – store hybride géré, avec scopes

Le scope est réifié en axe de premier rang (user / session / agent). Les quatre types de blocs de Cloudflare tombent dans un seul store. L'extracteur LLM décide de ce qui est écrit. Ce qui est complecté : le jugement de l'extracteur sur ce qu'est un fait se confond avec le comportement du store.

3.4. A-MEM (Xu et al. 2025) – Zettelkasten à notes mutables

Chaque interaction devient une note atomique. Des liens bidirectionnels sont créés à l'insertion, selon la similarité sémantique. À l'étape d'évolution de la mémoire, le design devient orienté lieu : les notes anciennes sont modifiées. Vu sous l'angle de la valeur, c'est ce qu'il faut éviter partout où une piste d'audit est nécessaire.

3.5. LangMem – sémantique, épisodique, procédural dans LangGraph

Personne d'autre ne sépare explicitement la mémoire procédurale. « En résumant un email, la première phrase doit nommer l'action à faire » est une règle procédurale, pas un fait sémantique. LangMem la range comme mémoire, pas comme texte de prompt.

Le coût : un couplage serré aux machines à états de LangGraph. Sur le benchmark LOCOMO, la latence de recherche publiée est de 59,82 secondes au p95 (p50 : 17,99 s) (Chhikara et al. 2025). C'est inutilisable en interactif.

4. Agents de code CLI – la convention comme schéma

La comparaison des agents CLI (CLI Coding Agents Q2 – Memory and persistence) montre le même découpage un niveau plus bas, à la frontière du harness. Là, le schéma est fait de noms de fichiers, pas de méthodes de provider :

Sens Convention des agents CLI
Instructions au niveau du projet CLAUDE.md / AGENTS.md / GEMINI.md
Mémoire longue par catégorie ~/.claude/.../memory/ (répertoires typés)
Documents de référence chargeables .claude/skills/SKILL.md + AGENTS.md
Contexte projet extrait automatiquement Kiro : product.md tech.md structure.md

Le schéma est une convention, pas un type. La convention passe d'un harness à l'autre : Claude Code, Copilot CLI et OpenCode lisent maintenant SKILL.md. Mais elle ne déclare pas au modèle, dans le prompt, le contrat de chaque fichier.

4.1. winze – recherche sémantique sur la convention

winze est un serveur MCP avec recherche sémantique et un outil GUI de recherche et d'édition, sur une base de connaissances Markdown. Il rend la convention interrogeable. Le substrat est le même markdown en répertoires typés que les agents CLI gardent déjà. winze ajoute la méthode search() qui manque au système de fichiers nu. Un bloc readonly ou writable devient searchable. Les octets restent où ils sont.

  • Les écritures relèvent d'une curation humaine, pas d'une extraction. Par l'édition GUI, une personne écrit et révise les notes. Aucun extracteur LLM ne décide de ce qu'est un fait (au contraire de Mem0 et A-MEM). Il n'y a donc rien à complecter.
  • La recherche reste réactive. La recherche sémantique est un outil que l'agent appelle. winze est du côté du contrat réactif, avec les autres, pas sur l'axe JITIR plus bas.

C'est la leçon du search() de Cloudflare, au niveau des fichiers : la capacité est structurelle. winze fait partie d'une petite famille (basic-memory, sqlite-memory, memsearch). C'est l'instance Clojure/MCP. (h/t Clojure Deref, 2026-05-19.)

5. JITIR – une autre coupe

JITIR est sur un axe que les systèmes ci-dessus occupent à peine. La forme du stockage est ordinaire. Le contrat diffère.

5.1. Deux contrats

  • Contrat réactif : search(intent) -> candidates. Un agent ou un humain écrit l'intention. Le substrat répond aux requêtes.
  • Contrat proactif : observe(context) -> candidates pushed. Le substrat écrit l'ensemble des candidats. L'agent ou l'humain lit.

Ce qui sépare les deux contrats, c'est qui décide de regarder. Tous les systèmes ci-dessus suivent le contrat réactif. Ce contrat cache un mode d'échec : l'agent n'a pas cherché parce qu'il ne savait pas qu'il y avait quelque chose à trouver.

Antériorité : Rhodes (Rhodes 1997, 2000).

5.2. Consolidation proactive : Dreaming, exemple géré

Dreaming (Claude Managed Agents, research preview, 2026-05-06) occupe l'extrémité proactive de l'axe. Les systèmes réactifs écrivent aux frontières de tour et cherchent au moment de la requête. Dreaming lance un processus planifié, hors bande. Il lit un lot de transcripts de sessions passées contre le store existant. Il produit un store réorganisé pour les lectures futures. C'est le parent en production le plus proche du memory-manager d'arrière-plan de LangMem : la même forme, emballée comme service géré, avec une preview sur demande et une boucle d'évaluation (Outcomes) attachée.

Une écriture réactive ratée coûte une trajectoire. Une passe de consolidation ratée réécrit le substrat que liront toutes les sessions suivantes, sans rollback par session. Le pôle proactif achète une qualité de recherche amortie au prix d'un rayon d'impact à l'échelle du store.

5.2.1. Question ouverte : l'affirmation non destructive et le vide de gouvernance

Anthropic dit que la réécriture est non destructive. Cela n'a de sens que si l'ancien store survit comme artefact adressable et diffable. Sans versions conservées, ce n'est qu'une compaction avec pertes sous une étiquette rassurante. La place de la gouvernance est vide aussi : rien dans la preview ne dit qui fait la revue de dream(t) face à dream(t-1), ni selon quel invariant. En tuple : [reviewer:dreaming-agent:_@managed(store)]. Le reviewer manque.

5.2.2. Conditions de réfutation

F1 (affirmation non destructive). Si dream(t-1) n'est pas conservé comme artefact adressable et diffable, si la consolidation est une compaction avec pertes, F1 réfute l'étiquette. Ouvert, en attendant que le fournisseur confirme le versionnage du store.

F2 (primitive ou emballage). Dreaming est une architecture de mémoire distincte si et seulement s'il expose un mécanisme au-delà d'une planification gérée et d'un évaluateur de type Outcomes sur un store externe. Sans ce mécanisme, il faut le traiter comme l'emballage géré du pattern memory-manager de LangMem, et faire descendre l'entrée de « nouvelle architecture » à « pattern opérationnel ».

6. La case vide

Les blocs de Cloudflare se rangent sur deux axes binaires : où le contenu vit dans le prompt (toujours ou à la demande), et qui l'écrit (agent ou code). Une troisième ligne, initié par le substrat, est vide dans tous les frameworks de mémoire en production :

Où Lectures poussées à l'agent Écritures initiées par le substrat
Initié par le substrat forme JITIR (aucun système en production)

La case en bas à droite, où le substrat décide d'écrire, est approchée. Personne ne l'occupe. Le plus proche est Kiro, avec ses fichiers générés product.md / tech.md / structure.md : au premier lancement, le harness observe le dépôt et écrit une compréhension dérivée. Il le fait une fois, pas en continu.

7. Ce qui compose, ce qui complecte

Système Découplé Complecté
Cloudflare les quatre (typés par bloc) écritures et lectures au rendu
MemGPT/Letta journal / scratchpad / archive faits et référence en archival
Zep/Graphiti identité / état (bitemporel) sémantique et épisodique dans un graphe
Mem0 scope (user/session/agent) extraction fondue dans le stockage
A-MEM notes liées par similarité l'identité mute sur place
LangMem sémantique / épisodique / procédural opérations mémoire complectées au graphe
JITIR déclencheur séparé du store le consommateur est Emacs ; il faut un port
Dreaming consolidation proactive (planifiée) rayon d'impact à l'échelle du store

8. Voir aussi

9. Références

  • Cloudflare Agents (Cloudflare 2026) – API Sessions, quatre types de blocs (readonly, writable, searchable, loadable)
  • Packer et al. (Packer et al. 2023) – MemGPT : pagination en mémoire virtuelle pour le contexte des LLM
  • Rasmussen et al. (Rasmussen and Gallagher 2025) – Zep/Graphiti : graphe de connaissances temporel pour la mémoire d'agent
  • Xu et al. (Xu et al. 2025) – A-MEM : mémoire agentique auto-organisée
  • Chhikara et al. (Chhikara et al. 2025) – Mem0 : chiffres de latence LOCOMO cités pour LangMem
  • Rhodes (Rhodes 1997) – le Wearable Remembrance Agent : JITIR proactif au MIT Media Lab
  • Rhodes (Rhodes 2000) – thèse de doctorat qui formalise le Just-In-Time Information Retrieval
  • winze. Serveur MCP de mémoire agentique sur une base de connaissances Markdown. Via Clojure Deref, 2026-05-19. Même famille : sqlite-memory, memsearch.

10. Références

Chhikara, Prateek, Dev Khant, Saket Aryan, Taranjeet Singh, and Deshraj Yadav. 2025. “Mem0: Building production-ready ai agents with scalable long-term memory.” Arxiv preprint.
Cloudflare. 2026. “Agents: Memory.” 2026. https://developers.cloudflare.com/agents/concepts/memory/.
Packer, Charles, Sarah Wooders, Kevin Lin, Vivian Fang, Shishir G. Patil, Ion Stoica, and Joseph E. Gonzalez. 2023. “Memgpt: Towards llms as operating systems.” Arxiv preprint.
Rasmussen, Preston, and Daniel Gallagher. 2025. “Zep: A temporal knowledge graph architecture for agent memory.” Arxiv preprint.
Rhodes, Bradley J. 1997. “The wearable remembrance agent: A system for augmented memory.” Personal and ubiquitous computing 1 (3). https://doi.org/10.1007/BF01682024.
———. 2000. “Just-in-time information retrieval.” MIT Media Lab. https://www.bradleyrhodes.com/Papers/rhodes-phd-JITIR.pdf.
Xu, Wujiang, Zujie Liang, Kai Mei, Hang Li, Juntao Xie, and Wei Liu. 2025. “A-mem: Agentic memory for llm agents.” Arxiv preprint.

Vu à