Anthropic conseille de jeter la moitié des sous-agents : une seule boucle s'est révélée deux fois plus rapide

Anthropic a publié un article sur les cas où il vaut mieux replier les sous-agents dans la boucle principale de l'agent. Ses auteurs, l'équipe Applied AI, voient les déploiements en entreprise de l'intérieur. Leur conclusion est provocante : un agent unique doté de skills surpasse souvent, en qualité, à la fois l'approche « un seul prompt pour tout » et une architecture à base de multiples sous-agents. Il revient aussi moins cher et plus vite. Chez l'un des clients, la boucle unique s'est exécutée environ 2 fois plus vite que l'orchestration multi-agents. Chez un autre, une douzaine de sous-agents spécialisés dans l'agent destiné aux clients brisaient l'unité de ton de la marque et ajoutaient de la latence.

Pourquoi les sous-agents reproduisent l'organigramme

Le constat principal ressemble presque à la loi de Conway : l'architecture de l'agent reflète la structure de l'entreprise. Chaque équipe développe son propre sous-agent, et l'équipe plateforme place un orchestrateur par-dessus. S'ensuit une série de maux prévisibles :

• le contexte se perd lors des transmissions entre agents ;
• des centaines de sous-agents qui se chevauchent apparaissent, sans standards ni responsable ;
• le prompt système devient un « prompt Frankenstein », où chaque équipe a ajouté sa phrase ;
• les evals locales de chaque équipe servent de base aux décisions de la direction, alors qu'elles ne mesurent pas la qualité du système ;
• les latences augmentent, car chaque saut entre agents correspond à un appel de modèle distinct.

Côté économie des tokens, le tableau est simple. Chaque passation de contrôle implique de résumer le contexte, de dupliquer les instructions et d'ajouter un tour d'inférence. Vous payez tout cela deux fois : en argent et en temps de réponse.

Une seule boucle plutôt qu'un orchestre

Le schéma recommandé paraît modeste : une boucle, une fenêtre de contexte, des limites strictes sur le nombre de tours et sur le budget. Viennent ensuite quatre pratiques d'ingénierie :

• Révélation progressive. Le modèle ne voit que de courtes descriptions des skills et des outils, et ne charge les textes complets qu'en cas de besoin. C'est ainsi qu'Anthropic a réduit de plus de 80 % le prompt système de Claude Code.
• Regrouper les outils selon les intentions de l'utilisateur, et non selon l'API. Au-delà de 30–50 descriptions d'outils, la qualité du choix commence à se dégrader. Trente fines surcouches de méthodes REST valent donc moins qu'une dizaine d'outils correspondant à de vraies tâches.
• Vérifier les droits à l'intérieur des outils. Si l'accès n'est pas accordé, l'outil renvoie au modèle un refus explicite. Une seule boucle peut alors servir des utilisateurs aux niveaux d'accès différents, sans agent distinct par rôle.
• Une responsabilité centralisée de la qualité. Une seule petite équipe se charge entièrement du prompt système et de la qualité finale. Les autres équipes sont responsables des skills et des outils, pas des agents.

Pour autant, les sous-agents ne sont pas bannis. Anthropic cite trois cas où ils se justifient :

• une dégradation mesurable provoquée par un contexte gonflé ;
• le besoin de tâches parallèles avec un contexte vierge ;
• un agent qui s'embrouille entre les outils et des instructions contradictoires.

Il y a une condition : il faut découper les sous-agents par contexte, et non par type de tâche. Un découpage par type de tâche produit un « téléphone arabe », où chaque maillon déforme légèrement la requête initiale.

Migration : des exemples aux skills

L'article décrit la marche à suivre de façon assez concrète :

• D'abord, rassembler des exemples. 10 suffisent, ils serviront de jeu de comparaison avant/après.
• Fusionner les sous-agents les plus utilisés et les plus fortement couplés.
• Appeler les sous-agents restants comme des outils, et non comme des agents autonomes.
• Les transformer un par un en skills, et comparer le résultat aux exemples de référence après chaque étape.

Pour cela, Anthropic a publié sur GitHub un migration kit avec un skill qui aide à dérouler le processus.

Si vous avez en production un orchestrateur piloté avec une dizaine de spécialistes, commencez par mesurer : temps de réponse, nombre d'appels de modèle et coût par requête type, puis comparez avec une boucle unique sur les mêmes 10 exemples. Vérifiez aussi séparément que les descriptions d'outils ne sont pas gonflées : au-delà de 30–50, le regroupement par intentions apportera un gain avant même toute refonte d'architecture. La conclusion organisationnelle est aussi tranchée que la conclusion technique : les équipes cessent d'être propriétaires d'agents et deviennent propriétaires de skills et d'outils.

Cette histoire est d'ailleurs révélatrice pour toute l'industrie. L'an dernier, les orchestrateurs et les systèmes multi-agents étaient la tendance dominante ; aujourd'hui, on les reconstruit comme du legacy. L'auteur du résumé sur Telegram note qu'OpenAI est parvenue à des conclusions similaires dans son post sur ses Forward Deployed Engineers.