Scoped Context : le pattern qui rend les agents IA vraiment autonomes
#Un agent qui relit tout, c'est un agent qui perd du temps
Tu as déjà lancé un agent IA sur un projet, et remarqué qu'il passe un temps déraisonnable à explorer le code avant de faire quoi que ce soit ? C'est normal. La plupart des agents adoptent une approche brute-force : ils chargent un maximum de contexte — fichiers, historique, documentation — en espérant que le modèle trouvera ce qui est pertinent.
Le problème, c'est que le contexte est une ressource finie. Les transformers distribuent leur attention entre tous les tokens présents dans la fenêtre de contexte, avec une dégradation qui suit une courbe quadratique. Plus tu ajoutes de tokens, plus la qualité se dilue. Anthropic appelle ce phénomène le context rot : le modèle a accès à tout, mais ne se concentre plus sur rien.
Résultat concret : un agent qui charge 100 000 tokens de contexte alors qu'il n'en a besoin que de 15 000 va gaspiller 30 à 50 % de son budget en exploration inutile. Il sera plus lent, plus coûteux, et moins précis.
Le principe fondamental du context engineering tient en une phrase : trouver le plus petit ensemble de tokens à haute valeur qui maximise la qualité des résultats. Le scoped context est la mise en pratique de ce principe dans les systèmes multi-agents.
#L'intuition : donner à chaque agent uniquement ce dont il a besoin
Le scoped context (contexte ciblé), c'est l'idée de ne jamais donner à un agent l'intégralité du projet. Au lieu de ça, chaque agent — ou chaque session — reçoit un paquet minimal composé de :
- L'état global : où en est le projet (phase, progression)
- Un résumé du passé : ce qui a été fait avant cette session
- La mission ciblée : ce que cet agent doit faire, précisément
- Le contexte technique minimal : les 3-4 fichiers ou informations directement pertinents
C'est comme la différence entre donner à un développeur accès à tout le monorepo et lui dire "débrouille-toi", versus lui envoyer un ticket clair avec les fichiers concernés et le contexte métier nécessaire. Le second cas est évidemment plus efficace.
#Les quatre stratégies fondamentales
Anthropic a formalisé quatre stratégies de gestion du contexte dans leur article sur le context engineering pour les agents IA. Le scoped context les combine toutes.
#Write : externaliser l'état
Plutôt que de tout garder dans la fenêtre de contexte, l'agent écrit son état dans des fichiers externes. Un fichier de progression, un journal de session, des notes structurées. Ces fichiers servent de mémoire persistante entre les sessions.
Exemple concret : Devin (l'agent de Cognition) crée spontanément des fichiers CHANGELOG.md et SUMMARY.md pour externaliser son état. Claude Code maintient des fichiers CLAUDE.md comme mémoire partagée. Le pattern est universel.
#Select : charger dynamiquement
Au lieu de charger toute la documentation upfront, l'agent va chercher l'information quand il en a besoin. Tu maintiens des références légères (chemins de fichiers, URLs, identifiants) et l'agent utilise des outils ciblés (grep, glob, recherche sémantique) pour récupérer le contenu au bon moment.
C'est ce que Martin Fowler appelle le progressive disclosure : l'agent découvre le contexte de manière incrémentale, guidé par la structure du projet et les conventions de nommage.
#Compress : résumer l'historique
Quand la fenêtre de contexte se remplit, l'agent condense l'historique en un résumé compact. Les outputs d'outils volumineux, les échanges obsolètes, les résultats intermédiaires sont remplacés par un digest essentiel.
Les priorités de compression :
- Préserver : les décisions architecturales, les bugs non résolus, les détails d'implémentation en cours
- Jeter : les sorties d'outils redondantes, les logs d'interactions résolues
#Isolate : séparer les contextes
C'est la stratégie clé du scoped context. Plutôt qu'un agent unique qui gère tout, tu décomposes le travail entre plusieurs agents spécialisés, chacun avec sa propre fenêtre de contexte isolée.
Chaque sous-agent travaille avec un contexte chirurgical et retourne un résumé condensé (1 000 à 2 000 tokens) au coordonnateur, même s'il a consommé des dizaines de milliers de tokens en interne.
#En pratique : orchestrateur et workers
Le scoped context s'implémente avec une architecture hub-and-spoke : un agent coordonnateur (le hub) délègue des tâches à des agents spécialisés (les spokes).
| Approche | Contexte par agent | Taux de succès | Coût tokens |
|---|---|---|---|
| Agent unique (brute-force) | Tout le projet | ~40% | Élevé + retries |
| Multi-agents (scoped) | Contexte ciblé par tâche | ~80% | Réduit de 67% par worker |
#Comment fonctionne le coordonnateur
Le coordonnateur maintient une vue d'ensemble du projet. Son rôle :
- Décomposer la tâche en sous-tâches indépendantes
- Préparer un paquet de contexte minimal pour chaque worker
- Dispatcher les tâches aux agents spécialisés
- Synthétiser les résumés retournés par chaque worker
- Décider de la suite : nouvelle tâche, correction, ou terminaison
#Comment fonctionne un worker
Chaque worker reçoit un contexte scopé :
Mission : implémenter la validation du formulaire de contact
Fichiers concernés : src/components/ContactForm.tsx, src/lib/validation.ts
Contraintes : utiliser zod, messages d'erreur en français
État global : phase 2/5, formulaire de base déjà créé
Le worker ne voit pas le reste du projet. Il ne connaît pas la structure de la base de données, ni le système d'authentification, ni la configuration du déploiement. Il a exactement ce qu'il faut pour accomplir sa tâche.
Quand il termine, il retourne un résumé structuré :
Résultat : validation implémentée
Fichiers modifiés : ContactForm.tsx, validation.ts
Décisions prises : schéma zod avec 4 règles, erreurs inline
Questions ouvertes : aucune
Ce résumé est réinjecté dans le contexte du coordonnateur, qui peut alors dispatcher la tâche suivante.
#Les preuves : chiffres de la recherche
Le scoped context n'est pas une intuition — c'est un pattern validé par la recherche.
Une étude sur les assistants de code multi-agents (arxiv 2508.08322) a mesuré un taux de succès de 80 % avec une architecture hub-and-spoke, contre 40 % pour un agent unique sur les mêmes tâches. La définition de succès : passer tous les tests et satisfaire les critères d'acceptation sans correction humaine.
Côté tokens, chaque sous-agent consomme 67 % de tokens en moins grâce à l'isolation du contexte. Le système multi-agents utilise plus de tokens au total (environ 100 000 par tâche contre 10 000-20 000 pour un agent unique), mais il élimine les cycles de retry et de debugging qui gonflent le coût réel de l'approche mono-agent.
Anthropic rapporte de son côté une amélioration de 90 % des performances sur les tâches de recherche complexes en utilisant des sous-agents avec contextes isolés.
#Qui utilise déjà le scoped context
#Claude Code
Claude Code implémente le scoped context via son système de subagents. Quand tu lances un Task, Claude crée un sous-agent avec sa propre fenêtre de contexte. Ce sous-agent travaille indépendamment — il peut lire des fichiers, exécuter des commandes, explorer le code — puis retourne un résumé au contexte principal.
Le fichier CLAUDE.md joue le rôle de mémoire partagée : chaque agent (principal ou sub) le charge au démarrage pour avoir les conventions du projet sans encombrer le contexte avec l'intégralité du code.
#Devin (Cognition)
L'agent de Cognition externalise son état via des fichiers CHANGELOG.md et SUMMARY.md créés spontanément. Fait intéressant : cette externalisation est un comportement émergent — le modèle le fait sans instruction explicite, ce qui suggère que l'entraînement favorise la gestion externe de la mémoire.
Cognition a aussi découvert un phénomène appelé context anxiety : Sonnet 4.5 manifeste une conscience de sa fenêtre de contexte et termine prématurément ses tâches quand il approche de la limite, même s'il lui reste beaucoup de tokens. Leur solution : faire croire au modèle qu'il a 1 million de tokens disponibles tout en plafonnant l'usage à 200 000 tokens. Ce simple changement normalise le comportement.
#Google ADK
Le framework Agent Development Kit de Google structure le contexte en quatre niveaux :
| Niveau | Portée | Exemples |
|---|---|---|
| Working Context | Une seule invocation du modèle | Le prompt actuel, les outils disponibles |
| Session | Une conversation complète | Messages, appels d'outils, résultats, erreurs |
| Memory | Au-delà de la session | Connaissance long-terme, recherchable |
| Artifacts | Données volumineuses | Fichiers, binaires, datasets adressés par nom |
Le mécanisme clé est le scoped handoff : quand un agent passe la main à un autre, il peut choisir de transmettre tout le contexte de travail (mode par défaut) ou seulement le minimum nécessaire (mode none). Ce contrôle fin évite la pollution de contexte entre agents.
#Concevoir une architecture scoped
Si tu veux appliquer le scoped context dans tes propres systèmes, voici les principes directeurs.
1. Commence par la décomposition. Avant même de penser au contexte, décompose ta tâche en sous-tâches indépendantes. Plus les tâches sont isolées, plus le scoping sera efficace.
2. Définis un format de handoff. Chaque worker doit retourner un résumé structuré au coordonnateur. Définis ce format à l'avance : résultat, fichiers modifiés, décisions prises, questions ouvertes.
3. Utilise des fichiers de progression. Un simple progress.txt ou un JSON de tâches suffit. L'important, c'est que chaque session puisse comprendre l'état du projet en lisant un seul fichier, sans avoir à explorer tout l'historique.
4. Scope les outils aussi. Ne donne pas à un worker d'outils dont il n'a pas besoin. Un agent qui corrige du CSS n'a pas besoin d'accéder à la base de données.
5. Mesure et itère. Compare le taux de succès et la consommation de tokens entre l'approche brute-force et l'approche scopée. Les gains sont souvent spectaculaires, mais ils varient selon le type de tâche.
#Ce qu'il faut retenir
Le scoped context est le pattern qui transforme un agent coûteux et approximatif en un système multi-agents efficace et fiable. Les points essentiels :
- Le contexte est une ressource finie — chaque token superflu dégrade la performance
- Un agent qui reçoit uniquement ce dont il a besoin est deux fois plus performant qu'un agent qui voit tout
- L'architecture hub-and-spoke (coordonnateur + workers) réduit les tokens de 67 % par sous-agent
- Les outils existants implémentent déjà ce pattern : subagents dans Claude Code, niveaux de contexte dans Google ADK, externalisation d'état dans Devin
Le scoped context n'est pas une optimisation optionnelle. C'est la fondation sur laquelle reposent tous les systèmes multi-agents qui fonctionnent en production.