Agentic Context Engineering (ACE) : comment les agents IA apprennent de leur expérience

La plupart des agents IA commencent chaque tâche avec le même prompt système, quelques outils et, parfois, l’historique récent de la conversation. Lorsqu’ils commettent une erreur, la leçon disparaît généralement avec la session. L’exécution suivante peut échouer exactement de la même manière.

Les équipes réagissent souvent en allongeant le prompt. Elles ajoutent une règle, puis un exemple, puis un avertissement. Le prompt finit par devenir un document que personne ne comprend entièrement et que personne ne veut modifier.

L’Agentic Context Engineering, ou ACE, propose une autre approche : traiter le contexte de l’agent comme un playbook capable d’apprendre de l’exécution. Les poids du modèle ne changent pas. Ce qui évolue, c’est la connaissance structurée fournie au modèle lorsqu’il travaille.

L’idée vient du papier ICLR 2026 Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models. Sa thèse centrale est très concrète : un agent peut progresser en accumulant dans son contexte des stratégies utiles, des schémas d’échec et des règles métier, au lieu de réécrire sans cesse un unique prompt volumineux.[1]

Ce que change ACE

Un agent classique reçoit un contexte statique :

instructions système + documents récupérés + historique + tâche actuelle

Un agent inspiré d’ACE reçoit aussi un playbook évolutif :

instructions système + entrées pertinentes du playbook + tâche actuelle

Après la tâche, le feedback d’exécution est converti en petites mises à jour du playbook. Une séquence d’API réussie peut devenir une procédure réutilisable. Une tentative ratée peut devenir un avertissement. Une correction issue d’un validateur peut affiner une règle existante.

Cette définition est plus précise que le terme général « context engineering ». Le context engineering couvre la sélection, la construction et la transmission de tout ce qui entre dans la fenêtre de contexte du modèle. ACE est une méthode pour améliorer une partie de ce contexte au fil du temps.

La distinction compte. Un prompt indique à l’agent ce qu’il doit faire maintenant. Un playbook ACE conserve ce que les exécutions précédentes ont découvert sur la bonne manière de le faire.

Pourquoi le contexte statique finit par échouer

Le papier ACE décrit deux problèmes récurrents dans l’adaptation du contexte.

Le premier est le biais de brièveté. Les optimiseurs de prompts convergent souvent vers des instructions courtes et générales, car elles sont simples à évaluer et à réécrire. Ces résumés peuvent éliminer les détails dont un agent opérationnel a besoin : contraintes des outils, terminologie métier, particularités d’une API ou modes d’échec connus.[1]

Le second est l’effondrement du contexte. Lorsqu’un LLM réécrit tout le contexte accumulé après chaque tâche, des détails utiles peuvent disparaître en une seule passe. Dans l’étude AppWorld du papier, un contexte de 18 282 tokens a été réduit à 122 tokens à l’étape suivante. La précision est passée de 66,7 à 57,1, sous le niveau de référence de 63,7 sans adaptation.[1]

Ce problème est familier à quiconque utilise des agents sur de longues sessions. Un résumé semble propre, mais remplace discrètement des connaissances précises par des phrases comme « valider les entrées » ou « utiliser l’API appropriée ». Ces règles semblent raisonnables et n’aident presque personne.

ACE évite les réécritures complètes. Il stocke la connaissance dans de petites entrées et applique des changements localisés.

Le Generator, le Reflector et le Curator

ACE sépare l’amélioration du contexte en trois rôles.

1. Le Generator réalise la tâche

Le Generator est l’agent qui résout le problème. Il reçoit la requête et les entrées pertinentes du playbook, puis produit une trajectoire : raisonnement, appels d’outils, observations et résultat final.

Il doit aussi indiquer quelles entrées du playbook ont été utiles ou trompeuses. Le système peut ainsi relier une règle à un résultat observable.

2. Le Reflector extrait la leçon

Le Reflector examine la trajectoire et son feedback. Il pose des questions concrètes :

• Qu’est-ce qui a fonctionné ?
• Qu’est-ce qui a échoué ?
• L’échec vient-il d’une mauvaise stratégie, d’une connaissance manquante ou d’une mauvaise exécution ?
• Quelle leçon pourrait servir lors d’une future tâche ?
• Faut-il corriger une entrée existante du playbook ?

