Votre agent a une mémoire que vous n'avez pas écrite

Les LLMs développent une mémoire comportementale inconsciente que les évaluations existantes manquent entièrement. Un article de l’ACL 2026 a révélé que les meilleurs modèles obtiennent moins de 66 % à la détection de leurs propres schémas comportementaux appris, des schémas qui persistent d’une session à l’autre sans stockage explicite. La mémoire explicite que vous écrivez (SOUL.md, CLAUDE.md) ne représente que la moitié du tableau.

J’ai passé la majeure partie de la journée à rédiger une référence pratique pour Hermes Agent. L’une des sections porteuses couvre SOUL.md, le fichier où vous fixez l’identité de votre agent. Voix, ton, préférences, garde-fous comportementaux. La prémisse entière de la section est que vous placez l’identité là, l’agent la lit en tête de chaque prompt système, et l’agent se comporte en conséquence. Mémoire explicite. Déclarative. Auditable. Versionnée. Le bon type de mémoire, celui auquel un praticien sérieux devrait tenir.

Un article est paru sur arxiv hier, que j’ai capté lors d’une analyse de signal ce soir, et sa lecture m’a fait tenir la prémisse de SOUL.md plus lâchement que je ne le faisais plus tôt aujourd’hui.¹

L’article s’intitule ImplicitMemBench : Measuring Unconscious Behavioral Adaptation in Large Language Models.¹ Les auteurs le décrivent comme le premier benchmark systématique pour la mémoire implicite dans les LLMs : la mémoire qui (dans leur cadre) façonne ce qu’un agent exécute automatiquement, par opposition à la mémoire explicite qui façonne ce qu’il rappelle consciemment.¹ Les meilleurs performeurs obtiennent moins de 66 %.¹ Les auteurs rapportent également une asymétrie « spectaculaire » à l’intérieur de ce score,¹ que je vais décortiquer avec les nuances appropriées plus bas.

TL;DR

Les benchmarks de mémoire existants mesurent le rappel explicite : étant donné un fait que vous avez dit au modèle, peut-il le récupérer. ImplicitMemBench mesure un système de mémoire différent, celui qui (selon les auteurs) façonne le comportement automatique « sans récupération consciente », tiré de constructions standard des sciences cognitives (mémoire procédurale, amorçage, conditionnement classique).¹ Sur un benchmark de 300 items avec scoring à la première tentative, aucun modèle testé par les auteurs n’a dépassé 66 % globalement : DeepSeek-R1 a obtenu 65,3 %, Qwen3-32B 64,1 %, GPT-5 63,0 %, et les auteurs décrivent les meilleurs performeurs comme « bien en deçà des références humaines ».¹ Le chiffre principal n’en dit que la moitié. Le résumé rapporte également une asymétrie « spectaculaire » : 17,6 % sur l’inhibition contre 75,0 % sur la préférence, un écart d’environ 4x, présenté comme un « goulot d’étranglement universel » qui, selon les auteurs, nécessite des « innovations architecturales au-delà du passage à l’échelle des paramètres ».¹ Je lis l’asymétrie (avec la nuance que le résumé ne publie pas la méthodologie complète derrière ces deux chiffres) comme cohérente avec un mode de défaillance folklorique que je surveille dans le travail d’agent : des systèmes qui renforcent rapidement les préférences récemment vues et qui ne parviennent pas à désapprendre les échecs récemment vus. Si cette lecture tient, elle recadre la conversation sur l’identité de l’agent, la sécurité et l’évolution des compétences, passant de « qu’avez-vous mis dans le prompt ? » à « que la session pourrait-elle être en train de façonner silencieusement sans que vos points d’ancrage explicites puissent l’auditer ? » Le recadrage est mon extension de l’article, et non une affirmation de l’article lui-même.

Points clés à retenir

Les points ci-dessous sont ma lecture de ce que les conclusions de l’article impliquent pour les praticiens, et non des affirmations que l’article lui-même fait. L’article teste 17 LLMs sur un benchmark de sciences cognitives de 300 items ; il n’évalue pas les harnais d’agents de production ou les stratégies de prompting. J’étiquette chaque point à retenir en conséquence.

