Entre deux sessions, Claude peut corriger ce qu’il a mal retenu

Le « dreaming » permet aux agents Claude de relire leurs sessions, de corriger leurs notes et de constituer des wikis. Anthropic détaille ses essais.

Au pied du mont Sélénite, dans Pokémon Rouge, Claude croit avoir déjà traversé la grotte. Une note place le Centre Pokémon du mauvais côté de la montagne. En suivant ce repère, l’agent franchit un rebord qui le ramène sur la route précédente. Il répète l’erreur trois fois et termine l’essai dans la ville d’où il était parti.

Dans un autre essai décrit par l’équipe d’ingénierie d’Anthropic, Claude relit le journal de la partie entre deux sessions, repère l’erreur et réécrit sa note. Lorsqu’il reprend la partie, il retourne dans la grotte et finit par atteindre Azuria. Le « dreaming » désigne cette passe de travail entre les sessions, pendant laquelle l’agent revient sur ce qu’il a consigné en cours de tâche. Relire les traces avant de transmettre une note

Dans les expériences d’Anthropic, la mémoire prend la forme de fichiers qu’une session ultérieure peut consulter. Un agent peut y inscrire une règle qu’il a vérifiée ou une hypothèse qu’il reste à tester. Une passe de « dreaming » confronte ensuite ces notes aux journaux des sessions pour corriger des erreurs, fusionner des doublons ou organiser les informations par sujet. Le principe prolonge les travaux de Letta et de l’université de Californie à Berkeley sur le sleep-time compute, qui explorent le calcul effectué entre deux interactions pour préparer les suivantes.

La fonction Dreams de Claude Managed Agents applique cette méthode à un ensemble de sessions choisi par le développeur. Par défaut, elle produit une nouvelle version de l’espace de mémoire. Celle-ci peut être examinée avant d’être rattachée aux prochaines sessions. L’accès à cette fonction de l’API se fait sur demande, dans le cadre d’un aperçu de recherche. Un wiki complète la recherche dans les fichiers

Sur un corpus d’environ 350 000 fichiers internes de Stainless, des agents Opus 5 ont construit un wiki en plusieurs passes. Ils ont créé des pages, vérifié des informations dans les documents et relié les notes entre elles. Sur les 25 questions de l’évaluation interne, la recherche dans les fichiers seule satisfait 53 % des critères. Avec la recherche et le wiki le plus abouti, le score atteint 61 %. Le wiki seul plafonne à 48 % dans cet essai.

L’équipe rapporte aussi une économie d’environ 20 000 jetons par question lorsque les deux outils sont combinés. Cette mesure porte sur la phase de réponse. Le coût complet comprend aussi le calcul consacré à la construction du wiki et à ses mises à jour. Sur un autre exercice, où les informations étaient souvent accessibles par une recherche dans un seul document, le wiki n’a apporté aucun gain clair. Une page par contrat pour éviter les écrasements

Dans une simulation d’acquisition, plusieurs agents résumaient des clauses dans le même tableau. Certaines entrées ont disparu quand un agent a enregistré sa version par-dessus celle d’un autre. La note juridique produite à partir de ce premier wiki reprenait 41 des 57 éléments attendus.

L’équipe a ensuite essayé une organisation où chaque contrat avait sa propre page, confiée à un seul agent, avec les clauses reproduites mot pour mot. Dans cet exercice, la note produite à partir du wiki révisé a satisfait les 57 critères.