La réflexion est séparée de l’exécution. Le Generator se concentre sur la résolution. Le Reflector se concentre sur ce que le système peut apprendre du résultat.

3. Le Curator met le playbook à jour

Le Curator transforme les leçons du Reflector en deltas. Un delta peut ajouter une entrée, en réviser une autre, incrémenter ses compteurs d’utilité ou la proposer pour suppression.

Le papier représente le playbook sous forme de puces structurées dotées d’un identifiant unique, d’un contenu et de compteurs indiquant combien de fois chaque règle a été utile ou nuisible. Les mises à jour sont fusionnées par du code déterministe, sans demander à un LLM de réécrire tout le contexte.[1]

Une entrée simplifiée pourrait ressembler à ceci :

{
  "id": "payments-014",
  "scope": ["refunds", "card-payments"],
  "content": "Avant de rembourser un paiement capturé, récupérer le paiement et vérifier que son statut autorise le remboursement.",
  "helpful": 12,
  "harmful": 1,
  "source": "execution-feedback",
  "updatedAt": "2026-08-05T00:00:00Z"
}

Cette structure est plus simple à inspecter, rechercher, modifier et supprimer qu’un prompt unique de 20 000 tokens.

Un exemple pratique

Prenons un agent qui traite des tickets liés aux paiements.

Un client demande un remboursement. L’agent appelle immédiatement l’endpoint de remboursement, mais le provider refuse la requête parce que le paiement est encore en attente. La tâche échoue et l’environnement renvoie une erreur structurée.

Le Reflector ne devrait pas conserver une leçon vague comme « vérifier le statut du paiement ». Il peut extraire une règle plus utile :

Pour une demande de remboursement, récupérer le paiement avant d'appeler l'endpoint de remboursement.
Continuer uniquement si le statut du provider est « captured » et remboursable.
Si le paiement est « pending », expliquer le délai et s'arrêter au lieu de relancer le remboursement.

Le Curator examine ensuite le playbook existant :

• S’il n’existe aucune règle sur les remboursements, il ajoute cette entrée.
• Si une règle partielle existe, il la met à jour localement.
• Si plusieurs entrées décrivent la même procédure, il les fusionne.
• Si des exécutions ultérieures montrent que la règle est fausse pour un provider, il réduit son périmètre au lieu de supprimer toute la leçon.

Lors du prochain ticket similaire, le mécanisme de retrieval fournit cette entrée au Generator. L’agent commence avec une connaissance obtenue grâce à l’échec précédent.

C’est la forme utile de « self-improvement » dans ACE. Le modèle n’est pas devenu globalement plus intelligent. Le système a conservé une leçon vérifiée et l’a rendue disponible au bon moment.

Faire croître et affiner plutôt que tout réécrire

Un playbook évolutif ne peut pas grandir sans entretien. ACE emploie une stratégie appelée grow-and-refine.

Les nouvelles connaissances sont ajoutées sous forme d’entrées. Les connaissances existantes sont modifiées localement. Une étape de déduplication compare les entrées sémantiquement proches et supprime les redondances. Ce nettoyage peut avoir lieu après chaque mise à jour ou seulement lorsque le playbook approche de sa limite de tokens.[1]

Le système doit concilier deux responsabilités :

1. Préserver les détails utiles.
2. Maintenir un contexte assez pertinent pour que le modèle puisse l’exploiter.

Un contexte plus long n’est pas automatiquement meilleur. L’objectif est un playbook complet, bien structuré et associé à un bon retrieval, pas une archive de chaque observation faite par l’agent.

Un Curator de production a donc besoin de règles qu’un LLM ne peut pas contourner facilement :

- Ne jamais remplacer tout le playbook en une seule génération.
- Chaque mutation doit cibler un identifiant d'entrée.
- Conserver la source et l'historique d'évaluation.
- Exiger plusieurs preuves avant de supprimer une règle utile.
- Placer les entrées contradictoires en quarantaine pour revue.
- Imposer un budget de tokens par domaine ou par outil.

Adaptation offline et online

ACE prend en charge deux modes.

L’adaptation offline construit le playbook à partir d’un jeu d’entraînement avant le déploiement. L’agent exécute des tâches, observe les résultats, réfléchit et produit un playbook qui sera ensuite évalué sur des tâches séparées. Ce mode convient lorsque vous disposez de scénarios représentatifs et d’un environnement de test fiable.

