Votre agent IA oublie tout : les astuces MCP qui règlent l'engorgement du contexte

Le problème dont personne ne parle

Toute démo d'un agent de codage IA montre la même chose : un terminal propre, une consigne claire, un résultat net. Personne ne vous montre la troisième heure, quand l'agent a lu quarante fichiers, lancé une douzaine de suites de tests et rempli son context window du bruit produit par chaque commande qu'il a exécutée. À ce stade, l'agent ne devient pas plus intelligent. Il devient plus bête, oublieux, et prompt à répéter avec assurance un travail déjà terminé.

C'est le problème le moins glamour et le plus universel du codage agentique. Le contexte est la mémoire de travail de l'agent, et elle est finie. Tout ce que l'agent lit se dispute le même espace, et l'essentiel de ce qu'il lit est du déchet : journaux de build, traces de pile, listings de répertoires, le texte intégral de fichiers dont une seule ligne lui suffisait. La fenêtre se remplit de sédiments, et le raisonnement qui rendait l'agent utile au départ se fait évincer.

Les outils qui règlent ce problème ne sont pas ceux qui gagnent les comparatifs de benchmarks. Ce sont de la plomberie. Et en octobre, c'est la plomberie qui est montée dans le classement des tendances de GitHub.

L'idée derrière le sandboxing des sorties d'outils

L'un des projets les plus intéressants à avoir émergé est une couche d'optimisation du contexte pour les agents de codage, qui s'attaque au problème à la source. Son chiffre phare : une réduction d'environ 98 % du volume de sortie d'outils qui atteint le modèle.

Le mécanisme est simple dans son principe. Au lieu de laisser la sortie brute d'une commande se déverser directement dans la conversation, vous l'exécutez dans un sandbox et ne donnez au modèle que ce dont il a besoin dans le résultat : un résumé, un code de sortie, les lignes précises qui correspondent à une requête. La transcription complète reste à disposition du modèle pour qu'il la récupère délibérément, mais elle n'occupe pas la fenêtre au cas où elle serait pertinente.

C'est la discipline qu'un bon ingénieur applique par habitude. On ne colle pas un journal entier dans un chat quand une seule ligne d'erreur est le sujet. Un agent laissé à lui-même fait exactement le contraire.

Il y a une facture à la clé, et c'est pourquoi cet outillage n'est pas un simple raffinement d'ingénierie. Un context window n'est pas gratuit. Chaque token que le modèle doit traiter coûte de l'argent et du temps, et chaque token qu'il doit mémoriser coûte de l'attention. Un outil qui déverse cent mille tokens de sortie de build dans une session vous facture deux fois : une fois pour les tokens, et de nouveau pour la dégradation du jugement du modèle quand le signal est enterré. Cette réduction de 98 % est en réalité une correction de qualité déguisée en économie de coûts.

Une mémoire qui survit à la session

La seconde moitié du problème, c'est que les agents oublient d'une session à l'autre, pas seulement à l'intérieur d'une session. Fermez le terminal et le contexte disparaît. Rouvrez-le demain et l'agent n'a aucune idée de ce que vous avez décidé, de l'approche que vous avez rejetée, ni pourquoi le code ressemble à ce qu'il est. Vous réexpliquez, l'agent redérive, et quelque part une décision est prise deux fois.

Les outils de mémoire persistante de ce domaine adoptent des approches différentes. L'un des plus visibles capture ce que fait l'agent pendant une session, le compresse avec un modèle et réinjecte les parties pertinentes dans les sessions futures. Le discours est peu glamour mais juste : un agent qui se souvient de la forme de votre projet vaut plus qu'un agent marginalement plus intelligent sur une tâche unique. Les principaux fournisseurs de modèles vont dans le même sens, en ajoutant des réglages qui permettent à un subagent de compacter son propre context plus tôt que la conversation parente, précisément pour ne pas traîner l'historique de toute une session dans une tâche qui n'en a pas besoin.

La question de conception intéressante ici, c'est quoi mémoriser. Tout mémoriser, et vous avez reconstruit le problème d'origine sous une forme plus lente. Mémoriser trop peu, et la mémoire est inutile. Les projets qui prennent de l'élan sont ceux qui mémorisent de façon sélective, en partant du principe qu'un bon résumé du mois écoulé vaut mieux qu'un compte rendu parfait de la dernière heure.

Le routing comme stratégie de contexte

La troisième pièce du puzzle, c'est le routing : décider, avant qu'une tâche ne s'exécute, de quel modèle et de quels outils elle a besoin, pour qu'elle ne soit pas chargée de capacités qu'elle n'utilisera jamais. Un modèle à qui l'on a signalé dix-sept intégrations différentes dépense du contexte sur les dix-sept même si la tâche n'en demande qu'une. Imposer le routing sur toutes les plateformes ressemble à un détail d'infrastructure. C'est en fait une décision de budget de contexte déguisée.

C'est ici que le problème cesse de ressembler à un problème de cache et commence à ressembler à de la conception de systèmes. Le context window de l'agent est une ressource, comme le sont la mémoire et le disque, et les outils qui le traitent comme telle sont ceux qui gardent les agents cohérents sur de longues tâches. Ce n'est pas un hasard si les projets de sandboxing, de mémoire et de routing convergent : ce sont trois vues de la même rareté.

Le motif du subagent en est l'exemple le plus clair. Quand un agent engendre un assistant pour un travail étroit, cet assistant n'a pas besoin d'hériter de toute la conversation. Lui tendre un contexte propre contenant seulement la tâche en cours coûte moins cher et est plus précis, et c'est pourquoi les harnesses récents laissent un subagent compacter son propre context plus tôt que le parent. Le parent garde le long historique ; l'enfant obtient un bureau neuf. Les équipes qui ont fait tourner des agents sur des refactorisations d'une semaine en viennent généralement à cette règle d'elles-mêmes, souvent après avoir vu un subagent passer toute sa fenêtre à relire une conversation dont il n'avait pas besoin.

Pourquoi cela arrive maintenant

Aucun de ces problèmes n'est nouveau. Les agents perdent du contexte depuis le tout premier. Ce qui a changé, c'est qu'on attend désormais d'un agent qu'il tourne pendant des heures, sur de nombreuses sessions, sur un travail qui compte. Un jouet ne perd rien quand il oublie. Un outil sur lequel une équipe s'appuie pour une refactorisation d'une semaine perd beaucoup.

Le marché l'a remarqué. Il y a deux ans, « notre agent a une fenêtre de contexte de 200k » était un argument de vente. Aujourd'hui, la question utile est quelle fraction de cette fenêtre est consacrée au signal. Les fournisseurs qui l'ont compris livrent des contrôles de compactage et l'isolation du contexte des subagents. La communauté livre la plomberie qui rend le reste supportable.

La conclusion peu glamour

On est tenté de lire l'actualité des agents d'octobre comme une histoire de modèles plus intelligents et de plugins plus astucieux. L'histoire plus discrète et plus durable concerne l'hygiène. Les agents sont devenus assez utiles pour tourner longtemps, et les longues durées exposent chaque faiblesse dans leur façon de gérer leur propre mémoire.

Les projets qui grimpent dans les classements de tendances sont ceux qui acceptent une vérité banale : le goulot d'étranglement du travail autonome est rarement l'intelligence brute. C'est la capacité de rester sur la tâche sans se noyer dans ses propres notes. Corrigez la mémoire, mettez le bruit en sandbox, acheminez les capacités, et un modèle simplement compétent paraît soudain excellent. Ratez cela, et même un modèle de frontière passera son après-midi à relire un fichier de journal qu'il a déjà lu cinq fois.