Un agent reprend un projet après plusieurs jours. Il retrouve le code, mais ignore pourquoi l’équipe avait écarté une modification ou quel résultat devait encore être vérifié. Une mémoire peut lui rendre ce contexte disponible. Elle peut aussi lui transmettre une observation périmée ou une instruction qu’aucun responsable n’a approuvée.
La conception précise le stockage des informations mémorisées et les permissions qui autorisent leur utilisation par l’agent. Chaque note porte un statut permettant de distinguer une proposition, une information validée et une information retirée. Les recherches de l’agent appliquent ce statut avant de sélectionner le contexte transmis au modèle.
Distinguer le contexte courant et les connaissances persistantes
Un appel d’API sans état ne conserve pas, à lui seul, les appels précédents. L’application lui fournit les informations nécessaires. Certains produits ajoutent un historique, des résumés ou des fonctions de mémoire ; leurs capacités dépendent de leur configuration.
Quatre mécanismes méritent une distinction pratique. Ils peuvent coexister et ne forment pas une classification universelle des produits.
| Mécanisme | Fonction principale | Question à examiner |
|---|---|---|
| Base de connaissances versionnée | Conserver des documents identifiés et approuvés | Quelle version fait référence et qui peut la lire ? |
| Outil de mémoire | Permettre au modèle de demander des lectures et des écritures | Quel code autorise et exécute ces opérations ? |
| Édition ou compaction du contexte | Réduire les informations de la conversation courante | Quels éléments restent disponibles après la réduction ? |
| Service de mémoire persistante | Retrouver des informations entre sessions | Comment le service gère-t-il accès, versions et suppression ? |
L’outil de mémoire d’Anthropic illustre le deuxième mécanisme. Le modèle demande une opération, tandis que l’application gère le stockage et son exécution. Le chemin /memories ne désigne pas, à lui seul, un service de stockage administré par le fournisseur.
La compaction résume une conversation pour continuer à travailler dans une fenêtre de contexte limitée. Elle ne crée pas automatiquement une mémoire durable, partagée et gouvernée. L’application doit préciser ce qu’elle conserve, pendant combien de temps et comment elle le retrouve.
Faire entrer une information avec sa provenance
Prenons un agent qui participe au développement d’un logiciel. Après un essai, il observe qu’une procédure de migration échoue lorsque des dossiers anciens ne possèdent pas un champ devenu obligatoire. Cette observation peut être utile à la session suivante, mais elle doit rester reliée au test et à la version du code.
La note indique le fait observé, sa source, sa date et le périmètre de validité. Elle précise l’auteur de la proposition et son état d’approbation. Une référence au journal de test ou au correctif évite de transformer une conclusion locale en règle générale du projet.
L’équipe distingue cette observation des instructions qui définissent le mandat et les droits de l’agent. Une mémoire peut informer le travail sans autoriser une publication ou modifier les règles de sécurité. La séparation des fichiers aide à organiser cette distinction ; les permissions et le code doivent la faire respecter.
Un contenu reçu d’un document externe ne doit pas devenir une instruction privilégiée simplement parce que l’agent l’a mémorisé. Les mécanismes de validation examinent donc aussi l’origine des demandes de changement. Une proposition à fort impact peut nécessiter une approbation humaine avant toute utilisation ultérieure.
Le modèle de LLM Wiki présenté par Andrej Karpathy décrit une autre façon de compiler des sources en pages de connaissances. Pour une organisation, le choix de laisser le modèle entretenir ces pages doit s’accompagner d’une décision explicite sur leur autorité et leur validation.
Retrouver la bonne information au moment utile
Une mémoire persistante n’a pas besoin d’être intégralement injectée dans chaque requête. Selon l’architecture, l’agent peut consulter une liste, rechercher une information ou recevoir une sélection préparée par l’application. Cette sélection doit conserver les références et respecter les droits de l’utilisateur courant.
Dans notre exemple, l’agent retrouve l’observation lorsqu’il travaille sur la migration concernée. Une autre tâche ne nécessite pas de charger tous les incidents passés du projet. Limiter le contenu facilite la lecture et réduit le risque qu’une note sans rapport détourne le traitement.
Les tests utilisent une information pertinente présente, une information absente, deux versions contradictoires et une note interdite au rôle courant. L’équipe vérifie ce que l’agent rappelle et la manière dont il exprime une incertitude. La vérification compare la réponse aux passages que l’agent était autorisé à retrouver.
Les mots de passe et les jetons d’accès restent dans un système de gestion des secrets. Les données personnelles n’entrent en mémoire que lorsque la tâche et le cadre applicable le justifient. Les informations déjà maintenues dans le code ou le système métier gagnent généralement à être référencées plutôt que recopiées sans mécanisme de mise à jour.
Corriger, remplacer et retirer une note
Après correction du logiciel, l’observation sur la migration ne décrit plus nécessairement le comportement courant. Le processus de suivi marque la note comme remplacée ou expirée et conserve le lien vers la version qui a corrigé le problème. La recherche courante doit privilégier l’état applicable.
Le cycle de vie d’une note organise sa proposition, sa validation, sa publication pour les rôles autorisés, sa révision et son retrait ou remplacement. Chaque transition précise son responsable et sa conséquence sur les index et les caches. Ce modèle de cycle de vie reste une proposition d’architecture, à adapter au mécanisme utilisé.
La conservation de l’historique aide à expliquer les décisions passées. Elle ne justifie pas la conservation indéfinie de toutes les données. Une correction ou une suppression doit atteindre les représentations dérivées concernées, dans les conditions légales et techniques du système. Les sauvegardes demandent elles aussi une règle de conservation et de restauration qui évite de réintroduire une donnée retirée.
Lorsque deux sources se contredisent, le système peut exposer leurs dates et leur provenance, puis demander un arbitrage. La récence seule ne prouve pas la justesse. Le responsable de l’information détermine la référence applicable et documente cette décision.
Mesurer la valeur de la mémoire
Les tests mesurent les recherches répétées, la reprise d’une tâche après interruption et l’utilisation d’une décision validée lors d’une demande ultérieure. Il examine aussi les erreurs dues aux notes anciennes et le travail nécessaire pour les maintenir.
Le coût comprend l’écriture, la recherche, la relecture et les informations ajoutées au contexte. La mise en cache peut réduire certaines dépenses, mais son effet dépend du fournisseur et de la stabilité des entrées. Une mémoire volumineuse et rarement pertinente peut coûter davantage qu’un accès direct à la source au moment utile.
La note mémorisée conserve donc sa source, ses permissions et son statut. Ces métadonnées permettent de retrouver l’origine d’une information, d’expliquer sa présence dans le contexte de l’agent et de la retirer des recherches lorsqu’elle est périmée.
La validation des documents de référence est développée dans l’article sur une base de connaissances versionnée.