L’adaptation online modifie le playbook pendant l’utilisation. L’agent tente d’abord une tâche avec son contexte actuel, puis apprend du résultat avant de traiter les tâches suivantes. Ce mode est utile lorsque le comportement de la production change ou que la distribution complète des problèmes n’est pas connue.[1]

Le design de production le plus prudent combine généralement les deux :

1. Construire un premier playbook offline à partir des tests et des cas historiques.
2. Le déployer comme un artefact versionné.
3. Collecter des leçons candidates en ligne.
4. Valider ces leçons avant leur promotion.
5. Déployer progressivement une nouvelle version du playbook.

Mettre à jour un playbook partagé après chaque interaction utilisateur non vérifiée est risqué. Une instruction malveillante, une erreur temporaire du provider ou une mauvaise réflexion peut devenir un contexte durable. L’apprentissage online demande les mêmes contrôles qu’un changement de code : revue, tests, versioning et rollback.

ACE face aux techniques voisines

Technique	Ce qui change	Usage principal
Prompt engineering	Les instructions d’un appel modèle ou d’un workflow	Rôles, contraintes, formats et comportement immédiat
Retrieval-Augmented Generation	Les preuves externes sélectionnées pour la requête actuelle	Faits provenant de documents, bases de données ou moteurs de recherche
Mémoire agentique	Les informations conservées entre les tâches	Préférences utilisateur, événements passés et état de travail
Fine-tuning	Les poids du modèle	Comportements ou capacités qui doivent s’appliquer dans de nombreux contextes
ACE	Un playbook structuré construit depuis le feedback d’exécution	Stratégies réutilisables, schémas d’échec et procédures métier

Ces techniques peuvent fonctionner ensemble. Un système ACE peut utiliser le RAG pour récupérer des documents sources, la mémoire pour conserver des faits propres à un utilisateur et le playbook pour fournir des procédures apprises. Le fine-tuning reste utile lorsque le comportement recherché est trop général ou trop fréquent pour être transporté efficacement dans le contexte.

La provenance doit rester claire. Un fait récupéré ne doit pas se transformer silencieusement en règle permanente. Une mémoire propre à un utilisateur ne doit pas se retrouver dans un playbook partagé. Un échec d’exécution ne doit pas devenir une leçon avant que le système en comprenne la cause.

Ce que montrent les résultats publiés

Le papier évalue ACE sur AppWorld et sur des tâches de raisonnement spécialisé. AppWorld est un benchmark composé d’applications simulées, de centaines d’API et de tâches qui obligent les agents à écrire et exécuter du code sur plusieurs applications.[3]

Les auteurs rapportent des gains moyens de 10,6 % sur les tâches agentiques et de 8,6 % sur les benchmarks financiers face aux baselines sélectionnées. Ils indiquent aussi une réduction moyenne de 86,9 % de la latence d’adaptation. Dans deux comparaisons détaillées, ACE réduit de 82,3 % la latence de l’adaptation offline sur AppWorld et de 75,1 % le nombre de rollouts face à GEPA. Pour l’adaptation online de FiNER, il réduit de 91,5 % la latence et de 83,6 % le coût en tokens face à Dynamic Cheatsheet.[1]

L’implémentation officielle propose des modes offline, online et évaluation seule. Elle permet aussi de configurer le budget de tokens du playbook, la fréquence du Curator, le nombre de tours de réflexion, la déduplication et les modèles utilisés par chacun des trois rôles.[2]

Ces résultats sont prometteurs, mais restent des résultats de benchmark. Ajouter une boucle de réflexion ne garantit pas qu’un agent progressera. La qualité du signal de feedback compte davantage que l’étiquette « self-improving ».

Là où ACE peut échouer

Le papier expose clairement sa principale limite : si le Reflector ne sait pas extraire une leçon solide, le playbook devient bruité, voire nuisible. Les expériences financières montrent aussi une dégradation lorsqu’il n’existe ni labels corrects ni signaux d’exécution fiables.[1]

Plusieurs modes d’échec pratiques en découlent.

Un mauvais feedback crée une mauvaise mémoire

Un timeout ne prouve pas qu’une procédure est fausse. Un test instable ne justifie pas une nouvelle règle. Le système doit distinguer la qualité de la tâche du bruit d’infrastructure.

