💻 computer science

AMP: A Vendor-Neutral Wire Format for Agent Memory Operations

Ce document présente memorywire, un format de transfert JSON-Schema neutre vis-à-vis des fournisseurs et une implémentation de référence qui standardise les opérations de mémoire des agents à travers divers frameworks grâce à une interface unifiée, un canal de gouvernance et des adaptateurs de backend validés de manière empirique, visant à permettre l'interopérabilité sans concurrencer le Model Context Protocol.

Auteurs originaux : Thamilvendhan Munirathinam

Publié 2026-06-02

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Thamilvendhan Munirathinam

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous construisez une équipe d'assistants IA. En ce moment, chaque assistant possède sa propre façon de se souvenir des choses : l'un écrit des notes dans un journal en cuir, un autre utilise une application de post-it numériques, et un troisième garde des mémos vocaux. Ils parlent tous des « langues » de la mémoire différentes. Si vous voulez changer d'assistant pour passer à un autre système, vous devez réécrire toute son histoire à partir de zéro. Pire encore, si un assistant écrit quelque chose de bizarre ou de dangereux, il n'y a aucun gestionnaire pour vérifier avant que cela ne soit verrouillé dans son cerveau permanent.

memorywire est une nouvelle proposition pour corriger ce chaos. Considérez cela comme un traducteur universel et un système de classement standardisé pour les mémoires de l'IA.

Voici comment l'article le décompose, en utilisant des analogies simples :

1. Le Problème : La « Tour de Babel » de la mémoire de l'IA

Actuellement, les outils de mémoire IA populaires (comme mem0, Letta, Cognee) sont comme des pays différents avec des monnaies différentes.

Le problème : Si vous voulez déplacer la mémoire d'une IA du « Pays A » vers le « Pays B », vous ne pouvez pas simplement transférer l'argent liquide ; vous devez le faire fondre et le ré-émettre. Vous perdez des détails, et c'est coûteux.
Le gestionnaire manquant : Aucun de ces systèmes n'a de « gestionnaire » intégré pour réviser ce que l'IA écrit avant que cela ne devienne permanent. C'est comme laisser un élève écrire sur le tableau blanc de l'école sans qu'un professeur ne vérifie d'abord si les calculs sont corrects.

2. La Solution : Un « Fil de Mémoire » Universel (Memory Wire)

Les auteurs ont créé memorywire, qui est un format standard (une façon spécifique de packager les données) que tout système d'IA peut comprendre.

Les 5 Actions : Au lieu d'une liste désordonnée de commandes, memorywire définit exactement cinq choses qu'une IA peut faire avec la mémoire :
1. Se souvenir (Remember) : Écrire un nouveau fait.
2. Se rappeler (Recall) : Demander un souvenir.
3. Oublier (Forget) : Supprimer un souvenir.
4. Fusionner (Merge) : Combiner deux souvenirs similaires en un seul (pour éviter les doublons).
5. Expirer (Expire) : Supprimer automatiquement les vieux souvenirs (comme une « date de péremption »).
Les 4 Types de Mémoire : Tout comme les humains, le système classe les souvenirs dans quatre catégories :
- Sémantique : Des faits (ex : « Alice déteste les cacahuètes »).
- Épisodique : Des événements (ex : « Alice était nerveuse lors de son vol hier »).
- Procédurale : Des étapes de savoir-faire (ex : « Comment réserver un vol »).
- Émotionnelle : Des sentiments (ex : « Alice se sentait anxieuse à l'idée de voler »).

3. Le « Agent de Circulation » : Le Routeur

L'article introduit un « Routeur » qui agit comme un agent de circulation.

Fonctionnement : Lorsque vous demandez à une IA de « Se rappeler » quelque chose, le Routeur ne demande pas simplement à une seule base de données. Il crie la question à tous les différents systèmes de mémoire qui lui sont connectés en même temps.
Le tour de magie (RFF) : Le Routeur utilise une astuce mathématique appelée Fusion de Rang Réciproque (RRF). Imaginez trois amis qui devinent un nombre.
- Si l'Ami A dit « 5 », l'Ami B dit « 5 » et l'Ami C (le menteur) dit « 100 », le Routeur fait confiance aux deux amis qui sont d'accord.
- L'article prouve que même si l'un des systèmes de mémoire est piraté ou ment, cette astuce mathématique garantit que l'IA obtient la bonne réponse. C'est comme un filet de sécurité qui attrape le menteur.

4. L'« Humain dans la boucle » : La Porte d'Approbation

C'est une fonctionnalité majeure. Le système permet un flux de travail de type « Diff-and-Approve » (Comparer et Approuver).

Le scénario : Une IA veut écrire un nouveau souvenir : « L'utilisateur est allergique aux cacahuètes. »
La porte : Au lieu de l'enregistrer immédiatement, le système fait une pause. Il montre à un réviseur humain un « diff » (une comparaison de ce qui est nouveau par rapport à l'ancien).
La décision : L'humain clique sur « Approuver » ou « Rejeter ». Ce n'est qu'à ce moment que le souvenir est sauvegardé. Cela empêche l'IA d'écrire accidentellement des faits faux ou dangereux.