• Extension : ancrer l’identité dans SOUL.md, AGENTS.md, CLAUDE.md, les prompts système ou les fichiers de mémoire persistante est une mémoire déclarative explicite, domaine dans lequel les benchmarks existants montrent déjà que les modèles se débrouillent bien. ImplicitMemBench mesure un système de mémoire entièrement différent, et les modèles obtiennent moins de 66 %.¹ L’implication pratique (que les points d’ancrage d’identité explicites peuvent ne pas se propager au comportement automatique à la première tentative) est mon inférence, et non celle de l’article.
• Extension : l’asymétrie de 17,6 % contre 75,0 %, si elle se généralise au-delà du benchmark, prédirait un agent qui absorbe rapidement les préférences récemment vues et qui tarde à cesser de répéter les échecs récemment vus. L’article rapporte les deux chiffres et les qualifie de « spectaculaires » et « universels »,¹ mais ne publie pas la méthodologie par item sur la façon dont « préférence » et « inhibition » ont été opérationnalisées, et ne teste pas ce schéma dans des harnais d’agents. La lecture du comportement en production est la mienne.
• Extension : chaque token qui atterrit dans la fenêtre de contexte depuis un appel d’outil, une réponse MCP, une page web grattée ou une tentative d’injection de prompt constitue une influence comportementale en contexte. Pas un entraînement au sens d’une mise à jour de poids, mais une influence sur la prochaine réponse à la première tentative que la couche de prompt explicite ne peut pas auditer proprement. L’article ne fait pas cette affirmation directement ; j’étends le cadre de la mémoire implicite au contenu de la fenêtre de contexte.
• Affirmation de l’article : l’évaluation de 17 modèles révèle des « limitations sévères », des « asymétries spectaculaires » et des « goulots d’étranglement universels nécessitant des innovations architecturales au-delà du passage à l’échelle des paramètres ».¹ Les auteurs présentent l’écart comme architectural. Je lis cela comme une faible preuve contre « plus d’ingénierie de prompt corrigera cela », mais l’article ne teste pas spécifiquement des mitigations par prompting, alors traitez cette lecture comme mon hypothèse, et non la leur.

Ce que l’article mesure

Le cadre de l’article est que les benchmarks de mémoire existants pour les agents LLM « évaluent le rappel explicite des faits, mais négligent la mémoire implicite où l’expérience devient un comportement automatisé sans récupération consciente ».¹ L’écart qu’ils identifient : « les assistants efficaces doivent automatiquement appliquer les procédures apprises ou éviter les actions échouées sans rappels explicites ».¹ Si la seule façon dont votre agent peut éviter une erreur est que vous lui rappeliez à chaque tour de ne pas la commettre, vous ne construisez pas sur une mémoire implicite ; vous payez le coût de la mémoire explicite à chaque requête.

ImplicitMemBench teste trois constructions tirées directement des comptes rendus des sciences cognitives sur la mémoire non déclarative, citées du résumé :¹

1. Mémoire procédurale : « acquisition de compétences en une seule fois après interférence ». Le modèle peut-il, après avoir vu comment faire quelque chose une fois, l’exécuter à nouveau plus tard alors que d’autres instructions sont intervenues ? La mémoire procédurale permet à un humain d’apprendre à faire du vélo : vous ne rappelez pas comment rouler, vous faites le vélo, même après des années sans pratique.
2. Amorçage : « biais thématique via des instances expérimentales/de contrôle appariées ». Voir une classe de choses rend-il le modèle plus susceptible de produire cette classe de choses lors de la tâche suivante sans rapport, sans que le modèle soit conscient que l’amorçage s’est produit ?
3. Conditionnement classique : « associations Stimulus Conditionné-Stimulus Inconditionné (SC-SI) façonnant les premières décisions ». Si le modèle a été exposé à une association stimulus-réponse, cette association apparaît-elle comme un biais sur une tâche totalement nouvelle où ni le SC ni le SI n’est l’objet de la question ?

Les auteurs utilisent une suite de 300 items sous un « protocole unifié Apprentissage/Amorçage-Interférence-Test avec scoring à la première tentative ».¹ Le scoring à la première tentative est important. Un modèle qui peut s’auto-corriger après qu’on lui ait dit qu’il s’est trompé est acceptable, mais la question de recherche ici est de savoir si la mémoire a façonné la première réponse automatique. Si la première réponse est fausse et que la correction ne se produit qu’après un retour explicite, le système de mémoire implicite (tel que défini par l’article) a échoué sur cet item. Les auteurs résument leur contribution par une ligne que je veux citer directement : le benchmark « recadre l’évaluation de “ce que les agents rappellent” à “ce qu’ils exécutent automatiquement” ».¹