Un succès local peut devenir une erreur globale

Un contournement qui fonctionne pour un provider, un tenant ou une version logicielle peut échouer ailleurs. Chaque entrée a besoin d’un périmètre et d’une provenance.

Le retrieval peut cacher une bonne connaissance

Une leçon correcte ne sert à rien si le retrieval ne la sélectionne pas. Mesurez le rappel du retrieval séparément de la performance du Generator.

Le contexte peut quand même devenir coûteux

Les mises à jour incrémentales empêchent les réécritures destructrices, mais le playbook peut toujours grossir. Suivez les tokens, la latence, le taux de cache et la proportion d’entrées récupérées réellement utilisées par l’agent.

Le playbook devient une frontière de sécurité

Si du contenu externe peut influencer la réflexion, un attaquant peut tenter d’y planter des instructions durables. Les mises à jour candidates doivent passer par des contrôles de politique, une validation de leur source et des règles d’approbation avant d’entrer dans un contexte partagé.

ACE est également superflu pour des tâches simples aux stratégies stables. Le papier note que certaines tâches de questions-réponses et certains jeux à stratégie fixe profitent davantage d’instructions concises que d’un playbook riche.[1]

Une architecture de production minimale

Un système inspiré d’ACE a besoin de six composants :

1. Un exécuteur de tâches qui enregistre les trajectoires et les résultats des outils.
2. Des évaluateurs qui produisent un feedback structuré et fiable.
3. Un Reflector qui propose des leçons accompagnées de preuves.
4. Un Curator qui émet des opérations delta typées.
5. Un stockage versionné du playbook avec une fusion déterministe.
6. Un retrieval qui sélectionne les entrées selon la tâche, l’outil, le domaine et la similarité.

Le chemin de mise à jour peut tenir dans une boucle simple :

playbook = loadVersion("production")

for task in tasks:
    entries = retrieve(playbook, task)
    trajectory = generator.run(task, entries)
    feedback = evaluate(task, trajectory)

    candidateLessons = reflector.review(
        task,
        trajectory,
        feedback,
        entries
    )

    deltas = curator.propose(candidateLessons, playbook)
    validatedDeltas = validate(deltas, feedback, policies)
    playbook = deterministicMerge(playbook, validatedDeltas)

publish(playbook, after = [regressionTests, humanReview, canary])

L’évaluateur est la partie la plus souvent sous-estimée. Avant d’automatiser la réflexion, définissez ce qui constitue un succès, quelles preuves sont fiables et quels échecs ne doivent produire aucun apprentissage.

Les métriques à suivre

N’évaluez pas un système ACE uniquement sur le score final des tâches. Mesurez aussi le système d’apprentissage :

• Taux de réussite avant et après chaque version du playbook.
• Progression sur des tâches séparées de celles qui ont produit les leçons.
• Nombre d’entrées ajoutées, révisées, fusionnées, mises en quarantaine et supprimées.
• Rappel du retrieval et utilisation des entrées.
• Taux de contradictions et de doublons.
• Coût en tokens et latence de bout en bout.
• Régressions causées par un delta précis.
• Temps nécessaire pour retirer une leçon erronée ou sensible.

Une version du playbook doit être reproductible. À partir de la même version de base et des mêmes deltas approuvés, la fusion doit produire le même résultat.

La leçon à retenir

ACE éloigne le développement agentique de l’édition sans fin d’un unique prompt système. Il traite la connaissance opérationnelle comme une donnée dotée d’une structure, d’un historique, d’une évaluation et de règles de cycle de vie.

Cette idée reste utile même sans adopter l’implémentation officielle. Enregistrez les leçons sous forme de petites entrées bien délimitées. Reliez-les à des preuves. Récupérez-les de manière sélective. Modifiez-les localement. Testez le contexte obtenu avec le même sérieux que votre code.

Un agent n’apprend pas simplement parce qu’il possède une mémoire. Il apprend lorsque l’expérience devient une instruction fiable pour l’exécution suivante.

Sources

[1] https://arxiv.org/abs/2510.04618 — Agentic Context Engineering: Evolving Contexts for Self-Improving Language Models [2] https://github.com/ace-agent/ace — ACE official implementation [3] https://arxiv.org/abs/2407.18901 — AppWorld: A Controllable World of Apps and People for Benchmarking Interactive Coding Agents