5. Ce qu'ils ont réellement testé (Les Résultats)

Les auteurs n'ont pas inventé un nouveau cerveau magique ; ils ont simplement mieux organisé les outils existants. Ils ont testé leur système avec :

Vitesse : C'était très rapide (environ 40 millisecondes pour mémoriser ou se rappeler quelque chose).
Précision : Tested with 42 questions, the system found the correct answer 100% of the time in the top 5 results. (An additional 8 trick questions were used to ensure the system didn't hallucinate.)
Sécurité : Ils ont tenté de « pirater » le système en faisant mentir l'une des bases de données de mémoire. L'« Agent de Circulation » (RRF) a réussi à ignorer le menteur et à conserver les bonnes réponses.
Compatibilité : Ils ont testé le système contre 5 systèmes de mémoire existants. Il fonctionnait parfaitement avec ceux construits sur des bases de données standards (SQLite et PostgreSQL) et fonctionnait suffisamment bien avec les autres, prouvant qu'il peut parler différentes « langues ».

L'essentiel

L'article affirme que memorywire n'est pas un nouveau type d'intelligence artificielle. C'est un protocole standardisé. C'est le « port USB-C » pour la mémoire de l'IA. Cela permet à différents systèmes d'IA de se brancher sur la même banque de mémoire, garantit que les mauvaises données peuvent être filtrées par des humains, et protège le système même si une partie du réseau est compromise.

Les auteurs sont honnêtes : ils ne prétendent pas que ceci est la solution finale ou parfaite. Ils le publient en tant que « version 0 » (un brouillon) pour obtenir des commentaires, avec l'objectif d'en faire un standard que tout le monde adopte, de la même manière que le Model Context Protocol (MCP) devient un standard pour les outils d'IA.

Résumé technique : memorywire – Un format de fil (wire format) neutre vis-à-vis des fournisseurs pour les opérations de mémoire d'agents

1. Le Problème : Des cadres de mémoire isolés

Le paysage actuel des cadres de mémoire pour agents (ex: mem0, Letta/MemGPT, Cognee, Zep/Graphiti, MemoryOS, MemTensor) est caractérisé par une hétérogénéité. Chaque cadre livre son propre SDK, sa propre disposition de stockage, son propre vocabulaire opérationnel et un cycle de vie implicite pour la création et la suppression d'enregistrements. Il n'existe pas de « format de fil » partagé.

Ce manque de standardisation crée trois problèmes principaux :

Intégration et migration sur mesure : Intégrer un agent avec un nouveau backend ou migrer entre des cadres nécessite des adaptateurs personnalisés. La perte de données au niveau des champs est courante lorsque les cadres sources encodent plus d'états que le modèle de données de la cible ne peut en supporter.
Absence de gouvernance partagée : Aucun cadre ne fournit actuellement un flux de travail standardisé de type « diff-and-approve » (différence et approbation) où des réviseurs humains peuvent auditer les écritures avant qu'elles n'entrent dans le stockage à long terme. Les opérateurs doivent construire des couches de gouvernance personnalisées, qui peuvent être contournées par le cadre sous-jacent.
Stagnation algorithmique vs lacunes protocolaires : L'article soutient que les algorithmes de base (recherche vectorielle, fusion de classement réciproque, FSM, consolidation STM/LTM) sont bien compris. La lacune ne réside pas dans la performance de la récupération, mais dans l'absence d'un protocole partagé pour composer ces composants à travers différents environnements d'exécution et backends.

2. Méthodologie et Architecture

L'article présente memorywire, un format de fil neutre vis-à-vis des fournisseurs et une implémentation de référence conçu pour standardiser les opérations de mémoire des agents.

2.1 Conception du format de fil

Le protocole est défini via JSON Schema 2020-12 et est agnostique au transport (REST, JSON-RPC, etc.). Il définit :

Cinq opérations de base : remember (écrire), recall (lire), forget (supprimer), merge (dédupliquer) et expire (application de la politique TTL).
Quatre types de mémoire : Sémantique, Épisodique, Procédurale et Émotionnelle, tirés des taxonomies des sciences cognitives (Tulving, Squire).
Protocole MemoryStore : Un Protocol Python définissant l'interface pour les backends. Les backends déclarent leurs capabilities (capacités) (ex: vector, graph, procedural), permettant à un routeur de composer des magasins hétérogènes sans que l'appelant ait besoin de connaître les contraintes spécifiques du backend.

2.2 Implémentation de référence

Les auteurs fournissent une implémentation de référence en Python 3.11+ comprenant :

Cinq adaptateurs de backend : sqlite-vec, mem0, Letta, Cognee et pgvector. Ces adaptateurs mappent le format de fil vers leurs modèles de données internes respectifs, en gérant la perte de fidélité (ex: en encodant les champs sous forme de balises de métadonnées) si nécessaire.
Routeur de mémoire (Memory Router) : Un routeur de diffusion (fan-out) qui exécute des opérations sur $N$ $N$ magasins enfants en parallèle.
- Fusion de rappel (Recall Fusion) : Utilise la Fusion de Classement Réciproque (RRF) comme algorithme par défaut ( $k=60$ ), qui est indépendant des scores et additif. Il supporte également la fusion MAX et weighted (pondérée).
- Boost de graphe (Graph Boost) : Un boost optionnel d'un saut (one-hop) dans le graphe pour les éléments dont les voisins sont également présents dans l'ensemble fusionné.
- Tolérance aux pannes : Utilise asyncio.gather avec return_exceptions=True pour garantir qu'un seul backend défectueux ou indisponible ne fasse pas planter l'ensemble de l'opération de rappel.
Mémoire procédurale : Stocke les machines à états finis (FSM) sous forme de blobs sérialisés en JSON compatibles avec pytransitions, avec une validation stricte pour empêcher l'exécution de code à distance (RCE) via l'injection de callbacks.
Transformateur STM/LTM : Une tâche de fond asynchrone qui évalue les éléments à court terme en fonction de la récence, de la saillance et de la confiance, pour les promouvoir vers le stockage à long terme ou les évincer.

2.3 Canal de gouvernance

Une caractéristique clé est le modèle Co-memorize, formalisant un flux de travail de type « diff-and-approve ».

Les écritures marquées avec approval_required=true sont mises en attente derrière un sentinelle (PENDING_APPROVAL_DELETED_AT = -1) et restent invisibles au rappel jusqu'à ce qu'un réviseur humain les valide ou les rejette via une interface fournie.
Un journal d'audit de type append-only sert de source unique de vérité pour toute la gouvernance et les événements de mutation.

3. Contributions Clés

L'article présente cinq contributions spécifiques :

C1. Spécification du format de fil : Un protocole basé sur JSON Schema pour cinq opérations sur quatre types de mémoire, explicitement versionné avec une politique de changement de rupture (breaking change) jusqu'à la v0.5.
C2. Implémentation de référence : Un SDK Python prêt pour la production avec cinq adaptateurs de backend, un routeur parallèle utilisant RRF, et un modèle de tolérance partielle aux défaillances.
C3. Interface de gouvernance (UI) : Une implémentation du modèle diff-and-approve qui s'intègre de manière transparente avec n'importe quel adaptateur de backend.
C4. Évaluation empirique :
- Un micro-benchmark sur 100 faits et 50 requêtes.
- Une expérience de fusion adversaire testant la robustesse contre les backends malveillants.
- Une suite de conformité cross-adaptateur de 16 scénarios.
C5. Modèle de menace et artefacts : Un modèle de menace à six adversaires avec des atténuations au niveau de la ligne de code et des artefacts de données ouvertes permettant la reproductibilité totale des affirmations.

4. Résultats

4.1 Performance du micro-benchmark

Sur un corpus de 100 faits rédigés à la main et 50 requêtes étiquetées (utilisant all-MiniLM-L6-v2 et sqlite-vec) :

Recall@5 : 1.000 sur 42 requêtes étiquetées (paraphrase, correspondance exacte et multi-hits).
Latence : Ingest p50 = 37,8 ms ; Recall p50 = 40,6 ms.
Précision : 0,214 (bornée par le ratio d'IDs d'or par requête).
Gestion de l'absence de correspondance (No-Match) : 0/8 sondes de "pas de correspondance" ont retourné des faux positifs (bien que l'article note que cela est dû à un choix délibéré de la conception v0 de retourner jusqu'à $k$ hits sans seuil de pertinence).

4.2 Expérience de fusion adversaire

L'étude a testé la robustesse des algorithmes de fusion contre un "backend malveillant 1 sur N" qui injecte des IDs contrôlés par l'attaquant au rang 0.

RRF : A maintenu un Recall@5 = 1.000 à travers tous les budgets d'attaque ( $K \in \{0, 5, \dots, 50\}$ ). L'indépendance du score de RRF empêche un magasin malveillant de dominer le résultat fusionné.
MAX : S'est effondré immédiatement à $K=5$ , avec un Recall@5 tombant à 0,500 et un taux de fuite de 80 % (80 % des IDs retournés étaient contrôlés par l'attaquant).
Weighted : A performé de la même manière que RRF lorsque les poids étaient égaux.