Les résultats

Le chiffre principal : « aucun modèle ne dépasse 66 % globalement ».¹

• DeepSeek-R1 : 65,3 %
• Qwen3-32B : 64,1 %
• GPT-5 : 63,0 %

Les meilleurs performeurs ci-dessus sont décrits comme « bien en deçà des références humaines », bien que le résumé ne publie pas le chiffre exact de la référence humaine ni un classement complet par modèle.¹ Dix-sept modèles au total sont évalués dans l’article.¹

Le chiffre principal cache le sous-résultat. Les auteurs écrivent que « l’analyse révèle des asymétries spectaculaires (inhibition 17,6 % contre préférence 75,0 %) et des goulots d’étranglement universels nécessitant des innovations architecturales au-delà du passage à l’échelle des paramètres ».¹ Je veux être prudent ici sur ce que signifient les chiffres. Le résumé ne donne pas une décomposition méthodologique complète sur la façon dont les auteurs ont calculé ces deux chiffres, donc ma glose est une inférence à partir du libellé du résumé, et non une lecture des définitions internes de l’article. Avec cette nuance signalée :

• Préférence : 75,0 % (chiffre de l’article). Ma glose, en attendant l’article complet : les modèles semblent relativement bons pour montrer que l’exposition implicite les a attirés vers un stimulus. L’amorçage et les appariements SC-SI qui biaisent le comportement dans une direction particulière tombent juste environ trois fois sur quatre.
• Inhibition : 17,6 % (chiffre de l’article). Ma glose, en attendant l’article complet : les modèles semblent dramatiquement moins bons pour montrer que l’exposition implicite les a poussés à l’écart d’un stimulus. Le signal « ne refais pas ça » tombe juste moins d’une fois sur cinq. J’infère la signification comportementale du mot « inhibition » et du cadre du conditionnement classique de l’article ; le résumé n’explicite pas l’opérationnalisation.

Les auteurs qualifient explicitement l’asymétrie de « spectaculaire » et l’attribuent à des « goulots d’étranglement universels »,¹ et le mot universel compte : les auteurs présentent cela comme un schéma à travers leur évaluation de 17 modèles, et non un artefact d’un seul modèle. Je ne vais pas prétendre que le goulot d’étranglement est un « problème de prompting » ou « pas un problème de prompting ». L’article ne teste pas le prompting comme mitigation, et affirmer l’un ou l’autre dépasserait ce que le résumé soutient.

Ce que l’asymétrie signifie réellement

Je veux être précis sur ce que je prétends ici, parce que c’est la partie où il est tentant de sur-interpréter un benchmark.

Ce que l’article montre. Sur un benchmark de 300 items ancré dans les sciences cognitives, noté sur les réponses à la première tentative, les LLMs sont dramatiquement moins bons pour démontrer l’inhibition implicite que la préférence implicite, d’un facteur d’environ quatre, à travers tous les modèles testés. Les auteurs qualifient cela de goulot d’étranglement universel qui ne peut être corrigé par la mise à l’échelle.

Ce que je prétends — séparément de l’article. Le schéma d’asymétrie correspond à un mode de défaillance que je surveille dans mon propre travail d’agent depuis des mois, sans lui avoir donné de nom auparavant. Les harnais d’agents (d’après mon expérience) semblent étonnamment bons pour absorber le contexte qui pointe vers un style, un outil ou une approche préférée. Le comportement de l’agent dérive vers ce que vous lui avez fourni le plus récemment, rapidement. Ils semblent étonnamment mauvais pour ne pas répéter un échec qu’ils viennent de voir se produire. L’agent essaie la même commande cassée, le même mauvais outil, le même chemin périmé, même après que ceux-ci aient échoué dans la même session. C’est du folklore, pas une mesure ; c’est mon impression de praticien, pas une étude contrôlée. Les chiffres d’ImplicitMemBench sont cohérents avec ce folklore, c’est pourquoi je m’intéresse à l’article. Ils ne valident pas, à eux seuls, le folklore, et je ne veux pas prétendre que l’article donne « un chiffre » à mon folklore alors que l’article a mesuré quelque chose de plus étroit et plus contrôlé que tout ce que j’ai pu observer.

