J'ai vu le fil de discussion de Sarah Wooders la semaine dernière et j'en ai immédiatement accepté la moitié.

Wooders, co-créateur de MemGPT (maintenant Letta), [a soutenu que la mémoire n'est pas un plugin, c'est le harnais](https://x.com/sarahwooders/status/2040121230473457921). Le harnais prend des décisions invisibles qu'aucun outil externe ne peut contrôler : ce qui survit au compactage, comment le contexte est chargé, si l'agent peut modifier ses propres instructions. "Demander de brancher de la mémoire sur un harnais d'agent, c'est comme demander de brancher la conduite sur une voiture."

Le cadrage est facile à transmettre. J'entends sans cesse la ligne de harnais répétée comme un arrière-plan établi, et non comme une demande d'inspection. C’est en partie parce que la moitié avec laquelle je suis d’accord est correcte.

## Les décisions invisibles sont réelles

[Claude Code a une hiérarchie de mémoire multi-niveaux intégrée au harnais](https://docs.anthropic.com/en/docs/claude-code/memory) : CLAUDE.md, état de session, règles de compactage, injection de messages système. Lorsque [Claude Code compacte](https://docs.anthropic.com/en/docs/claude-code/best-practices) une conversation de 100 000 jetons à 20 000, le harnais décide de ce qui survit. Aucun outil externe ne peut reproduire ou annuler cette décision.

Ahmed Kidwai, qui construit [Virtual Context](https://github.com/virtual-context/virtual-context), a décrit la même structure depuis le siège de l'utilisateur dans [L'IA passe la majeure partie de sa vie à lire sur sa vie](https://open.substack.com/pub/virtualcontext/p/ai-spends-most-of-its-life-reading). Chaque tour peut rejouer le fil de discussion complet, donc la plupart des jetons d'entrée servent à relire ce qui s'est déjà passé. Lorsque la fenêtre se remplit, le compactage remplace l'historique brut par un résumé. Vous ne recevez pas de reçu détaillé de ce qui a disparu.

Au cours d'une seule session, les choix du harnais concernant ce qui entre dans la fenêtre contextuelle, ce qui est résumé et ce qui est supprimé constituent le système de mémoire efficace. Wooders a raison à ce sujet.

## L'argument suppose un harnais

Le fil conclut que vous devez utiliser un harnais axé sur la mémoire. Cette conclusion vous oblige à opérer à l’intérieur d’un seul.

Je ne sais pas. J'utilise Cursor comme interface principale, Claude Code pour des tâches spécifiques, ChatGPT pour les conversations et des scripts personnalisés pour l'automatisation. Cela représente quatre harnais, chacun prenant ses propres décisions invisibles sur ce qu'il faut retenir.

Les personnes avec qui je parle et qui construisent avec des agents utilisent trois à cinq outils. Chacun se compacte différemment, charge le contexte différemment, stocke l'état différemment. L'utilisateur devient la couche de synchronisation humaine entre eux tous.

L'ajout de mémoire intégrée au faisceau ne fait qu'empirer les choses, mais pas les améliorer. Chaque outil bénéficie d'une meilleure mémoire interne. Aucun d’eux n’est d’accord.

## Trois préoccupations, pas une

Wooders regroupe la gestion des fenêtres contextuelles, l'état de session et l'état durable en un seul concept qu'elle appelle « mémoire ». Ceux-ci sont architecturalement distincts.

**Gestion des fenêtres contextuelles** : ce qui tient actuellement dans l'invite, ce qui est compacté, ce que le modèle voit ce tour-ci. Il s'agit d'un souci de harnais. Wooders a raison.

**État de session** : persiste dans une conversation. C’est aussi un souci de harnais.

**État durable** : persiste dans les sessions, les outils et les agents, avec provenance et versionnage. Il s’agit d’une infrastructure, pas d’un harnais.

Aucun harnais ne fournit un état multiplateforme déterministe, lié à un schéma, avec ajout uniquement, avec provenance. La gestion du contexte est le moteur. L'état durable correspond aux données de navigation. Il informe sur la conduite mais n’appartient pas à la transmission.

## Même le contexte peut être externalisé

Le [Contexte virtuel] de Kidwai (https://github.com/virtual-context/virtual-context) est un proxy qui se situe entre votre client et l'API LLM en amont. Le client définit une fenêtre contextuelle de 20 millions de jetons. La vraie fenêtre du modèle est de 200K. Le contexte virtuel compresse, indexe et pages entre eux. Une charge utile Claude Code de 937 000 jetons avec 52 chaînes d'outils s'effondre à ~ 65 000 signaux organisés.

Sur [LongMemEval](https://github.com/virtual-context/virtual-context#benchmark-results), Virtual Context a obtenu une précision de 95 % contre 33 % pour Claude Sonnet 4.5 avec un contexte brut complet, pour la moitié du coût. Le proxy fonctionne avec Claude Code, Cursor, OpenClaw ou tout client acceptant une URL de base. VCATTACH permet à deux clients de partager la même base de connaissances compactée sur toutes les plateformes.

Le mécanisme compte. VC ne contourne pas le harnais. Le harnais prend toujours ses propres décisions de compactage et de troncature et compose la requête API. VC intercepte cette demande en aval via une redirection d'URL de base. Lorsque le harnais tronque l'historique des conversations, VC détecte la troncature et récupère à partir de son propre magasin durable. Ce qui atteint le modèle est la fenêtre organisée de VC, et non la sortie brute du harnais.

Wooders a raison : aucun outil externe ne peut contrôler les décisions internes du harnais. Mais un proxy placé entre le harnais et l’API peut observer ces décisions et les annuler partiellement. Le harnais envoie 937 000 jetons après son propre compactage. VC envoie 65 000 de signal sélectionné au modèle. Le harnais gère toujours la boucle d'outils et l'agent. La couche qui décide de ce que le modèle voit réellement vit à l’extérieur.

Cela laisse trois couches, pas deux. Le harnais exécute l'agent. Une couche de gestion de contexte facultative peut se situer entre le harnais et l'API. Et une couche d'état durable se trouve sous tout, conservant ce qui est vrai quelle que soit la façon dont le contexte d'une session est géré.

## Contrôle contre valeur

Un outil externe ne peut pas contrôler les décisions de compactage du harnais. Vrai. Mais la question n’est pas de savoir si une couche étatique contrôle le compactage. Il s'agit de savoir si elle apporte de la valeur à la mémoire native du harnais.

La plupart des mémoires natives du harnais sont éphémères. Letta est l'exception : elle conserve la mémoire d'une session à l'autre, de par sa conception. Mais même la mémoire de Letta est spécifique à un outil, non portable et non déterministe. L'agent décide quoi stocker et quand via des appels d'outils pilotés par LLM, de sorte que la même conversation peut produire différents états de mémoire. Le curseur ne peut pas le lire. Claude Code n'arrive pas à le lire. Une couche d’état durable est multiplateforme, déterministe, versionnée et traçable jusqu’à la source.

Vous n'avez pas besoin de contrôler le harnais pour avoir de la valeur. Vous devez survivre aux décisions du harnais. L’état durable, composé uniquement d’ajouts, survit grâce à sa conception. Lorsqu'un harnais compacte le contexte, la couche d'état détient l'enregistrement complet. Lorsque vous ouvrez un autre outil demain, la couche d'état contient ce que vous avez stocké hier.

## Déclenchement versus transport

Nicolò Boschi (Hindsight/Vectorize) [d'accord avec Wooders](https://x.com/nicoloboschi/status/2042145292632379598) : "Utiliser la mémoire via MCP et espérer que le modèle stockera et recherchera des informations dans la mémoire est sans espoir." L'inquiétude est réelle. Si le modèle doit décider quand stocker et récupérer, il peut oublier de stocker. Il peut ignorer la récupération lorsque cela est important.

Au lieu de MCP, Hindsight utilise des [hooks](https://docs.anthropic.com/en/docs/claude-code/hooks) : des scripts qui exploitent s'exécutent automatiquement lors d'événements du cycle de vie comme le démarrage de la session, la soumission rapide ou l'achèvement de l'outil. Aucun LLM ne décide de les licencier. Le plugin Claude Code de Hindsight utilise quatre hooks de cycle de vie pour conserver automatiquement chaque conversation et rappeler automatiquement à chaque invite. Ça marche.

Mais cet argument confond deux choses : comment la mémoire est déclenchée et où elle se trouve.

Les hooks de Hindsight appellent l'API Hindsight. Ils n'écrivent pas dans la mémoire intégrée du harnais. Les crochets sont le déclencheur. Le serveur externe est le stockage. Cette séparation représente toute l’architecture. Un hook qui écrivait dans la mémoire native de Claude Code hériterait des mêmes limitations : éphémère, non portable, invisible pour Cursor demain.

Les crochets résolvent le problème de déclenchement. Ils ne résolvent pas le problème du stockage. Tout système de mémoire durable a besoin des deux.

Les crochets sont largement disponibles, mais pas universellement. Claude Code dispose d'un système de plugins avec plus de 12 événements. Le curseur a hooks.json avec plus de 14 événements en version bêta. OpenCode propose plus de 20 événements, notamment le contrôle du compactage et l'injection d'invites système. Le Codex a des hooks de session avec des hooks au niveau des outils en cours de développement. ChatGPT et l'application Web Claude restent uniquement MCP. Hindsight lui-même fournit un serveur MCP exactement pour ces cas.

La réponse est des crochets lorsqu'ils sont disponibles, MCP là où il n'y en a pas, les deux écrivant sur la même couche d'état durable sous chaque harnais. "MCP est sans espoir" est une déclaration sur le déclenchement de la fiabilité, et non sur l'endroit où la mémoire devrait résider.

## Les calques sont complémentaires

Cinq harnais prenant cinq décisions différentes de compactage et de contexte produisent cinq versions différentes de ce que l'agent sait. L'analogie de la « conduite » fonctionne pour la gestion du contexte. Il tombe en panne lorsque vous conduisez cinq voitures et que vous avez besoin de données de navigation cohérentes sur chacune d'elles.

La gestion du contexte et l’état durable ne sont pas en concurrence. Un harnais exécute l'agent et la boucle d'outils. Une couche de contexte, intégrée ou externe, gère ce que le modèle voit à chaque tour. Une couche d'état gère ce qui est vrai dans les sessions et les outils. Aucun harnais ou proxy de contexte n'offre une vérité, une provenance, un déterminisme, une validation de schéma ou un accès multi-outils vérifiables. L’argument en faveur d’une mémoire intégrée au harnais est simultanément l’argument en faveur d’une couche d’état partagée sous chaque harnais.

## Ce que je construis

Je construis [Neotoma](https://neotoma.io), une couche de mémoire structurée qui vit sous n'importe quel harnais : résolution d'entité, chronologies, provenance, déterminisme, accès multiplateforme.

Ces fils de discussion ont changé ce que je construis ensuite. J'avais traité MCP comme la seule surface d'intégration. Maintenant, j'ajoute des hooks en tant que couche d'extension du cycle de vie. MCP reste l'interface principale de l'agent.

La séparation est délibérée. MCP est propriétaire du contrat de l'agent : instructions chargées une fois au démarrage de la session, outils de stockage structurés que l'agent appelle avec une connaissance contextuelle complète. Les hooks sont propriétaires du contrat de harnais : événements du cycle de vie que l'agent ne contrôle pas. Un hook `UserPromptSubmit` récupère automatiquement les entités pertinentes avant que l'agent ne voie chaque invite. Les hooks `PostToolUse` capturent chaque modification de fichier et chaque commande shell sous forme d'observations. Un hook `Stop` persiste la conversation brute si le propre magasin de fermeture de l'agent a été manqué. Un crochet « PreCompact » observe ce que le harnais est sur le point de jeter.

Le résultat est un plancher de fiabilité en dessous du plafond de qualité MCP. Sans hooks, MCP fonctionne comme aujourd’hui. Sans MCP, les hooks fournissent une capture d'observations brutes mais pas d'extraction d'entités structurées. Les deux ensemble permettent une récupération déterministe, une observation passive, une conscience du compactage et une récupération en cas d'accident.

Cela diffère de l’approche de Hindsight. Hindsight capture les transcriptions brutes via des hooks, puis exécute un LLM distinct côté serveur pour extraire les entités. Cela signifie qu'un deuxième modèle juge ce qui compte, avec un coût et une latence supplémentaires par opération. Neotoma maintient l'extraction d'entités pilotée par un agent : le même modèle qui comprend la conversation effectue l'extraction à un coût LLM marginal nul. Les hooks fournissent la couche de fiabilité en dessous, pas l’intelligence.

Les plugins pour Claude Code, Cursor, OpenCode et Codex viennent ensuite. Les crochets écrivent dans Neotoma, pas dans la mémoire intégrée du harnais. Tous atteignent la même couche d’état durable, par des hooks lorsqu’ils sont disponibles et par MCP lorsqu’ils ne sont pas disponibles.

Wooders a raison de dire que le harnais possède le contexte. Boschi a raison de dire que les crochets battent MCP pour la fiabilité de déclenchement. Kidwai montre que même la gestion du contexte peut être externalisée. La question qu’aucun d’eux n’aborde est de savoir à qui appartient la vérité lorsque vous utilisez cinq harnais. Cette réponse doit vivre au-dessous d’eux tous.