IBM Research compare ALTK-Evolve à ACE sur AppWorld : une mémoire d’agent livrée de façon adaptative réduirait fortement les tokens d’inférence, sans baisse mesurée de performance.
Un agent IA ne rate pas forcément une tâche parce qu’il ignore quoi faire. Il peut connaître les API, disposer des bons outils et malgré tout échouer sur un détail opérationnel : mal gérer une pagination, identifier le mauvais contact ou retourner une valeur qui n’était pas demandée. Le problème est alors moins la connaissance que la capacité à réutiliser correctement l’expérience acquise.
IBM Research présente ALTK-Evolve, une approche de mémoire agentique comparée à ACE (Agentic Context Engineering). Les deux systèmes apprennent à partir des trajectoires précédentes d’un agent, sans mise à jour des poids du modèle ni annotations humaines. Leur divergence se situe dans la façon d’injecter ces apprentissages au moment de l’exécution. D’après les résultats publiés par IBM sur le benchmark AppWorld, cette différence permettrait de réduire fortement le volume de tokens consommés, à performance comparable ou supérieure dans les configurations testées.
Le sujet n’est pas seulement de stocker une mémoire pour un agent IA. Il faut aussi décider quelle part de cette mémoire mérite d’entrer dans le contexte, pour une tâche et un modèle donnés. Un contexte exhaustif peut coûter cher et, selon IBM, devenir contre-productif sur certains modèles.
ACE et ALTK-Evolve cherchent à capitaliser sur les erreurs des agents
Dans les deux cas, l’objectif est de transformer des épisodes passés — réussites, erreurs et corrections — en consignes réutilisables. IBM appelle ces éléments des « leçons ». Elles servent à guider l’agent lors de tâches ultérieures, notamment dans des environnements composés de plusieurs étapes et applications simulées.
ACE rassemble ces leçons dans un playbook unique qui évolue au fil des expériences. Chaque élément conserve notamment un compteur indiquant s’il s’est montré utile ou nuisible. L’idée est de préserver le détail, plutôt que de résumer toute l’expérience sous la forme de quelques règles générales.
ALTK-Evolve adopte le même principe de non-compression : une leçon issue de cinq épisodes indépendants ne doit pas être confondue avec une leçon observée une seule fois. Son stockage conserve donc un compteur de support, c’est-à-dire le nombre d’épisodes qui étayent une directive.
Ce point de convergence compte. Les auteurs opposent cette logique à deux écueils : des instructions trop courtes et génériques, qu’ils associent à un biais de concision, et l’effacement progressif des détails lorsqu’un modèle doit sans cesse réécrire ou résumer l’intégralité de son contexte. Dans les deux systèmes, l’expérience ne doit pas être réduite à un résumé propre mais pauvre.
La différence se joue dans la construction, surtout dans la livraison du contexte
IBM distingue deux niveaux. Le premier est la consolidation du magasin de mémoire. ACE alimente son playbook par une boucle de génération, réflexion et curation, avec des mises à jour incrémentales et une déduplication fondée sur les embeddings.
ALTK-Evolve regroupe les leçons proches et les fusionne dans un cluster, tout en additionnant leurs compteurs de support. Selon la source, le système extrait aussi des directives typées — stratégie, récupération et optimisation — liées causalement à leur trajectoire d’origine et associées à un sous-problème. Cette granularité est censée faciliter le transfert d’une leçon entre applications ou étapes comparables.
Mais l’enjeu économique se situe surtout au second niveau : ce qui est effectivement envoyé au modèle à l’inférence.
- ACE injecte le playbook complet à chaque étape, indépendamment de la tâche et du modèle utilisé.
- ALTK-Evolve peut fournir un noyau fixe de directives très soutenues par les épisodes passés, puis ajouter quelques consignes sélectionnées pour la tâche. La sélection peut reposer sur la similarité cosinus ou être guidée par un LLM et pondérée par priorité.
- Pour un modèle disposant de suffisamment de capacité contextuelle, ALTK-Evolve peut aussi fournir l’ensemble consolidé.
Autrement dit, ALTK-Evolve traite la taille du contexte comme un paramètre à régler. La mémoire disponible est la même dans l’esprit, mais son volume injecté varie selon ce que le modèle paraît capable d’exploiter. C’est une distinction directement exploitable si tu opères des agents à volume élevé : le coût dépend autant du raisonnement que du texte répété dans chaque appel.
Sur AppWorld, IBM rapporte moins de tokens pour des scores proches ou meilleurs
Les résultats publiés reposent sur AppWorld test_normal, un ensemble de 168 tâches. Les essais utilisent un même agent de base ReAct : à chaque étape, l’agent écrit du Python et l’environnement renvoie le résultat. Deux métriques sont rapportées : le Task Goal Completion (TGC) et le Scenario Goal Completion (SGC), ce dernier imposant la réussite de toutes les variantes d’un scénario.
Sur DeepSeek-V3.2, IBM indique les résultats suivants :
- ACE : 80,4 % de TGC, 73,2 % de SGC et 634 000 tokens par tâche ;
- ALTK-Evolve : 89,3 % de TGC, 80,4 % de SGC et 263 000 tokens par tâche.
Sur gpt-oss-120b, les chiffres publiés sont :
- ACE : 54,8 % de TGC, 35,7 % de SGC et 777 000 tokens par tâche ;
- ALTK-Evolve : 56,0 % de TGC, 37,5 % de SGC et 116 000 tokens par tâche.
Sur le premier modèle, ALTK-Evolve consommerait donc environ 41 % du volume de tokens attribué à ACE dans ce protocole. Sur gpt-oss-120b, le volume rapporté est proche d’un septième. IBM nuance néanmoins l’écart de score sur ce second modèle : une répétition de ses propres essais aurait atteint 54,8 % en TGC, soit le score d’ACE, ce qui suggère que le faible avantage observé peut relever de la variabilité du benchmark.
Le bon volume de mémoire dépendrait de la capacité du modèle
La répartition des résultats par difficulté nourrit l’argument d’IBM. Avec gpt-oss-120b, ACE obtiendrait de meilleurs résultats sur les tâches faciles et moyennes, tandis que la sélection par tâche d’ALTK-Evolve prendrait l’avantage sur les tâches difficiles et sur le score agrégé.
Avec DeepSeek-V3.2, IBM rapporte un avantage d’ALTK-Evolve sur les tâches faciles, difficiles et au global ; ACE ne devancerait ALTK-Evolve que sur la catégorie intermédiaire. Les auteurs ont configuré ALTK-Evolve différemment selon le modèle : jeu consolidé complet pour le modèle qu’ils qualifient de fort, récupération sélective pour le modèle qu’ils qualifient de plus faible.
Leur interprétation est claire : un contexte très large peut aider un modèle à l’aise avec cette information, mais surcharger un modèle qui ne sait pas isoler la bonne consigne. C’est une hypothèse étayée ici par un benchmark précis, pas une loi générale démontrée pour tous les modèles, tous les agents ou tous les domaines métier.
Les chiffres viennent d’une comparaison réalisée en interne par IBM, sur un seul benchmark, 168 tâches et un agent ReAct commun. Ils sont utiles pour évaluer la méthode, mais ne suffisent pas à prédire les coûts ni les taux de réussite sur ton stack, tes outils et tes flux de production.
Comment évaluer cette approche dans un agent de production
Si tu construis un agent qui enchaîne des appels d’outils, retiens surtout le mécanisme plutôt que les pourcentages. Une mémoire durable ne justifie pas l’envoi de tout son contenu à chaque tour. Mesure ce que chaque bloc de contexte apporte réellement.
- Conserve la provenance. Relie chaque règle mémorisée à une trajectoire, une erreur ou un succès identifiable. Sans cela, impossible de l’auditer ou de la corriger.
- Compte les confirmations indépendantes. Une règle observée à répétition mérite davantage de poids qu’une intuition isolée.
- Teste la récupération sélective. Compare un contexte complet, un petit noyau fixe et une sélection liée à la tâche. Observe à la fois le taux de réussite, la latence et les tokens.
- Segmente par modèle et par difficulté. Une configuration efficace avec un modèle puissant peut dégrader un modèle plus compact ou moins robuste au bruit contextuel.
- Évalue sur tes tâches réelles. Les scénarios AppWorld sont simulés. Un agent de support, de back-office e-commerce ou d’automatisation interne rencontrera des données, droits d’accès et erreurs d’outils différents.
La promesse d’ALTK-Evolve n’est donc pas qu’une mémoire d’agent rend automatiquement le raisonnement moins cher. Elle est plus concrète : une mémoire riche peut rester utile sans être injectée intégralement à chaque étape. Pour les équipes qui surveillent leur facture d’inférence, c’est une piste à tester avec une instrumentation sérieuse, plutôt qu’une optimisation à adopter sur la seule foi d’un benchmark.