Ce que je ne prétends pas. Je ne prétends pas qu’ImplicitMemBench a spécifiquement mesuré le comportement des harnais d’agents ou des workflows Claude Code / Cursor / Codex en production. Ce n’est pas le cas. Il a mesuré 17 modèles contre un protocole structuré de sciences cognitives. La correspondance entre le benchmark et le comportement en production est mon extension, étiquetée comme telle, et je ne veux pas qu’un lecteur pense que l’article a fait cette affirmation à ma place.

Avec ces étiquettes en place, la distinction que le benchmark trace entre rappel explicite d’une instruction et comportement automatique à la première tentative sous amorçage/conditionnement est la distinction que je veux que mon propre travail d’agent commence à prendre au sérieux. Vous pouvez dire à l’agent « ne fais pas X » et le rappel explicite fonctionnera probablement ; il peut vous répéter « ne fais pas X » lorsqu’on le lui demande. Ce qu’ImplicitMemBench mesure est autre chose : l’agent ne fait-il pas automatiquement X lors de la prochaine décision à la première tentative, en l’absence de tout rappel explicite ? Je ne sais pas si les harnais d’agents en production héritent du chiffre agrégé de 17,6 % du benchmark pour le comportement à la première tentative dans la nature. Cette correspondance n’est pas testée, et je ne la prétends pas. Je prétends quelque chose de plus faible : la distinction entre « peut rappeler la règle » et « exécute automatiquement la règle » est plus tranchée que je ne la traitais, et les résultats de l’article en font partie.

L’illusion SOUL.md

Le guide Hermes que je rédigeais aujourd’hui traite SOUL.md comme le point d’ancrage d’identité principal de l’agent. Slot n° 1 dans chaque prompt système. Ton, voix, garde-fous. Le guide formule une version de l’argument que chaque système de mémoire persistante pour agents a fait ces deux dernières années : si vous placez l’identité dans le bon fichier de mémoire déclarative, le comportement de l’agent reste aligné avec elle.

Cet argument n’est pas faux, mais ImplicitMemBench me donne une raison d’être moins confiant quant à son application complète. SOUL.md est une mémoire déclarative explicite, le système de mémoire que les benchmarks existants mesurent déjà et sur lequel les modèles se débrouillent déjà bien. Les modèles peuvent rappeler son contenu à la demande ; c’est la partie facile. La question plus difficile, et celle à laquelle SOUL.md ne répond pas selon moi : le point d’ancrage explicite prend-il significativement le dessus sur l’amorçage implicite, le conditionnement et le biais à la première tentative qui s’accumulent à mesure qu’une session se remplit de sorties d’outils, de documents récupérés, de tours d’assistant précédents, de corrections d’utilisateur et de tout le reste qui façonne le comportement à la première tentative sans aucune étape de récupération ? Je ne sais pas. L’article ne teste pas SOUL.md ni aucun fichier d’ancrage d’identité équivalent, et je ne veux pas prétendre qu’il répond à cette question à ma place.

Voici la préoccupation, formulée comme une hypothèse plutôt qu’une conclusion. Si vous ancrez une identité dans SOUL.md qui dit « sois concis et factuel », puis que la session se remplit d’un long fil de conversation narratif de l’utilisateur, le cadre de la mémoire implicite prédit que l’amorçage devrait en partie façonner le comportement à la première tentative au tour suivant, même si le point d’ancrage explicite tient toujours sur le rappel. Que l’amorçage gagne réellement en moyenne en production, je ne peux pas le prouver à partir de cet article, et je ne vais pas essayer. L’illusion SOUL.md, comme je la nomme : la possibilité que vous ayez ancré le rappel de l’identité plutôt que l’exécution automatique de celle-ci, et ces deux choses ne sont pas les mêmes.

Je ne dis pas de ne pas écrire SOUL.md. Je vais toujours l’écrire, et le guide Hermes le recommandera toujours, parce que la mémoire déclarative explicite est porteuse pour les choses qu’elle fait bien. Ce que je dis, clairement étiqueté comme ma propre extrapolation : si vous construisez quoi que ce soit qui dépende de ce que l’agent ne répète pas une erreur, ne dérive pas vers un style récemment vu, ne soit pas détourné par un signal d’amorçage que vous n’aviez pas prévu, je ne parierais pas le budget de fiabilité sur SOUL.md seul, et je ne présumerais pas que rendre SOUL.md plus long ou plus spécifique résout le problème. L’article utilise l’expression « innovations architecturales au-delà du passage à l’échelle des paramètres »,¹ que je lis (prudemment) comme une faible preuve que les mitigations d’ingénierie de prompt ne combleront pas l’écart mesuré par le benchmark. L’article lui-même ne teste pas les mitigations d’ingénierie de prompt, donc je ne peux pas dire qu’il prouve qu’elles échouent ; je peux seulement dire qu’il ne me donne pas confiance qu’elles fonctionneront.

