La mémoire des agents a besoin d'un standard commun comme OpenTelemetry

L'écosystème de la mémoire des agents IA est actuellement fragmenté, chaque outil utilisant sa propre structure de données et son mécanisme de stockage. Mads Thines soutient que ce paysage reflète l'état chaotique de l'observabilité logicielle avant 2019, nécessitant un standard unifié pour permettre aux différents agents de partager efficacement le contexte.

Ce qui s'est passé

La plupart des environnements de développement actuels reposent sur plusieurs systèmes disjointes pour conserver les informations entre les sessions. Une configuration typique peut inclure des fichiers d'instructions comme AGENTS.md ou CLAUDE.md, des répertoires gérés par l'agent tels que /memories, des faits hébergés provenant de services comme GitHub Copilot, et des graphes de connaissances distincts maintenus par des serveurs du Model Context Protocol (MCP). Ces quatre approches courantes ne peuvent pas lire les données les unes des autres, ce qui signifie que les informations acquises par un agent d'intégration continue restent invisibles pour un agent éditeur ou les outils suivants.

Cette fragmentation a entraîné une prolifération de solutions personnalisées, les développeurs construisant fréquemment leurs propres couches de mémoire pour combler des lacunes spécifiques. Bien que chaque format individuel soit logiquement cohérent, le résultat collectif est une reconstruction redondante de concepts fondamentaux : une note stockée à une adresse, valide pendant une certaine durée. Le problème central n'est pas un manque d'outils, mais l'absence d'accord communautaire sur un modèle de données partagé, un problème que le secteur de l'observabilité a résolu avec succès grâce à la création d'OpenTelemetry.

Comment cela fonctionne

Avant 2019, les fournisseurs d'observabilité se faisaient concurrence en créant des agents propriétaires, des bibliothèques d'instrumentation et des formats de données, rendant difficile le changement de fournisseur pour les utilisateurs. L'industrie a résolu ce problème en fusionnant OpenTracing et OpenCensus au sein d'OpenTelemetry, qui a établi quatre niveaux critiques d'accord. Ceux-ci comprenaient un modèle de données unifié pour les spans et les métriques, des conventions sémantiques pour le nommage, un protocole de transport unique appelé OTLP, et des implémentations de référence comme des SDK partagés. Les fournisseurs ont ensuite concouru sur le stockage et l'analyse plutôt que sur la collecte de données, permettant aux utilisateurs d'instrumenter leur code une seule fois.

La mémoire des agents manque actuellement de cet accord fondamental. Une spécification partagée proposée reprendrait l'approche d'OpenTelemetry en définissant des niveaux d'adresse standard, tels que global, projet ou dépôt, et en établissant des conventions sémantiques pour les attributs. Elle définirait également un contrat pour les opérations de base telles que l'écriture, la lecture et la recherche, exposées via MCP, tout en laissant les décisions relatives au stockage, au classement et à l'interface utilisateur aux soins des fournisseurs individuels. Cette séparation permet aux outils d'interagir sur la structure des données tout en se distinguant par des fonctionnalités à valeur ajoutée.

Détails clés

• Les formats de mémoire actuels incluent les fichiers d'instructions, les fichiers gérés par l'agent, les faits hébergés du dépôt, les blocs de contexte, les faits extraits, les magasins nommés et les graphes de connaissances, aucun d'entre eux n'étant mutuellement lisible.
• OpenTelemetry a réussi en convenant d'un modèle de données, de conventions sémantiques, d'un protocole et d'implémentations de référence, permettant aux fournisseurs de concourir sur l'utilisation des données plutôt que sur leur collecte.
• Les propositions existantes comme Portable Memory, Open Memory Protocol et COGX se concentrent principalement sur l'exportation de données entre fournisseurs plutôt que sur la mise en œuvre d'une adressage concurrentiel en temps réel.
• Une structure de record de mémoire proposée comprend des champs pour l'identité, l'adresse, la clé, le type de contenu, le cycle de vie et les attributs, le contenu réel de la mémoire étant stocké séparément.
• La spécification devrait enregistrer qui a écrit la mémoire, qu'il s'agisse d'un humain ou d'un agent, afin d'aider les lecteurs à évaluer la fiabilité et à atténuer les risques d'injection de prompt.
• LoreKit propose son schéma et son format sur disque sous licence MIT comme contribution concrète au développement d'un standard partagé.

Pourquoi c'est important

Pour les ingénieurs qui construisent des workflows agentiques, le manque actuel de normalisation signifie que le contexte est cloisonné dans des outils ou des fournisseurs spécifiques. Cela empêche les agents de collaborer efficacement, car une leçon apprise par un composant ne peut être utilisée par un autre sans intervention manuelle ou intégrations personnalisées complexes. À mesure que le nombre d'outils d'agents augmente, le coût de maintenance de ces systèmes de mémoire disjoints s'accroît, entraînant des efforts de développement redondants et des expériences utilisateur incohérentes.

L'adoption d'un standard partagé permettrait aux développeurs d'instrumenter leurs agents une seule fois et de les faire fonctionner de manière transparente sur différentes plateformes et outils. Elle favoriserait un écosystème dynamique où les fournisseurs se distinguent par des fonctionnalités avancées comme de meilleurs algorithmes de récupération ou des interfaces utilisateur, plutôt que d'enfermer les utilisateurs dans des formats de données propriétaires. Ce changement réduirait l'enfermement propriétaire (vendor lock-in) et faciliterait l'adoption de nouveaux outils par les équipes sans perte de contexte historique ni nécessité de réingénierie de leur infrastructure de mémoire.

Ce que vous pouvez faire

• Auditez votre environnement de développement actuel pour identifier tous les endroits où la mémoire des agents est stockée et notez les incompatibilités entre eux.
• Examinez les propositions existantes comme Portable Memory, Open Memory Protocol et COGX pour comprendre leurs approches en matière d'exportation et de sérialisation des données.
• Expérimentez avec le magasin hors ligne de LoreKit en exécutant npx @lorekit/cli install pour examiner comment des fichiers Markdown simples peuvent représenter des records de mémoire structurés.
• Comparez les records de mémoire générés par vos outils actuels avec la structure proposée pour identifier les champs manquants ou les attributs nécessaires à votre cas d'usage.
• Engagez-vous avec la communauté en partageant vos retours sur ce dont un format partagé aurait besoin pour soutenir votre workflow spécifique, en mettant l'accent sur l'adressage en temps réel et les mécanismes de confiance.
• Envisagez de contribuer à la discussion sur des terrains neutres, tels que l'Agentic AI Foundation de la Linux Foundation, pour aider à façonner les standards émergents.