L'avenir du développement d'agents IA ne dépend pas uniquement de la puissance des modèles, mais de la qualité de l'infrastructure qui les entoure, appelée « harnais ». Ce harnais comprend les boucles d'agents, la gestion du contexte et surtout la mémoire, transformant un modèle brut en un produit fonctionnel. Un débat majeur oppose ceux qui s'enferment dans des écosystèmes propriétaires, subissant ainsi des coûts de changement élevés, à ceux qui privilégient la portabilité. La mémoire reste le point de friction critique : si elle est stockée dans un harnais fermé, l'utilisateur ne possède pas véritablement ses données. Une solution émergente propose de placer la couche de mémoire en dehors du harnais, permettant à n'importe quel client de s'y brancher via des hooks, ou accroches, standards. Cette architecture permet de créer une mémoire unifiée fonctionnant simultanément sur Claude Code, OpenAI Codex et Cursor. Contrairement au protocole MCP (Model Context Protocol), qui oblige le modèle à décider activement d'appeler un outil pour accéder à des données, les hooks fonctionnent de manière déterministe et passive. Ils s'exécutent automatiquement à des événements précis du cycle de vie du système : démarrage de session, soumission d'une invite, utilisation d'outils ou fin de session. Le modèle ne consomme ainsi aucune attention ni contexte pour enregistrer les données, garantissant une traçabilité complète. L'architecture repose sur trois couches distinctes. La première couche, en ligne, utilise des hooks pour logger chaque événement dans une base de données persistante, ici Neo4j, sous forme d'une liste liée par session. Ces hooks reçoivent un flux JSON en entrée et peuvent renvoyer du JSON en sortie pour injecter du contexte dans la conversation, le tout sans appel de modèle supplémentaire pour rester rapides. La seconde couche, dite « phase de rêve », est un traitement hors ligne qui s'exécute par lot. Elle extrait les faits des événements récents, utilise un modèle IA pour synthétiser ces informations en mémoires durables au format Markdown, et les stocke dans le graphe. Cette phase met à jour les mémoires existantes plutôt que de simplement les ajouter, évitant ainsi une croissance incontrôlée des données. La troisième couche gère l'injection de cette mémoire dans les futures sessions. Au début d'une interaction, les informations de profil et les instructions pertinentes sont pré-chargées dans la invite système grâce aux hooks. De plus, lors de la soumission de chaque prompt utilisateur, les souvenirs associés sont recherchés et ajoutés dynamiquement. Bien que cette démonstration utilise uniquement les hooks pour l'injection, l'accès en direct par le modèle est également possible via des outils MCP pour permettre des opérations de lecture, écriture et suppression en temps réel. Cette approche garantit que la mémoire de l'agent est indépendante de l'outil utilisé. L'utilisateur peut passer de Cursor à Claude Code ou à Codex sans perte de contexte, de préférences ou d'historique de travail. Les trois environnements partagent le même contrat d'interface standardisé pour les hooks, permettant à un même script de gérer tous les clients. En séparant la logique de stockage et de synthèse de l'exécution des modèles, cette méthode brise les murs de jardinage des fournisseurs, offrant enfin une véritable propriété de la mémoire pour les utilisateurs d'IA. Le code source de cette implémentation est disponible publiquement pour faciliter l'adoption de ce standard.