Ce que l’article ne dit pas (et ce que j’ajoute)

L’article est un article de benchmark. Il mesure un écart, le quantifie, et soutient que l’écart est architectural. Il ne prescrit pas de mitigations spécifiques au niveau du harnais ni ne fait d’affirmation sur des systèmes d’agents de production spécifiques. Tout dans cette section est mon cadrage, pas celui de l’article.

Implication 1 : chaque token dans la fenêtre de contexte est une influence comportementale en contexte. Si le cadre de la mémoire implicite tient en dehors du benchmark (et je spécule ici, je ne rapporte pas), chaque token atterrissant dans la fenêtre de contexte depuis un appel d’outil, un document récupéré ou une réponse intermédiaire façonne le comportement à la première tentative du tour suivant d’une manière que la lecture du prompt explicite ne peut pas auditer proprement. J’ai précédemment écrit sur la surface d’attaque d’exfiltration silencieuse (sorties d’outils non fiables transportant des instructions injectées) et le fait que votre agent a un intermédiaire que vous n’avez pas vérifié (routeurs API LLM non fiables entre votre client et le modèle). Aucun de ces articles n’a affirmé la mémoire implicite comme le mécanisme causal. Tous deux ont affirmé l’injection de prompt et la compromission de la chaîne d’approvisionnement comme les mécanismes. ImplicitMemBench offre un angle supplémentaire possible sur pourquoi ces attaques fonctionnent comme elles le font : même si la sortie d’outil hostile ou le routeur compromis ne « dit » jamais explicitement à l’agent quoi faire, le contenu de ce qu’il renvoie pourrait amorcer la prochaine décision de l’agent. C’est une hypothèse avec laquelle ImplicitMemBench est cohérent, et non une conclusion que l’article rapporte.

Implication 2 : la longueur de session pourrait être un risque de fiabilité, et pas seulement un risque de coût. L’observation folklorique est que les agents s’aggravent au cours de longues sessions et l’explication folklorique est la pression de la fenêtre de contexte. ImplicitMemBench n’est pas du tout une étude sur la longueur de session. C’est un benchmark de 300 items avec scoring à la première tentative sous un protocole Apprentissage/Amorçage-Interférence-Test,¹ qui mesure quelque chose de différent de « ce qui se passe sur 30 tours dans une session de production ». Je ne veux pas prétendre qu’il se projette directement sur les sessions de production. Ce que je suggère, à titre d’hypothèse, c’est que le mécanisme que nomme l’article (l’amorçage implicite et le conditionnement classique atterrissant dans les décisions à la première tentative sans récupération) est une explication alternative candidate pour la dérive folklorique, et qu’il mérite une considération sérieuse même si l’article ne le teste pas sous cet angle. Ma règle opérationnelle en attendant : faire des sessions plus courtes que ce que votre fenêtre de contexte permet, pas aussi longues qu’elle le permet. Assurance bon marché contre ce que le mécanisme réel se révélera être.

Implication 3 : l’argument « les compétences statiques sont des compétences mortes » a besoin d’une note de bas de page. J’ai écrit Static Skills Are Dead Skills plus tôt cette semaine en soutenant que les compétences cessent de s’améliorer dès qu’elles sont livrées à moins que vous ne construisiez une boucle de rétroaction de trajectoire. Cet argument supposait que le mode de défaillance était l’absence : absence d’agrégation, absence de détecteur de schéma, absence d’évolueur. En lisant ImplicitMemBench à la lumière de cet article antérieur, je veux signaler un deuxième mode de défaillance possible superposé : même avec des mises à jour de compétences pilotées par la trajectoire, la mise à jour atterrissant dans le fichier de compétences (mémoire déclarative explicite) pourrait ne pas se propager proprement au comportement automatique à la première tentative si quelque chose de plus proche de la couche de mémoire implicite pilote les décisions à la première tentative. Je ne sais pas que c’est le cas. L’article ne teste pas les mises à jour de compétences. Mais c’est une préoccupation que je n’avais pas lorsque j’ai écrit l’article précédent, et je la signale comme une préoccupation plutôt qu’une conclusion.