4.3 Conformité cross-adaptateur

Une suite de 16 scénarios invariants du protocole a été exécutée contre les cinq adaptateurs (80 cellules au total).

Résultats : 68 PASS, 12 SKIP, 0 FAIL.
Analyse : Les adaptateurs basés sur SQL (sqlite-vec, pgvector) ont passé tous les scénarios. Les adaptateurs enveloppant des SDK (mem0, Letta, Cognee) ont sauté des scénarios liés à des fonctionnalités manquantes dans leurs amonts (ex: absence de namespaces user_id, absence d'IDs stables par enregistrement, ou absence de gardes de politique vide). Ces sauts ont identifié des zones spécifiques pour le resserrement de la spécification v0.2.

4.4 Benchmarks préliminaires de contexte long

Des exécutions préliminaires sur LongMemEval et LoCoMo montrent une amélioration significative après la correction d'un bug où le top-k ANN vectoriel était calculé avant le filtrage de l'agent :

LongMemEval : Amélioration de 0,286 à 0,417 (+46 % relatif).
LoCoMo : Amélioration de 0,018 à 0,150 (+8,3× relatif).
Les auteurs notent que ceux-ci sont préliminaires (n=10–12, 1 graine) et que l'embedder (all-MiniLM-L6-v2) est une référence faible ; le protocole lui-même est agnostique au modèle d'embedding.

5. Signification et Revendications

L'article cadre explicitement sa contribution non pas comme une nouvelle percée algorithmique, mais comme un emballage et une standardisation de composants établis (RRF, FSM, consolidation STM/LTM, flux de travail diff-and-approve).

Positionnement : memorywire est positionné pour composer avec le Model Context Protocol (MCP) plutôt que de rivaliser avec lui. Alors que MCP standardise l'utilisation des outils, il manque d'une primitive de mémoire native. memorywire comble cette lacune, pouvant servir d'extension MCP à l'avenir ou de standard autonome (via l'IETF).
Modestie : Les auteurs reconnaissent que memorywire v0 est un projet (draft) avec des droits réservés pour rompre la compatibilité jusqu'à la v0.5. Ils admettent que l'évaluation actuelle utilise de petits corpus synthétiques et des benchmarks préliminaires, les évaluations à grande échelle (5 graines × 200 questions) étant reportées à une version v2.
Valeur Fondamentale : La principale proposition de valeur est un protocole neutre en termes de lieu qui permet à n'importe quel client de parler à n'importe quel backend, permet aux agents de transporter la mémoire à travers les environnements d'exécution, et fournit une surface standardisée pour la gouvernance humaine sur les écritures de mémoire.

En résumé, memorywire offre un protocole pragmatique, empiriquement validé, pour résoudre la fragmentation de l'interopérabilité et de la gouvernance qui plague actuellement l'écosystème de la mémoire des agents.