Contexte et diversité des formats

Les agents de développement stockent leurs souvenirs sous au moins quatre formes distinctes : un fichier AGENTS.md ou CLAUDE.md dans le dépôt, des fichiers .cursor/rules/*.mdc, un répertoire /memories alimenté par l’outil de mémoire d’Anthropic, et un serveur MCP qui exporte un graphe de connaissances au format JSONL. Chaque format possède son propre schéma, son propre protocole d’accès et aucune interopérabilité n’existe entre eux, ce qui contraint chaque outil à ré‑implémenter la logique de lecture/écriture.

Analyse des propositions existantes

Plusieurs initiatives tentent de combler ce vide. Copilot Memory associe chaque fait à une citation et propose l’oubli par défaut, mais reste enfermé dans l’écosystème Microsoft. LangGraph réduit le cœur du modèle à put(namespace, key, value). Graphiti introduit deux timelines : une pour la vérité du fait et une pour son enregistrement. Portable Memory de MacPaw propose un bundle .mem avec sérialisation byte‑reproducible, tombstones de suppression et signatures optionnelles, bien que son adoption soit encore limitée. Enfin, le Open Memory Protocol (avril 2026) décrit un échange ZIP contenant un manifeste, et le format COGX de Cognee agrège les spécifications de Mem0, Letta et Zep. Toutes ces solutions résolvent principalement l’export : elles permettent de transférer un jeu de souvenirs d’un fournisseur à un autre, mais ne définissent pas de mécanisme d’adressage partagé en temps réel.

Modèle de donnée proposé

Le texte propose un enregistrement type, présenté sous forme de front‑matter. Le modèle comporte les champs suivants : id (identité unique), address (niveau de portée : repo, projet, etc.), key (nom du souvenir), kind (type, ex. : lesson), written_by (type et nom de l’auteur, agent ou humain), content_type (format du corps, ex. : text/markdown), lifecycle (date d’expiration ou prolongation) et attributes (métadonnées spécifiques). Le corps du fichier contient le texte du souvenir. Le même enregistrement peut être sérialisé en JSON pour le transport via MCP.

---
spec: agent-memory/0.1
id: 8f0c2a6e-4b1d-4c7a-9e2f-3a5b6c7d8e9f
address:
  level: repo
  value: github.com/acme/checkout
key: tests-need-local-postgres
kind: lesson
written_by:
  type: agent
  name: claude-code
content_type: text/markdown
lifecycle:
  expires_at: null
  extended_by: write
attributes:
  vcs.pr: 482
  ci.run_url: "https://ci.example/runs/123"
---
Integration tests fail with `ECONNREFUSED 127.0.0.1:5432` unless Postgres is already running. Start it before `pnpm test`: docker compose up -d db

Vers une spécification partagée

En s’inspirant d’OpenTelemetry, la proposition suggère trois couches : des conventions de nommage (ex. : address.level, vcs.*, ci.*), un contrat d’opérations (write, read, list, search, archive) exposé via MCP, et des tests de conformité qui valident la perte nulle de données, la persistance des attributs inconnus et le respect du cycle de vie. Le stockage, le ranking, les embeddings et l’interface utilisateur restent hors du périmètre, afin de laisser la concurrence aux fournisseurs. Un registre neutre, hébergé par la Linux Foundation’s Agentic AI Foundation, garantirait la gouvernance indépendante du projet LoreKit ou de tout autre acteur commercial.