Implication 4 : le problème de mesure pour la qualité de l’agent pourrait devenir plus difficile. La plupart des évaluations d’agents existantes mesurent soit l’achèvement fonctionnel de la tâche (l’agent a-t-il résolu le problème) soit le rappel explicite des faits (l’agent s’est-il rappelé ce que vous lui avez dit). ImplicitMemBench introduit, sur son propre protocole, une troisième dimension : le comportement automatique à la première tentative sous amorçage implicite. Si cette dimension s’avère importante en production (ce que je ne sais pas, et l’article ne le teste pas), toute boucle de qualité sérieuse pour le travail d’agent a besoin d’un point d’accroche de mesure pour elle, et la plupart des boucles aujourd’hui n’en ont pas. Je traite cela comme un TODO pour mon propre système de qualité plutôt qu’une prescription pour le vôtre.

Implication 5 : l’alignement est une porte de récupération, pas un mécanisme d’effacement. Un article distinct de Liu et al. renforce le cadre de la mémoire implicite sous un autre angle.² Ils montrent que le fine-tuning sur du texte sémantiquement lié (même des romans du domaine public) réactive le rappel textuel de livres protégés par le droit d’auteur que le modèle avait mémorisés pendant le pré-entraînement mais que l’alignement avait supprimés : jusqu’à 85-90 % de reproduction textuelle, des passages uniques dépassant 460 mots, généralisant à plus de 30 auteurs non liés lorsqu’il est fine-tuné sur un seul, avec une corrélation r >= 0,90 entre modèles GPT-4o, Gemini-2.5-Pro et DeepSeek-V3.1.² Le mécanisme compte pour l’argument de la mémoire implicite : la mémorisation était déjà encodée dans les poids du pré-entraînement. Le fine-tuning n’a pas injecté de nouvelles connaissances — il a contourné la porte d’alignement qui bloquait la récupération. Si l’alignement fonctionne comme une porte plutôt qu’une gomme, l’empreinte mémoire réelle du modèle est plus grande et moins contrôlable que ce que les mécanismes explicites (alignement, prompts système, points d’ancrage d’identité) exposent. ImplicitMemBench fait la même affirmation structurelle du côté comportemental : le modèle a une mémoire, à la fois comportementale et de contenu, que vos points d’ancrage explicites ne gouvernent pas. L’article sur le finetuning et ImplicitMemBench mesurent des manifestations différentes de la même réalité sous-jacente. (Comme précédemment, la connexion entre ces deux articles est mon cadrage, et non une affirmation que l’un ou l’autre article fait.)

Que faire concrètement

Aucun des deux articles ne prescrit ou ne teste quoi que ce soit dans cette section. Ce qui suit est ma lecture, travaillant à partir de mes propres arguments antérieurs et utilisant ImplicitMemBench et la constatation de la porte d’alignement comme éléments de preuve supplémentaires, de ce que les conclusions impliquent pour les praticiens qui construisent contre les harnais actuels. Étiquetez en conséquence.

Arrêtez de supposer que les points d’ancrage explicites sont suffisants. Continuez à écrire SOUL.md, AGENTS.md, CLAUDE.md et les fichiers de mémoire, mais traitez-les comme nécessaires-mais-pas-suffisants. L’article AGENTS.md patterns documente comment structurer ces fichiers efficacement ; cet article-ci ajoute une condition limite sur ce qu’ils peuvent garantir. Ce que je mets à jour, c’est ma propre hypothèse par défaut selon laquelle « si c’est dans le prompt système, ça tient ». L’article ne teste pas cette hypothèse ; il teste des questions adjacentes et rapporte des scores qui me font vouloir tenir ma propre hypothèse plus lâchement qu’hier.

Raccourcissez délibérément les sessions. L’observation folklorique est que les agents s’aggravent au cours de longues sessions. L’explication folklorique que j’utilisais est la « pression du contexte ». ImplicitMemBench n’est pas une étude sur la longueur de session. Il utilise un protocole contrôlé Apprentissage/Amorçage-Interférence-Test, et non des sessions de production à longue durée.¹ Mais le mécanisme qu’il nomme (amorçage implicite et conditionnement classique atterrissant sans récupération) est une explication alternative candidate pour ce folklore. La règle opérationnelle que j’adopte : quand une session dérive, ne la combattez pas avec plus de correction explicite. /new la session et repartez de zéro. Que la dérive soit due à la pression de la fenêtre de contexte, à l’amorçage implicite ou à autre chose, une session propre réinitialise quelle que soit la cause réelle.

