Audit de récupération

Le constructeur de contexte décide de ce qui est chargé dans un agent au démarrage. L'audit en est le pendant durant le travail lui-même : il montre ce que l'agent recherche réellement (search / recall) et ouvre (get_note), et s'il a trouvé quelque chose. Cela compte parce que le principal mode de défaillance de la mémoire n'est pas « le fait est absent » — c'est un échec de récupération : la note dont vous avez besoin existe, mais la requête ne l'atteint jamais. Sans observabilité, entretenir la mémoire tourne à la devinette.

La section se trouve sous Agents → Audit.

Ce qui entre dans le journal

Chaque appel à un outil de lecture (search, recall, get_note) ajoute une ligne au journal : ce qui a été recherché (query, scope, class) et ce qui a été trouvé (les meilleurs résultats avec noteId, title, score, class, ainsi que le nombre de résultats). La capture se fait en arrière-plan — elle n'affecte ni la latence ni l'exactitude de la réponse renvoyée à l'agent.

Les outils d'écriture (create_note, remember_*, edit_note) ne sont pas journalisés dans l'audit de récupération — leur provenance vit dans le journal des révisions. L'audit concerne la lecture.

Chaque ligne retient aussi le nom de l'agent — le nom convivial du token ou de l'application (par exemple, une CLI ou Claude), capturé tant que le token est actif. Ainsi la ligne se souvient à jamais de l'agent qui a émis la requête.

Angles morts

Le signal principal de l'audit, ce sont les requêtes récurrentes sans résultat. Une seule recherche vide est normale (l'agent a testé une hypothèse). Mais une requête qui ne trouve rien encore et encore est un angle mort : l'agent a besoin d'un fait qui n'est pas en mémoire, ou qui est classé sous un titre malheureux. C'est une indication directe de ce qu'il faut ajouter ou de la façon de reformuler.

L'interface condense cela en deux panneaux :

Angles morts — les requêtes vides récurrentes (seuil : deux ou plus sans résultat), surlignées en jaune/ambre.
Fréquentes — les requêtes les plus fréquentes.

Plus un fil d'historique (le plus récent en haut) avec un filtre par outil (All / Search / Recall / Open) : l'icône de l'outil, la requête elle-même, le nom de l'agent, l'étiquette de classe/catégorie, le projet (uniquement lorsqu'une portée est appliquée), le nombre de résultats et l'heure. Déplier une ligne révèle les résultats trouvés — ils sont cliquables et mènent directement aux notes.

Résultats vides

L'audit détecte de façon fiable précisément le cas du résultat vide. Le cas « quelque chose de pertinent existe mais n'a pas figuré parmi les meilleurs résultats » nécessite d'exécuter la requête contre la mémoire — c'est un signal distinct et plus subtil que l'audit ne fait pas apparaître.

Confidentialité et portée

Le journal n'est visible que par le propriétaire : vous voyez la récupération effectuée par vos propres agents, rattachée à votre nom d'utilisateur. Comme celui qui consulte est le propriétaire, le nom de votre agent est affiché sans masquage. L'audit couvre tous vos espaces à la fois — une ligne n'a pas d'espace d'origine unique.

Quand la récupération n'est pas journalisée

L'audit est stocké dans la base de métadonnées. Un hôte sans base de métadonnées (par exemple, le mode none sans base de données) ne journalise pas la récupération — la section reste simplement vide, sans erreur.

Ensuite

Jeux de contexte et épingles — ce qui est chargé au démarrage ; l'audit montre ce qui est récupéré à la demande.
Mémoire de l'agent — ce que recherchent exactement search et recall.
Sécurité et visibilité — pourquoi les journaux de lecture ne sont visibles que par le propriétaire.