Les agents qu'on construit aujourd'hui ne tiennent plus en un seul appel LLM : recherche multi-étapes, coding agents, assistants qui persistent entre sessions.
Le style "Claude Code" / DeepAgents — planification, sous-agents, systèmes de fichiers virtuels — est devenu le patron de référence pour les agents "longue durée" en 2025-2026.
Nos pipelines data (ingestion, exploration, reporting automatisé) ressemblent de plus en plus à ces agents : la question "où vit l'état, et pour combien de temps ?" devient centrale.
Objectif de cette session : vous donner un vocabulaire précis et partagé pour parler de mémoire d'agent, avant de rentrer dans le code en session 2.
Les deux outils qu'on va utiliser
LangGraph & DeepAgents, en une minute
LangGraph
Le framework d'orchestration d'agents de LangChain : on modélise un agent comme un graphe d'états (nœuds = étapes, arêtes = transitions), avec une gestion native de la persistance de cet état.
DeepAgents
Un harnais d'agent « batteries-included », construit au-dessus de LangGraph, explicitement inspiré du comportement de Claude Code : planification, sous-agents, filesystem virtuel — livrés par défaut plutôt qu'à coder soi-même.
Pourquoi ça compte pour ce talk : les deux traitent la mémoire comme citoyen de première classe — c'est pour ça qu'ils servent de fil rouge à toute la Session 1, avant même qu'on les revoie en détail en fin de session.
Le problème central
La fenêtre de contexte est finie
Tout ce qu'un LLM "sait" à un instant t tient dans un budget de tokens fixe, partagé entre :
system prompt + schémas d'outils + historique de conversation + documents récupérés ≤ N tokens
N = la taille de fenêtre de contexte du modèle utilisé — fixe pour un modèle donné (ex. 200k tokens pour Claude), mais jamais infinie.
Plus la conversation / la tâche s'allonge, plus ce budget se remplit — il faut choisir quoi garder.
Et ce n'est pas qu'un problème de place : l'étude « Context Rot » de Chroma (2025) montre que la qualité des réponses de 18 modèles frontières se dégrade avec la longueur du contexte, parfois bien avant la limite nominale — même sur des tâches qui ne demandent pas de "tout retenir".
« Empiler tout dans le contexte » n'est pas une stratégie de mémoire gratuite : c'est un choix qui a un coût de qualité, pas seulement de latence/coût $.
Définition
Qu'est-ce que la « mémoire » d'un agent ?
La mémoire d'un agent, c'est tout mécanisme qui permet de faire persister de l'information au-delà d'un seul passage dans le contexte du modèle — et de la ramener au bon moment.
Ce n'est pas les poids du modèle (ça, c'est ce qu'il a appris à l'entraînement — implicite, non modifiable à l'inférence).
C'est une question d'ingénierie logicielle : où stocker, comment indexer, quand écrire, quand relire, quand oublier.
Le champ académique a un nom pour l'architecture de référence : CoALA.
Cadre de référence
CoALA — Cognitive Architectures for Language Agents
C'est la taxonomie que reprennent (implicitement ou explicitement) la quasi-totalité des frameworks modernes, LangGraph et DeepAgents inclus.
Court terme Working memory
Le contenu actif du cycle de décision en cours : ce qui est littéralement dans la fenêtre de contexte à l'instant t. Volatile, non persisté par elle-même.
Long terme Long-term memory
Ce qui survit au-delà d'un cycle : trois familles, empruntées à la psychologie cognitive (slide suivante).
CoALA — Long-term memory
Trois familles de mémoire long terme
Épisodique
Traces d'événements passés : « au tour 12, l'utilisateur a dit X, l'agent a fait Y ». Mémoire autobiographique.
Sémantique
Connaissances factuelles, généralisées à partir de l'expérience : « le manager de l'utilisateur s'appelle Priya ». Faits, ontologie.
Procédurale
Le comment faire : compétences, règles, comportements appris — dans les poids du modèle (implicite), ou explicite (prompt, code, playbook).
Vous verrez cette même tripartition réapparaître, sous d'autres noms, dans LangGraph (Store) et DeepAgents (filesystem + skills).
C'est ce cycle retrieval ↔ learning autour d'une working memory limitée qui est, in fine, « le » problème d'ingénierie de la mémoire d'agent.
Retrieval
Comment on récupère de la mémoire
Basé sur des règles : filtres explicites (par utilisateur, par date, par type) — simple, prévisible, mais rigide.
Recherche sparse : mots-clés / BM25, qui combine trois signaux :
saturation de fréquence du terme — un mot répété 10× ne compte pas 10× plus,
IDF (rareté globale du terme dans le corpus) — plus un mot est rare, plus il est informatif,
normalisation par longueur de document — pour ne pas avantager les textes longs.
Résultat : bon rappel exact, faible sur le sens.
Recherche dense (embeddings) : on encode chaque souvenir en vecteur à l'écriture, la requête en vecteur à la lecture, puis on classe par similarité. C'est le mécanisme dominant aujourd'hui — c'est du RAG appliqué au propre passé de l'agent, pas seulement à des documents externes.
Un peu de maths (1/3)
La similarité cosinus
La seule formule vraiment nécessaire pour comprendre la recherche dense : on mesure l'angle entre deux vecteurs, pas leur norme.
cos(u, v) = (u · v) / (‖u‖ · ‖v‖)
u, v = les vecteurs d'embedding du souvenir et de la requête.
u · v = leur produit scalaire.
‖u‖ = la norme (longueur) du vecteur.
Résultat entre -1 et 1 (en pratique, souvent entre 0 et 1 pour des embeddings de texte).
1 = même direction (même sens) ; 0 = aucun rapport.
On embed chaque souvenir une fois, à l'écriture — et on ré-embed seulement la requête à chaque lecture.
C'est tout ce qu'il faut retenir en maths pour 90% des systèmes de mémoire vectorielle en production.
Chaque souvenir est un événement horodaté dans un memory stream. Pour décider quoi rappeler, on combine trois signaux :
score = αr·recency + αi·importance + αv·relevance
Recency — à quel point le souvenir a été consulté récemment (détail slide suivant).
Importance — la portée que le LLM lui-même a attribuée au souvenir à l'écriture (détail slide suivant).
Relevance — la similarité cosinus entre le souvenir et la situation actuelle (slide précédente).
(dans l'article, les trois α = 1 ; chaque terme est normalisé min-max dans [0,1] avant la somme, pour qu'aucun ne domine par pure question d'échelle)
Un peu de maths (3/3)
Recency : une décroissance exponentielle
recency = γΔt (γ = 0.995, Δt en « heures » depuis le dernier accès)
Un souvenir non consulté depuis ~140 « heures » de simulation a déjà perdu environ moitié de son poids.
Chaque lecture d'un souvenir remet son horloge à zéro — comme un cache LRU.
Importance & relevance
Importance : notée 1–10 à l'écriture, en demandant littéralement au LLM : « quelle est la portée de cet événement ? » (« se brosser les dents » → 2, « une rupture amoureuse » → 8).
Relevance : la similarité cosinus (slide précédente) entre le souvenir et la situation actuelle.
Consolidation
Reflection : de l'épisodique au sémantique
Sans consolidation, la mémoire long terme n'est qu'un journal brut qui grossit indéfiniment — de moins en moins exploitable.
Reflection (Generative Agents) : déclenchée quand la somme des scores d'importance récents dépasse un seuil (150 dans l'article). Le LLM reçoit les ~100 événements les plus récents et génère 3 questions à haut niveau, puis synthétise des insights citant leurs sources.
Résultat : un arbre de réflexion — les feuilles sont des observations brutes, les nœuds internes des abstractions de plus en plus générales (des réflexions peuvent réfléchir sur d'autres réflexions).
C'est l'ancêtre conceptuel direct de la « consolidation mémoire » / résumé hiérarchique qu'on retrouve dans presque tous les frameworks modernes (y compris LangGraph, session 2).
Depuis les articles 2023-2025 cités ci-dessus
Graphes de connaissances temporels : une mémoire qui invalide, plutôt qu'elle n'écrase
Rasmussen et al. (Zep), A Temporal Knowledge Graph Architecture for Agent Memory, 2025 — arXiv:2501.13956
Reflection (slide précédente) ne répond jamais à : que se passe-t-il quand un ancien insight s'avère faux ? Un vector store plat laisse simplement le fait obsolète traîner, en concurrence sur la similarité cosinus avec la correction.
Graphiti (le moteur open-source de Zep) stocke la mémoire sous forme de graphe où chaque arête porte une paire (valid_at, invalid_at) — les faits anciens sont marqués invalides avec provenance, jamais silencieusement supprimés ni silencieusement contredits.
Se superpose proprement à CoALA : nœuds épisodiques ≈ mémoire épisodique, entités/faits ≈ mémoire sémantique — la nouveauté, c'est la validité bi-temporelle que CoALA ne modélise pas.
Mise en garde sur les benchmarks : les chiffres du leaderboard LoCoMo pour Mem0/Zep/autres sont auto-rapportés sous des protocoles d'évaluation différents et ne sont pas directement comparables — à traiter avec méfiance toute affirmation isolée de « SOTA » dans ce domaine.
Ce qui tient dans la fenêtre du modèle : instructions système, fenêtre de messages récents, et des blocs de « core memory » éditables par le modèle lui-même.
External context (≈ disque)
Tout le reste, hors fenêtre : archival memory (mémoire archivée, faits/documents recherchés par embeddings) et recall memory (mémoire de rappel, historique brut complet et recherchable).
MemGPT — mécanique
Le modèle gère sa propre mémoire, via des outils
Le LLM décide lui-même, par des appels de fonction explicites, ce qui doit rester en RAM ou être paginé : core_memory_append, core_memory_replace, archival_memory_search, archival_memory_insert, conversation_search.
L'éviction n'est pas un daemon en arrière-plan : quand le contexte principal approche de son budget de tokens, le système injecte un avertissement de pression mémoire (memory-pressure warning) dans la conversation elle-même, et le LLM décide quoi évincer via un appel de fonction — de l'auto-régulation, pas du garbage collection.
MemGPT → Letta (2026) : le nom « MemGPT » désigne aujourd'hui surtout le patron de conception ; Letta est le framework/produit open-source maintenu (letta-ai/letta). Nouveauté 2026 : les « Context Repositories », une mémoire versionnée façon git pour les agents de code.
Comparatif
Cinq familles, un seul spectre
Approche
Complexité
Latence/coût
Fiabilité
Bon pour
Contexte brut (tout empiler)
Nulle
Croît avec l'historique
Se dégrade (Context Rot)
Prototypes très courts
RAG mémoire (embeddings)
Moyenne
Faible par tour
Bonne, mais rappel silencieusement incomplet
Personnalisation multi-session
MemGPT / Letta (paging OS)
Élevée
Appels outils supplémentaires
Dépend de l'auto-discipline du modèle
Session longue et multi-session
LangGraph Store
Faible si déjà sur LangGraph
Lookup peu coûteux
Élevée, explicite, testable
Personnalisation par utilisateur/org
DeepAgents (filesystem + sous-agents)
Moyenne (harnais opinionated)
+ d'appels LLM, mais contexte parent réduit
Forte pour tâches longues mono-session
Agents "longue tâche" (recherche, code)
Anthropic memory tool (fichiers côté client)
Faible
Appels outils supplémentaires, peu coûteux
Élevée — vous possédez stockage & validation
Progression d'agent multi-session, sans adopter un framework
Ces approches se combinent plus qu'elles ne s'excluent — DeepAgents, par exemple, s'appuie directement sur le Store de LangGraph (session 2).
Le pont vers la pratique moderne
« Context engineering » : le vocabulaire d'Anthropic
Anthropic formalise le contexte comme une ressource finie à rendement décroissant — et nomme 4 techniques qu'on retrouve, productisées, dans DeepAgents.
« Effective context engineering for AI agents » — anthropic.com/engineering
Les 4 techniques de context engineering
1. Compaction
Résumer une conversation qui approche la limite de contexte, puis repartir avec le résumé (+ les fichiers les plus récemment consultés).
2. Note-taking structuré
Un fichier de notes persistant hors de la fenêtre de contexte, pour survivre à une réinitialisation et reprendre où on en était.
3. Architectures multi-agents
Un agent « chef d'orchestre » synthétise ; des sous-agents spécialisés travaillent avec leur propre fenêtre de contexte, propre et isolée.
4. Retrieval juste-à-temps
Garder des références légères (chemins, identifiants) plutôt que le contenu complet, et ne le charger qu'au moment où on en a réellement besoin.
Anthropic, concrètement
L'outil mémoire : un vrai mécanisme, pas juste un nom
Depuis septembre 2025, Anthropic propose une réponse concrète au « note-taking structuré » : un outil memory que Claude peut appeler directement, sans framework requis.
Six commandes sur /memories
view, create, str_replace, insert, delete, rename — les mêmes primitives qu'un éditeur de texte, cantonnées à un seul répertoire.
Côté client par conception
Claude ne fait que demander des opérations sur fichiers ; votre application les exécute sur un stockage que vous possédez (disque, DB, S3 — les SDK fournissent un helper filesystem local). Anthropic ne voit ni ne stocke jamais les fichiers.
Impact mesuré (éval interne Anthropic) : +29% avec le context editing seul, +39% combiné à l'outil mémoire, et une réduction de 84% des tokens sur une tâche de recherche web à 100 tours — c'est la même idée « compaction + notes hors fenêtre » vue deux slides plus tôt, avec un chiffre dessus cette fois.
Outil mémoire vs. mémoire Claude.ai vs. « Dreaming » de ChatGPT
Quoi
Qui stocke
Qui décide ce qui est écrit
Pour
Outil API memory
Vous (côté client)
Claude demande, votre app peut valider/rejeter
Ingénieurs qui construisent des agents
« Memory » de Claude.ai (Topics)
Hébergé par Anthropic
Automatique, l'utilisateur peut voir/éditer/supprimer par sujet
Utilisateurs finaux qui discutent avec Claude
« Dreaming » de ChatGPT (OpenAI, 2026)
Hébergé par OpenAI
Entièrement automatique — réécrit les entrées sans qu'on le demande
Utilisateurs finaux, moins transparent par conception
Le choix de conception explicite d'Anthropic est l'inverse du « Dreaming » : Claude vous dit quand il utilise un souvenir et demande avant d'écrire une information sensible. C'est un arbitrage délibéré en faveur de la transparence, pas un manque de capacité.
Ce n'est pas qu'une question de longueur (rappel de l'intro) : la manière dont le contexte est organisé compte aussi.
Sur certaines tâches, les modèles font mieux sur un contexte long mais désordonné que sur un contexte long et logiquement cohérent — signe que « avoir tout sous la main » n'est pas neutre cognitivement pour le modèle.
Conclusion pratique : compacter, isoler, et récupérer à la demande n'est pas une optimisation de coût — c'est aussi une optimisation de qualité.
Transition
Où LangGraph et DeepAgents se situent
DeepAgents n'est pas un concurrent de LangGraph : c'est une couche opinionated au-dessus — sa contribution propre, c'est la métaphore filesystem + les sous-agents, pas un nouveau mécanisme de persistance.
Synthèse
Ce qu'il faut retenir avant la session 2
La mémoire d'agent = un problème d'ingénierie autour d'une fenêtre de contexte finie, pas un détail d'implémentation.
Taxonomie CoALA : working memory (actif, volatile) vs long-term memory (épisodique / sémantique / procédurale).
Récupération = recherche (souvent par embeddings/cosinus), éventuellement pondérée par recency + importance + relevance.
Sans consolidation (reflection), la mémoire long terme devient un journal brut inexploitable.
Deux philosophies d'implémentation dominantes en 2026 : MemGPT/Letta (le modèle gère sa mémoire via des outils) et LangGraph/DeepAgents (l'ingénieur structure explicitement checkpointer / Store / filesystem / sous-agents).
Glossaire (1/2)
Vocabulaire agent / LLM
Terme
Définition
Framework
Une bibliothèque logicielle qui impose une structure : on écrit son code à l'intérieur des règles qu'elle définit — par opposition à une simple librairie qu'on appelle depuis son propre code.
Harness (harnais d'agent)
L'ensemble du code qui entoure un LLM pour en faire un agent complet : boucle de décision, gestion des outils, de la mémoire, du contexte — le LLM seul ne "sait" pas boucler ou appeler des outils.
Opinionated
Qui impose des choix de conception par défaut plutôt que de tout laisser configurable (à l'opposé de "unopinionated"/neutre) — un compromis entre rapidité de mise en route et flexibilité.
Batteries-included
Livré avec tout ce qu'il faut pour être utile immédiatement, sans devoir assembler soi-même des briques tierces (expression empruntée à Python : "batteries included").
Model-agnostic
Qui fonctionne avec n'importe quel modèle LLM sous-jacent (Claude, GPT, ...), sans dépendance forte à un fournisseur.
Token
L'unité de texte qu'un LLM traite (environ un mot ou un fragment de mot) — c'est l'unité dans laquelle la fenêtre de contexte est comptée.
Embedding
Un vecteur numérique représentant le "sens" d'un texte, produit par un modèle dédié ; deux textes proches en sens ont des embeddings proches (cf. similarité cosinus).
RAG
Retrieval-Augmented Generation : injecter dans le prompt des documents pertinents récupérés dynamiquement, plutôt que de compter uniquement sur ce que le modèle a mémorisé à l'entraînement.
Glossaire (2/2)
Vocabulaire LangGraph / DeepAgents
Terme
Définition
Checkpointer
Le composant LangGraph qui sauvegarde l'état d'un graphe à chaque étape, pour pouvoir le reprendre plus tard (= la mémoire courte terme).
Store
Le composant LangGraph de stockage clé/valeur namespacé, indépendant des threads (= la mémoire long terme).
Backend
Dans DeepAgents, le système qui détermine où vivent réellement les fichiers virtuels (état éphémère, Store persistant, disque...) ; plus généralement, la partie d'un système qui gère stockage/traitement, invisible depuis l'interface utilisateur.
Grounding
Le fait qu'un agent agisse sur / perçoive le monde réel (appels d'outils, environnement), par opposition au raisonnement interne pur.
Context engineering
La discipline (nommée par Anthropic) qui consiste à gérer activement ce qui entre dans la fenêtre de contexte d'un LLM, plutôt que d'y déverser tout ce qui est disponible.
Offloading
Déplacer une information hors de la fenêtre de contexte active (ex. vers un fichier) pour libérer du budget de tokens, quitte à la relire plus tard si besoin.
Sub-agent (quarantaine)
Un agent auxiliaire qui tourne dans sa propre fenêtre de contexte isolée ; seul son résultat final "traverse" vers l'agent parent — le bruit intermédiaire ne pollue pas le contexte parent (d'où "quarantaine").
Bibliographie (1/2)
Fondations académiques
Sumers, Yao, Narasimhan & Griffiths, Cognitive Architectures for Language Agents (CoALA), TMLR 2024 — arXiv:2309.02427
Park, O'Brien, Cai, Morris, Liang & Bernstein, Generative Agents: Interactive Simulacra of Human Behavior, UIST 2023 — arXiv:2304.03442 · ACM DOI 10.1145/3586183.3606763
Packer, Fang, Patil, Lin, Wooders & Gonzalez, MemGPT: Towards LLMs as Operating Systems, 2023 — arXiv:2310.08560
Zhang, Bo, Ma, Li, Chen, Dai, Zhu, Dong & Wen, A Survey on the Memory Mechanism of Large Language Model based Agents, ACM TOIS 2025 — arXiv:2404.13501 · DOI 10.1145/3748302
Wu, Liang, Zhang, Wang, Zhang, Guo, Tang & Liu, From Human Memory to AI Memory: A Survey on Memory Mechanisms in the Era of LLMs, 2025 — arXiv:2504.15965
Du, Memory for Autonomous LLM Agents: Mechanisms, Evaluation, and Emerging Frontiers, 2026 — arXiv:2603.07670
Chroma Research, Context Rot: How Increasing Input Tokens Impacts LLM Performance, 2025 — trychroma.com/research/context-rot