Traitez l’inhibition comme difficile à imposer dans le prompt. Si vous avez besoin que votre agent ne fasse pas quelque chose, ne comptez pas sur le fait de le lui avoir dit. Construisez une garde structurelle (un linter, un hook de pré-outil, une politique de sandbox, un outil qui refuse l’appel) qui impose l’interdiction au niveau du code. Mon argument de la boucle qualité Jiro a été que les portes dures doivent être en dehors du modèle pour une raison ; je tenais déjà cette position avant cet article. ImplicitMemBench ajoute un schéma spécifique (le chiffre agrégé d’inhibition de 17,6 %¹) qui est cohérent avec l’argument que je défendais, bien que l’article ne teste pas lui-même le prompting ou les harnais d’agents, et je ne veux pas sur-affirmer qu’il prouve la position.

Auditez le contexte pour ce qu’il amorce, pas seulement pour le nombre de tokens qu’il contient. Le nombre de tokens est la mesure que tout le monde a. Si le cadre de l’amorçage implicite est une lentille utile (et je le traite comme une hypothèse que je veux tester, pas un résultat établi), un contexte de 20k tokens rempli de contenu narratif orienté utilisateur pourrait façonner le comportement à la première tentative vers des sorties narratives plus qu’un contexte de 60k tokens rempli de code structuré. Je n’ai pas d’outillage pour ce type d’audit axé sur le contenu pour l’instant, et je ne suis pas sûr que quiconque en ait. La version minimale viable est : regardez vos sessions récentes et demandez-vous « vers quoi un humain lisant ce contexte serait-il amorcé ? » Que cette question soit réellement prédictive du comportement de l’agent est empirique et je ne vais pas prétendre que l’article le tranche.

Journalisez la disposition à la première tentative, pas seulement la disposition finale. Si vous exécutez un quelconque type de capture de trajectoire contre vos compétences, séparez « ce que l’agent a essayé en premier » de « ce sur quoi l’agent a atterri après correction ». Le protocole de scoring à la première tentative d’ImplicitMemBench¹ est l’argument méthodologique expliquant pourquoi cette séparation importe : la disposition finale mesure l’agent plus la boucle de correction, tandis que la première tentative mesure ce que l’agent a réellement produit avant le retour externe. Pour toute boucle de qualité où l’expérience utilisateur dépend de la première réponse qui tombe juste, vous avez besoin du chiffre à la première tentative, et presque rien ne le journalise séparément aujourd’hui.

FAQ

ImplicitMemBench teste-t-il un harnais d’agent spécifique ?

Non. Il teste 17 LLMs directement sur un benchmark de 300 items sous un protocole Apprentissage/Amorçage-Interférence-Test avec scoring à la première tentative.¹ Ce n’est pas un benchmark de harnais. Il n’évalue pas Claude Code, Cursor, Codex, Hermes ni aucune boucle d’agent de production. La correspondance que je trace dans cet article entre les résultats du benchmark et le comportement de production des harnais d’agents est mon extension, étiquetée comme telle tout au long, et n’est pas une conclusion de l’article.

L’asymétrie de 17,6 % contre 75,0 % est-elle un résultat par modèle ou un agrégat ?

Le résumé décrit l’asymétrie comme faisant partie de l’analyse des auteurs sur les résultats globaux du benchmark à travers les modèles, et la qualifie de preuve de « goulots d’étranglement universels ».¹ Je lis cela comme l’asymétrie apparaissant de manière cohérente à travers les 17 modèles testés, les chiffres spécifiques reflétant le schéma agrégé. Le résumé ne publie pas de décomposition par modèle, et je ne vais pas en inventer une. Pour la décomposition complète par modèle, l’article est la source.

Pourquoi cela pourrait-il compter davantage pour les agents de production que pour les benchmarks existants ?

Nuance partielle sur celle-ci. ImplicitMemBench lui-même utilise un protocole en plusieurs étapes (Apprentissage/Amorçage-Interférence-Test),¹ donc il n’est pas exact que le benchmark soit « en une seule fois ». Je ne veux pas répéter la ligne habituelle imprudente sur les benchmarks. Ce qui semble valoir la peine d’être signalé (en tant que spéculation de praticien, pas conclusion de l’article) c’est que la plupart des autres évaluations d’agents que les gens regardent mesurent soit l’achèvement fonctionnel de la tâche soit le rappel explicite des faits, les deux favorisant les modèles. Si l’écart de mémoire implicite rapporté par cet article est réel au-delà de son propre protocole (et je ne sais pas que c’est le cas), ces autres évaluations manquent une dimension du comportement de production que les utilisateurs expérimentent réellement dans les sessions de longue durée. Je traite cela comme une hypothèse testable, pas une conclusion.

