Quatre niveaux d'ingénierie du contexte pour les agents IA en production

Les agents IA en production échouent souvent lors de tâches complexes comme l'analyse de données parce qu'ils épuisent leurs fenêtres de contexte. Une nouvelle implémentation de référence d'Amazon Web Services, nommée Deep Insight, décrit une stratégie à quatre niveaux pour résoudre ce goulot d'étranglement. Publiée le 4 novembre 2026, cette guide détaille comment isoler, contrôler, externaliser et vérifier le contexte pour maintenir la précision et réduire les coûts.

Ce qui s'est passé

Les grands modèles de langage offrent des fenêtres de contexte généreuses, telles que les 200K tokens disponibles dans Anthropic Claude Sonnet 4.5 sur Amazon Bedrock. Cependant, les flux de travail réels consomment rapidement cette capacité. Une demande typique consistant à analyser des données de ventes et à générer un rapport implique plusieurs étapes, notamment le chargement des données, la validation statistique et la génération de graphiques. Ces étapes peuvent brûler plus de 150K tokens en seulement 15 minutes, entraînant des échecs en cours d'exécution, une précision dégradée due à des informations obsolètes et des coûts plus élevés.

Pour répondre à cela, les ingénieurs d'AWS ont développé Deep Insight, une solution multi-agent open source construite sur le SDK Strands Agents et Amazon Bedrock AgentCore. Le système applique une approche structurée de l'ingénierie du contexte, allant au-delà de simples ajustements de prompts vers une discipline architecturale holistique. L'implémentation montre que la combinaison de ces techniques peut réduire d'environ 95 % les tokens ajoutés par chaque script et diminuer les prompts système d'environ 97 %.

La guidance est organisée en quatre niveaux distincts : l'isolation du contexte au niveau architectural, son contrôle via les prompts, son externalisation vers le système de fichiers et sa vérification par des garde-fous indépendants. Cette méthode en couches garantit que lorsqu'une technique atteint ses limites, le niveau suivant prend le relais, empêchant la « pourriture du contexte » qui afflige les systèmes mono-agents.

Comment cela fonctionne

Le premier niveau se concentre sur l'isolation architecturale. Au lieu d'exécuter toutes les tâches dans un seul agent, Deep Insight utilise une hiérarchie d'agents spécialisés, incluant un Coordinateur, un Planificateur, un Superviseur et divers Agents Outils. Chaque agent opère dans sa propre fenêtre de contexte indépendante. Ils communiquent via un dictionnaire d'état partagé contenant uniquement des résumés compressés, ou « indices », plutôt que des historiques de conversation complets. Cela garantit que même les agents les plus actifs, tels que le Coder, restent sous la barre des 25K tokens.

Le deuxième niveau contrôle l'afflux de contexte grâce à une ingénierie stricte des prompts. Chaque agent dispose de budgets explicites de tokens de sortie. Par exemple, l'agent Coder est limité à 1 500 tokens car son code réel est sauvegardé dans des fichiers, et non renvoyé dans le chat. Les prompts imposent également une philosophie de code autonome, exigeant que chaque script inclue ses propres imports et sa logique de chargement de données. Cela évite la nécessité de conserver d'anciens extraits de code en mémoire, permettant ainsi de supprimer en toute sécurité le contexte obsolète.

Le troisième niveau, le plus impactant, externalise le contenu lourd vers le système de fichiers. Deep Insight remplace les outils séparés d'écriture et d'exécution par un unique write_and_execute_tool. Cet outil écrit le code Python dans un fichier et l'exécute immédiatement, ne renvoyant qu'un bref résumé de succès à l'agent. Le code lui-même n'entre jamais dans la fenêtre de contexte. De plus, la logique courante est stockée dans des modules réutilisables, et les résultats d'analyse détaillés sont sauvegardés dans des fichiers texte structurés comme all_results.txt. Les agents lisent ces fichiers uniquement lorsque nécessaire, gardant le contexte actif allégé.

Détails clés

• Deep Insight réduit l'utilisation du contexte des scripts d'environ 95 % grâce à un outil combiné d'écriture et d'exécution.
• Le chargement des compétences à la demande réduit la taille du prompt système d'environ 97 %.
• Le système utilise un dictionnaire shared_state pour transmettre uniquement des indices compressés et des avis de complétion entre les agents.
• Les agents Coder sont limités à 1 000–1 500 tokens de sortie, les obligeant à synthétiser plutôt qu'à déverser du code.
• Les fonctions utilitaires courantes sont pré-générées dans un module coder_analysis_utils.py pour éviter de régénérer du code dupliqué.
• Des fichiers de prise de notes structurés comme all_results.txt servent de bus de communication inter-agents, remplaçant le passage de messages verbeux.

Pourquoi c'est important

Pour les ingénieurs qui construisent des systèmes IA en production, la gestion du contexte n'est plus seulement une optimisation des performances ; c'est une exigence de fiabilité. Sans ces niveaux, les agents souffrent d'une dégradation de l'attention à mesure que la fenêtre de contexte se remplit. Les instructions importantes se perdent, et le modèle commence à halluciner ou à ignorer les contraintes récentes. En isolant les contextes, les équipes peuvent garantir que chaque sous-tâche reçoit toute l'attention du modèle sans interférence de l'historique non pertinent.

L'efficacité des coûts est un autre moteur critique. Dans les modèles de tarification par token, envoyer des centaines de milliers de tokens pour des tâches routinières est intenable. La stratégie d'externalisation basée sur les fichiers démontrée dans Deep Insight déplace la charge des appels API coûteux vers des opérations de stockage bon marché. Cela permet aux développeurs de construire des agents plus complexes et à long terme sans augmentations prohibitives des coûts.

Enfin, cette approche améliore la débogabilité et la maintenance. Lorsque le code et les résultats sont stockés dans des fichiers plutôt que cachés dans l'historique éphémère du chat, les développeurs peuvent inspecter directement les artefacts. La séparation des responsabilités signifie que les erreurs dans un agent ne corrompent pas nécessairement l'état d'un autre, rendant le système plus résilient face aux défaillances partielles.

Ce que vous pouvez faire

• Adoptez une architecture multi-agent où des travailleurs spécialisés gèrent des tâches distinctes avec des fenêtres de contexte isolées.
• Implémentez des budgets stricts de tokens de sortie dans vos prompts système pour empêcher les agents de générer du texte inutile et verbeux.
• Remplacez les outils séparés d'écriture et d'exécution de code par un outil unique qui écrit sur disque et ne renvoie que des résumés d'exécution.
• Imposez la génération de code autonome en exigeant que les agents incluent tous les imports et le chargement de données dans chaque script.
• Utilisez le système de fichiers comme bus de communication en sauvegardant les résultats intermédiaires dans des fichiers structurés que les agents avalants peuvent lire.
• Pré-générez des modules utilitaires communs pour éviter de répéter du code standard (boilerplate) sur plusieurs tours d'agent.