Doter un agent d'IA d'une mémoire paraît simple : le laisser écrire des notes et les relire la fois suivante. Le nouveau billet de recherche d'Anthropic montre pourquoi ce n'est pas le cas, et pourquoi la réponse a changé à mesure que les modèles progressaient. En bref, les modèles Claude les plus puissants enregistrent bien moins, choisissent mieux quoi garder et font moins bien quand on leur dicte précisément quoi noter.
L'exemple le plus parlant vient de Pokémon Rouge. Après environ 10 000 étapes de jeu, Claude Sonnet 3.7 avait écrit 413 fichiers de mémoire répartis dans 225 dossiers, dont des fichiers distincts pour chaque combat, objet et personnage, et gagné un badge. Claude Fable 5 a écrit neuf fichiers dans deux dossiers plus un unique tableau de bord général, et gagné quatre badges. Une grande partie de ce que gardait l'ancien modèle, comme l'argent ou la position sur la carte, se lit de toute façon à l'écran, et à un moment il a passé 17 étapes à réorganiser ses fichiers sans jouer un seul coup. Opus 5.5 a tenu un petit ensemble de notes réécrites en continu et a fini le jeu. Sur une tâche de questions sur une base de données tirée de Continual Learning Bench 1.0, Opus 5 a été le premier modèle à boucler la boucle, en écrivant des règles accompagnées de la façon dont il savait qu'elles étaient vraies ; Opus 5.5 et Sonnet 5.5 ont fait de même.
Les conseils pour les développeurs sont précis. Dire à Claude à quoi sert la mémoire, sans lui dicter comment l'utiliser, a le mieux fonctionné avec les modèles puissants. Imposer une règle comme « n'enregistre que les échecs » a fait perdre à Opus 5 et Opus 4.7 une bonne part de ce que la mémoire leur apportait. Les modèles plus anciens ont encore besoin d'être guidés : demander à Sonnet 4.6 de lire sa mémoire et de tester ses hypothèses a presque doublé son score, alors que Sonnet 5 lisait sa mémoire spontanément neuf fois sur dix.
La seconde idée est le rêve : revoir hors ligne d'anciennes transcriptions pour corriger les mauvaises notes. Dans une partie de Pokémon, Claude a noté à tort de quel côté de Mt. Moon se trouvait un repère et retombait sans cesse du même rebord ; une fois que le rêve a confronté la note à la transcription, il est retourné dans la grotte et a atteint la ville suivante. Sur un corpus d'environ 350 000 fichiers internes, construire un wiki lié au fil de 128 sessions de rêve a fait passer les réponses justes à 25 questions de 13% à 48%, et le wiki associé à la recherche a battu la recherche seule, 61% contre 53%, tout en économisant environ 20 000 tokens par question.
Pour les développeurs de Claude Developer Platform, une grande partie de cela passe par Managed Agents et s'utilise directement. Les réserves : tous les résultats viennent de tâches et de jeux conçus par Anthropic, certaines comparaisons reposent sur une seule exécution, et le billet montre lui-même un wiki devenu plus volumineux que les documents qu'il résumait, ce qui rappelle que plus de mémoire n'est pas toujours une meilleure mémoire.