Cela contredit-il vos conseils sur SOUL.md dans le guide Hermes ?

Non. Cela ajoute une condition limite. Le guide Hermes recommande SOUL.md comme point d’ancrage d’identité principal parce que la mémoire déclarative explicite est toujours porteuse pour ce qu’elle fait bien : rappel cohérent de l’identité, contrôle de version auditable, comportement prévisible sous interrogation directe. Le guide Hermes n’a pas couvert (parce que rien n’existait pour le mesurer jusqu’à la parution de cet article) le fait que le point d’ancrage d’identité explicite ne se propage pas automatiquement au comportement automatique à la première tentative sous amorçage et conditionnement classique. Vous voulez toujours SOUL.md. Vous voulez aussi des gardes structurelles en dehors de celui-ci.

L’ingénierie de prompt peut-elle corriger tout cela ?

La réponse honnête est que l’article ne teste pas le prompting comme stratégie de mitigation, donc je ne peux pas vous le dire avec l’autorité de l’article. Ce que je peux dire : les auteurs présentent l’écart comme « nécessitant des innovations architecturales au-delà du passage à l’échelle des paramètres »,¹ ce qui est une affirmation plus forte que « de meilleurs prompts aideront » mais n’est pas tout à fait « aucun prompt ne peut aider ». Pour le côté inhibition spécifiquement (17,6 % agrégé), mon intuition de praticien (que vous devriez escompter par rapport à l’article lui-même) est que les gardes structurelles en dehors du modèle sont un pari plus sûr que les instructions de prompt. Mais c’est moi, pas l’article.

Est-ce l’un des articles de « benchmark de mémoire » que j’ai beaucoup vus récemment ?

Non, et l’article se distingue explicitement d’eux. Le cadre du résumé est que les benchmarks de mémoire existants évaluent le rappel explicite des faits : donner un fait au modèle, demander au modèle de le récupérer. ImplicitMemBench mesure autre chose entièrement, l’adaptation comportementale automatique sans aucune étape de récupération.¹ Cette distinction est la contribution de l’article et la raison pour laquelle il a été accepté à la conférence principale de l’ACL 2026.¹

Où cela se situe-t-il par rapport à vos articles précédents sur la mémoire d’agent ?

L’article se situe dans le hub d’ingénierie IA et est un compagnon direct de Static Skills Are Dead Skills. Context is architecture établit l’argument structurel pour expliquer pourquoi ce qui entre dans la fenêtre de contexte compte ; compound context décrit l’infrastructure qui s’accumule au fil des sessions. Cet article précédent soutenait que les compétences ont besoin d’agrégation de trajectoire pour rester vivantes, et je supposais que le mode de défaillance était une pure absence : si vous pouviez juste obtenir les données de trajectoire et exécuter un détecteur de schéma, vous seriez tranquille. ImplicitMemBench pointe vers un deuxième mode de défaillance superposé : même avec des mises à jour de compétences parfaites pilotées par la trajectoire, le comportement à la première tentative peut ne pas refléter la mise à jour parce que la mise à jour a atterri dans la mémoire explicite et que la mémoire implicite pilote les décisions réelles. L’article précédent reste correct sur ce qu’il affirmait ; le présent article met à jour ce qu’il ne savait pas affirmer.

Cela pourrait-il être un artefact de mesure ?

Possiblement. L’article est récent (soumis le 9 avril 2026, accepté à la conférence principale de l’ACL 2026), et les benchmarks uniques peuvent mesurer des artefacts de leurs protocoles spécifiques aussi facilement qu’ils mesurent des phénomènes réels.¹ Je ne vais pas prétendre le contraire. La raison pour laquelle je pense que ce n’est pas juste un artefact est que le mode de défaillance qu’il décrit (agents renforçant rapidement les préférences tout en échouant à désapprendre les échecs) est un folklore que je surveille sans nom pour lui depuis plus d’un an. Le benchmark n’a pas besoin d’être parfaitement calibré pour que la direction du résultat soit la chose sur laquelle les praticiens devraient agir.

Références