Pour la mémoire d'agent locale et ouverte, la récupération est la valeur par défaut : les pipelines RAG, la recherche agentique, les magasins d'intégration et la traversée de graphiques sont ce que la plupart des constructeurs recherchent en premier. Une [enquête de 2026](https://arxiv.org/abs/2602.19320) conclut que la conception de la mémoire, et non la capacité du modèle, est désormais le facteur limitant pour les agents à longue durée de vie.

La récupération fonctionne bien pour le codage et l'exploration, mais elle s'interrompt lorsque les agents gèrent l'état en cours. Les principaux projets ([Zep](https://www.getzep.com/), [Mem0](https://mem0.ai/), [Letta](https://www.letta.com/), [LangMem](https://langchain-ai.github.io/langmem/)) ajoutent la résolution d'entité, la persistance et la structure de graphe, mais la convergence complète vers une conception structurée se heurte à des obstacles difficiles à adapter : requêtes axées sur le schéma, déterminisme identité, provenance en ajout uniquement et contrôle local d'abord.

## Pourquoi la récupération domine

La récupération correspond au cas d’utilisation qui place les agents sur la carte : le codage. Les bases de code sont exploratoires, vous ne savez souvent pas où se trouvent les choses et vous voulez « où gérons-nous X ? plutôt que de « répertorier chaque fonction avec sa provenance ». La recherche sémantique et le parcours ad hoc sont bien adaptés à cela.

La plupart des gens forgent leur intuition sur la mémoire des agents à partir du codage, où la récupération suffit. Le problème est de généraliser à partir de là. Pour l'état opérationnel tel que les tâches, les contacts, les transactions et les engagements, vous avez besoin de la même réponse la semaine prochaine, des ensembles complets et des pistes d'audit.

La récupération est également peu coûteuse à ajouter. Vous pouvez intégrer vos documents, connecter un magasin de vecteurs et disposer d'une mémoire de travail en un après-midi, sans conception de schéma, sans résolution d'entité et sans suivi de provenance. C’est un réel avantage, pas seulement l’inertie.

## Où la récupération s'interrompt

Les pauses apparaissent lorsque vous dépendez de la mémoire de l'agent pour la vérité.

**Réponses incohérentes.** La question « lister toutes les tâches du projet X » renvoie sept résultats un jour et quatre le lendemain. La récupération est réinférée à chaque fois. [La recherche confirme](https://arxiv.org/abs/2512.12818) que les agents confondent les informations entre les sessions et produisent des réponses temporellement incohérentes à mesure que la mémoire augmente.

**Rappel incomplet.** Les systèmes RAG avec un rappel de récupération inférieur à 80 % affichent [des taux d'hallucinations de 34 %, contre 20 % pour les systèmes dont le rappel est supérieur à 90 %](https://www.ijmsrt.com/storages/download-paper/IJMSRT25SEP018). La récupération basée sur l'intégration supprime la structure temporelle et relationnelle, et plus vous avez d'entités, plus le rappel est mauvais.

**Aucune provenance.** Lorsque vous demandez « d'où vient ce numéro ? » la récupération vous donne une réponse déduite de tous les morceaux qui ont fait surface. Il n'y a aucun lien entre la réponse et les enregistrements sources.

**Écritures irrécupérables.** Lorsqu'un agent écrase un contact ou fusionne des tâches, l'état précédent disparaît. Il n'y a pas de versionnage ni de restauration.

**Dérive entre outils.** Une tâche créée dans ChatGPT ne peut pas être interrogée de manière fiable dans Cursor. La mémoire du fournisseur est [incohérente de manière imprévisible](https://www.datastudios.org/post/can-chatgpt-remember-previous-conversations-memory-behavior-session-limits-and-persistence), et les configurations de récupération ouvertes ne sont pas non plus multi-outils par défaut.

## Ce que fournit l'état structuré

L'état structuré désigne un magasin avec des entités typées, des identifiants stables, des relations et des délais. La même requête renvoie le même résultat à chaque fois, et vous obtenez la provenance et la restauration.

| Besoin | Magasin structuré | Récupération |
|------|--------|-----------|
| Ensemble complet ("toutes les tâches du projet X") | Oui, par schéma et relations | Partielle ou déduite |
| Même réponse la semaine prochaine | Oui | Non |
| Tracer jusqu'à la source | Oui, chaîne de provenance | Non |
| Récupérer d'une mauvaise écriture | Oui, si l'ajout uniquement | Généralement non |
| Cohérence entre outils | Oui, si multiplateforme | Seulement si tous les outils partagent le même backend |
| Explorez l'inconnu | Possible mais pas sa force | Oui, c'est là que la récupération excelle |
| Résumé ponctuel | Exagération | Oui |

Un magasin structuré peut être sous forme de graphique, et celui que je construis, [Neotoma](https://neotoma.io), est : une couche de mémoire locale compatible MCP qui donne aux agents une source unique de vérité pour les entités, les relations et la lignée. Ce qui le distingue des « configurations graphiques » courantes en matière de récupération est la persistance, les identifiants canoniques et la provenance. J'ai écrit davantage sur [pourquoi la mémoire de l'agent a besoin d'une couche de vérité](/posts/truth-layer-agent-memory) ailleurs.

## Où le terrain se déplace

Les grands projets convergent vers un état structuré du côté de la récupération.

**[Zep](https://www.getzep.com/)/[Graphiti](https://www.getzep.com/)** crée un [graphique de connaissances temporelles](https://arxiv.org/abs/2501.13956) qui permet d'obtenir un gain de précision de 18,5 % par rapport à MemGPT et une réduction de latence de 90 %, et livre un serveur MCP. C’est l’état le plus proche de l’état structuré dans l’écosystème actuel.

**Mem0** utilise un [pipeline d'extraction et de consolidation en deux phases](https://mem0.ai/research) qui rapporte une précision 26 % supérieure à celle de la mémoire d'OpenAI, avec une variante graphique pour les relations entre entités. Il s’agit toujours principalement de récupération et la couche structurée est additive.

**[Letta](https://www.letta.com/)** (anciennement [MemGPT](https://docs.letta.com/guides/legacy/memgpt-agents-legacy)) [conserve tous les états dans une base de données](https://docs.letta.com/guides/agents/context-engineering) avec des blocs de mémoire modifiables. Il s'agit de l'« état structuré » le plus explicitement des projets d'origine de récupération.

**[LangMem](https://langchain-ai.github.io/langmem/)/[LangGraph](https://langchain-ai.github.io/langgraph/)** propose un [SDK de mémoire persistante](https://blog.langchain.com/langmem-sdk-launch/) avec des types sémantiques, épisodiques et procéduraux et une consolidation de la mémoire. La couche de persistance est réelle, mais le modèle d'accès principal intègre toujours la recherche.

**[Rétrospection](https://arxiv.org/abs/2512.12818)** ([Recherche 2025](https://arxiv.org/abs/2512.12818)) organise la mémoire en quatre réseaux logiques et atteint une précision de 83 à 91 % sur des benchmarks à long horizon. Cela montre la direction : la mémoire structurée avec des réseaux d'entités explicites surpasse la récupération plate.

## Les systèmes de récupération peuvent-ils converger entièrement ?

Certaines choses convergent naturellement, mais d’autres sont structurellement difficiles à moderniser.

**Ce qui converge déjà.** L'extraction d'entités et la structure des graphiques sont réelles dans Zep et [Mem0g](https://mem0.ai/). La persistance de la base de données est réelle dans Letta et LangGraph. Le suivi temporel est réel dans Graphiti. Ceux-ci comblent l’écart.

**La similarité d'abord par rapport au schéma d'abord.** Le modèle d'accès par défaut de Retrieval est « trouver des éléments similaires ». La valeur par défaut d'un magasin structuré est « requête par type, ID, relation ou heure ». Créer un schéma de système de récupération en premier signifie modifier la surface de l'API et les attentes des utilisateurs, et pas seulement ajouter une fonctionnalité.

**Identité implicite ou explicite.** La récupération traite deux morceaux comme la même entité si leurs incorporations sont proches. L'état structuré traite deux enregistrements comme la même entité s'ils partagent un identifiant canonique. La modernisation de l'identité déterministe signifie modifier chaque chemin d'ingestion.

**Upsert versus ajout uniquement.** Les systèmes de récupération écrasent généralement, tandis que le stockage par ajout uniquement préserve l'historique. Letta utilise des blocs de mémoire mutables et Zep suit l'évolution temporelle, qui est plus proche. La plupart des systèmes de récupération n'ont aucun concept d'écriture de l'historique.

**Provenance par consolidation.** Lorsque Mem0 consolide des faits ou que LangMem fusionne des mémoires associées, la provenance des sources originales est généralement perdue. La provenance qui survit à la fusion nécessite que le modèle de stockage la prenne en charge dès le départ.

**Déterminisme.** La récupération implique un classement et les résultats varient d'une exécution à l'autre. Les requêtes structurées sont déterministes : la même requête renvoie le même résultat. La suppression de la fonction de classement compromet ce qui rend la récupération utile. Ce sont des contrats de requête fondamentalement différents.

**Contrôle local d'abord.** Rendre un système véritablement local, sans dépendance au cloud ni télémétrie, entre en conflit avec le modèle commercial de la plupart des sociétés de mémoire. Il ne s’agit pas d’un obstacle technique ; c'est un problème structurel d'incitation.

Les systèmes de récupération peuvent accéder à mi-chemin à un magasin structuré, mais le dernier kilomètre nécessite des requêtes axées sur le schéma d'abord, une identité déterministe, une provenance par ajout uniquement, des résultats déterministes et des valeurs par défaut locales d'abord. Ces choix vont à l’encontre de l’architecture axée sur la récupération.

## Quelle récupération fait encore mieux

**Exploration.** Lorsque vous souhaitez trouver quelque chose dans vos notes sur l'appartement de Barcelone, vous ne connaissez pas le schéma ou le type d'entité. Récupération des bits pertinents sans modélisation préalable.

**Résumé.** Lorsque vous demandez ce que vous avez décidé avec l'entrepreneur, la récupération peut rechercher, extraire et résumer en une seule session. Vous n'avez pas besoin que cette réponse persiste ou corresponde exactement la prochaine fois.

**Parcours ad hoc.** ​​Lorsque vous demandez où les webhooks Stripe sont gérés, la disposition varie selon les bases de code et les documents. La récupération s'adapte sans graphique unifié.

**Faible coût initial.** Vous pouvez disposer d'une mémoire de travail en un après-midi. Pour tout ce qui ne nécessite pas d’exhaustivité, de cohérence ou de provenance, la récupération est suffisante et moins coûteuse.

## Lacunes dans l'état structuré et comment Neotoma les comble

**Surcharge de schéma.** Neotoma utilise un registre de schémas évolutif dans lequel l'extraction assistée par LLM propose des types et des relations lors de l'ingestion. Cela réduit le coût initial mais ne l’élimine pas. En pratique, l'agent examine et corrige les résultats de l'extraction au fil du temps, à mesure qu'il rencontre des incohérences.

**Complexité d'ingestion.** Neotoma calcule les identifiants canoniques basés sur le hachage à partir des propriétés d'identification, de sorte que la même entité obtient le même identifiant quelle que soit la source. C'est plus prévisible que la similarité basée sur l'intégration, mais cela dépend de la qualité de l'extraction : "Mark" et "Mark Hendrickson" hachent différemment jusqu'à ce que vous les fusionniez.

**Démarrage à froid.** Neotoma prend en charge l'ingestion à double chemin : vous pouvez télécharger des fichiers pour une extraction par lots ou accumuler l'état de manière incrémentielle via les conversations des agents. Ce n’est pas instantané, mais c’est plus rapide que d’attendre suffisamment de conversations pour créer un graphique utile.

**Coût d'ajout uniquement.** Le stockage augmente à chaque correction, ce qui rend la restauration et la provenance possibles. À l’échelle personnelle et opérationnelle, cela est gérable, mais il s’agit d’un véritable compromis : les requêtes visant à résoudre l’état actuel sont plus complexes.

**Ne remplace pas la récupération.** Neotoma fournit une récupération structurelle par type, ID, relation, plage de temps et voisinage graphique, et s'attend à ce que des outils de récupération tels que la recherche agentique et la recherche intégrée gèrent l'exploration. C'est un complément et non un substitut.

## Pourquoi je construis Neotoma

J'ai atteint les limites de récupération dans la pratique. Les tâches, les contacts et les transactions nécessitent des identifiants canoniques, un lignage et un accès multi-outils. Les choix de conception répondent directement aux obstacles à la convergence décrits ci-dessus.

**Schéma d'abord.** Les requêtes sont effectuées par type d'entité, ID, relation ou plage de temps. Il n’y a aucune similarité d’intégration dans le chemin de requête et les résultats sont déterministes.

**Identité basée sur le hachage.** La même entité obtient le même identifiant quelle que soit la source ou la session qui l'a introduite.

**En annexe uniquement.** Chaque fait remonte à sa source. Les corrections créent de nouveaux enregistrements et la restauration est possible.

**Outil croisé via MCP.** Une couche mémoire est accessible depuis n'importe quel client MCP : Cursor, ChatGPT, Claude ou Claude Code. Les mêmes données et les mêmes identifiants sont disponibles partout.

**Local d'abord.** Toutes les données résident dans SQLite et dans des fichiers locaux. Il n'y a pas de dépendance au cloud ni de télémétrie. Vous pouvez vérifier tout ce que fait le système.

[Neotoma](https://neotoma.io) est précoce. Il s'agit d'une [version développeur](/posts/neotoma-developer-release) : locale uniquement, CLI-first, avec résolution d'entité heuristique, évolution manuelle du schéma et aucune interface utilisateur Web. Ce qu'il fournit, c'est le contrat, et l'argument est que ce contrat est nécessaire pour les agents qui gèrent l'état en cours, et que la récupération à elle seule ne peut pas le fournir.

Le domaine converge vers la mémoire structurée. La question est de savoir qui construit la couche à laquelle vous faites confiance avec vos données et quelles garanties elle offre. Je veux que cette couche soit structurée dès le départ, et non ajoutée après coup. Local d'abord, ouvert, inspectable et sous le contrôle de l'utilisateur.