AWS : un seul outil réduit de 95% les tokens par script, et les compétences à la demande raccourcissent le prompt de 97%

Imaginez que vous demandiez à un agent IA : « Analyse les données de ventes et produis un rapport au format DOCX ». L'agent charge les données, calcule les agrégats par catégorie, trace cinq graphiques, vérifie les statistiques et rédige le document. L'ensemble prend environ 15 minutes et plus de 150 000 tokens, alors que la fenêtre de contexte (la mémoire de travail du modèle) de Claude Sonnet 4.

5 dans Amazon Bedrock est de 200 000 tokens. Si chaque script écrit et chaque résultat s'accumulent dans cette mémoire, elle se remplit vite : l'agent plante en pleine tâche, perd en précision ou fait exploser le budget, car les tokens sont facturés. L'équipe d'AWS a montré, sur le projet ouvert Deep Insight, comment l'éviter.

Deux chiffres à retenir : un seul outil au lieu de deux réduit d'environ 95% les tokens ajoutés par chaque script, et le chargement des compétences à la demande raccourcit le prompt système d'environ 97%. Pour un développeur d'agents, c'est un moyen direct de les rendre moins chers et plus fiables.

Pourquoi un contexte saturé pose problème

Le risque ne se limite pas à l'épuisement de la fenêtre. Anthropic décrit un effet de context rot : plus le contexte contient de tokens, moins le modèle retrouve bien l'information utile. Les données périmées gênent, et la moindre erreur oblige à relancer tout le pipeline. AWS a donc rassemblé des techniques tirées des articles d'ingénierie d'Anthropic et des fonctionnalités de Strands Agents SDK en quatre couches d'« ingénierie de contexte ». C'est la deuxième partie d'une série ; Deep Insight est une solution multi-agents d'analyse de données bâtie sur Strands Agents SDK et Amazon Bedrock AgentCore, et tous les exemples s'appuient sur elle.

Couches 1 et 2 : séparer les agents et borner leurs réponses

La première couche est architecturale. Chaque agent spécialisé dispose de sa propre fenêtre, et le coordinateur ne reçoit qu'un résumé condensé. Dans Deep Insight, la hiérarchie est la suivante : Coordinator, Planner, Plan Reviewer, Supervisor, puis les agents de travail Coder, Validator, Reporter, Tracker et Auditor. L'état partagé est un dictionnaire shared_state de quatre champs seulement : le dernier message de l'agent précédent, les notes condensées clues, la checklist du plan et un bref journal. Grâce à cela, même Coder, l'agent le plus « gourmand », reste sous les 25 000 tokens.

La deuxième couche concerne les prompts. L'isolation ne suffit pas : si un agent répond longuement, le contexte du Supervisor gonfle quand même. Les prompts fixent donc des budgets de réponse : Coder, 1000–1500 tokens ; Validator, 800 ; Reporter, 1000. Le format est le même pour tous : statut, tâches accomplies, conclusions clés chiffrées, liste de fichiers. Une règle moins évidente s'y ajoute : chaque script est autonome, c'est-à-dire qu'il contient ses propres imports et recharge lui-même les données depuis le cache. Les variables ne persistent pas d'une exécution à l'autre, mais l'ancien code peut être évacué du contexte sans risque.

Couche 3 : seulement des références dans le contexte, les données dans des fichiers

C'est ici que l'économie est la plus marquée. En général, un agent dispose de deux outils : « écrire un fichier » et « exécuter ». Chaque script de 100 lignes entre alors en entier dans l'historique de la conversation, et après quelques analyses, il s'y trouve plus de mille lignes de code. Dans Deep Insight, un seul outil, write_and_execute_tool, accomplit les deux étapes et renvoie un court résumé : « 105 lignes écrites, exécution réussie, analyse de cinq catégories terminée ». Le code reste sur le disque ; le contexte n'en contient qu'environ trois lignes. Selon l'estimation d'AWS sur cet exemple, cela représente environ 95% d'économie de tokens par script.

D'autres techniques du même ordre fonctionnent aussi :

• Un module commun, coder_analysis_utils.py, est créé une seule fois ; ses fonctions s'importent en deux lignes, au lieu des 20–30 lignes que l'agent réécrirait à chaque fois.
• Le fichier all_results.txt sert de bloc-notes : Coder y ajoute les détails, et Supervisor reçoit un message d'environ 30 tokens.
• Des fichiers remplacent la transmission de données entre agents : calculation_metadata.json va de Coder à Validator, citations.json de Validator à Reporter, audit_findings.json d'Auditor à Reporter.
• Les compétences (Skills) se chargent à la demande. Le prompt système contient un catalogue d'environ 500 tokens, et l'agent n'ouvre le guide complet SKILL.md (environ 3 000 tokens) qu'en cas de besoin. Si l'on insérait tous les guides d'emblée, on atteindrait plus de 20 000 tokens à chaque appel. D'où une économie d'environ 97%, et un nouveau skill peut être ajouté sans redéploiement.

Réserves et mise en pratique

Les chiffres proviennent de l'implémentation de référence d'AWS elle-même et d'un seul exemple illustratif, avec un script de 105 lignes, et non d'un benchmark indépendant. Sur votre cas d'usage, l'effet sera différent : plus les scripts sont longs et les étapes nombreuses, plus il est marqué. La quatrième couche est la vérification par des agents indépendants (Validator, Auditor), complétée par des garde-fous contre le débordement du contexte. Dans le projet, c'est la dernière ligne de défense si les trois premières couches ont laissé passer quelque chose.

L'ordre pratique est le suivant : séparez les contextes entre les rôles, fixez des budgets de réponse dans les prompts, et déportez ce qui pèse lourd (code, tableaux, résultats) dans des fichiers que vous transmettez par référence. Le premier pas le plus économique consiste à fusionner « écrire » et « exécuter » en un seul outil. Le pattern agents-as-tools de Strands Agents SDK apporte l'isolation au niveau du framework, de sorte qu'il n'est pas nécessaire de réécrire l'orchestration de zéro.