Anthropic appelle à replier les sous-agents : une seule boucle avec des skills bat les orchestrateurs

L'équipe Applied AI d'Anthropic a publié un article sur les cas où il vaut mieux replier les sous-agents dans la boucle principale de l'agent. La conclusion, tirée de déploiements réels en entreprise, dérange ceux qui ont passé l'an dernier à construire des orchestrateurs : un agent unique doté de skills fait souvent mieux, en qualité, que le schéma « un seul prompt pour tout » comme que la constellation de sous-agents. Et il revient moins cher et répond plus vite. Chez un client, la boucle unique a tourné environ 2 fois plus vite que l'infrastructure multi-agents. Chez un autre, une douzaine de sous-agents spécialisés dans l'agent client cassait l'unité de ton de la marque et ajoutait de la latence.

La loi de Conway appliquée aux agents

Les auteurs décrivent une dynamique organisationnelle bien connue. Chaque équipe construit son sous-agent, puis l'équipe plateforme pose un orchestrateur par-dessus. Résultat : l'architecture de l'agent reproduit l'organigramme de l'entreprise, avec tous ses travers :

• le contexte se perd lors des passations entre agents ;
• des centaines de sous-agents se chevauchent, sans standards ni responsable ;
• un « prompt Frankenstein » apparaît, où chaque équipe a ajouté sa phrase ;
• les décisions reposent sur des evals locaux, qui ne reflètent pas la qualité du système dans son ensemble ;
• les latences augmentent, car chaque transition entre agents est un appel de modèle de plus.

Sur le plan de l'économie des tokens, c'est un double coup. Chaque passation de tâche exige de résumer le contexte : cela ajoute des tokens d'entrée inutiles et fait courir le risque de perdre un détail nécessaire. L'effet « téléphone arabe » pèse sur la qualité, et les tours d'appels superflus sur le temps de réponse.

Une boucle, une fenêtre, une divulgation progressive

L'alternative proposée par Anthropic se présente ainsi :

• une seule boucle et une seule fenêtre de contexte, avec des limites sur le nombre de tours et sur le budget ;
• la divulgation progressive (progressive disclosure) : le modèle voit de courtes descriptions des skills et des outils, et ne charge les versions complètes que lorsqu'il en a besoin. C'est ainsi que l'équipe a réduit le prompt système de Claude Code de plus de 80% ;
• les outils sont regroupés par intention de l'utilisateur, et non par API. Au-delà de 30–50 descriptions d'outils, le choix commence à se dégrader ;
• les droits d'accès sont vérifiés à l'intérieur des outils, et le modèle reçoit un refus explicite. Une seule boucle peut alors servir des utilisateurs de niveaux d'accès différents, sans agents distincts pour chaque rôle.

Le dernier point est particulièrement pratique. Au lieu de multiplier les agents selon les groupes d'utilisateurs, l'autorisation passe au niveau de l'outil, et l'agent apprend à réagir de façon appropriée à un refus.

Quand les sous-agents restent nécessaires

Les auteurs ne demandent pas d'y renoncer complètement. Trois cas sont justifiés :

• une dégradation mesurable due à un contexte gonflé ;
• des tâches parallèles qui exigent un contexte vierge ;
• un agent qui s'embrouille entre les outils et les instructions contradictoires.

Ils recommandent par ailleurs de découper les sous-agents par contexte, et non par type de tâche. C'est précisément le découpage par type de tâche qui produit le téléphone arabe.

Plan de migration

L'article propose l'ordre d'action suivant :

1. Rassembler des exemples. Même 10 suffisent : ils serviront de base de comparaison. 2. Fusionner les sous-agents les plus utilisés et les plus fortement couplés. 3. Appeler les autres comme des outils. 4. Les transformer un par un en skills, en comparant le résultat à la référence après chaque étape.

La propriété change aussi sur le plan organisationnel. Les équipes cessent d'être propriétaires d'agents et le deviennent de skills et d'outils. Une seule petite équipe centrale répond du prompt système et de la qualité d'ensemble. Pour la migration, Anthropic a publié un skill migration kit sur GitHub.

Que faire dès maintenant

Si vous avez un schéma multi-agents en production, commencez par un audit : comptez les sous-agents, mesurez les latences moyennes aux passations et la taille du prompt système. Constituez un jeu de 10 cas réels et passez-le sur une boucle unique avec skills. Si la qualité ne baisse pas, tandis que le temps et la consommation de tokens diminuent, vous pouvez simplifier le schéma. Vérifiez à part que le jeu d'outils ne dépasse pas 30–50 descriptions. Si c'est le cas, regroupez-les par intention de l'utilisateur. Et désignez dès le départ un responsable du prompt commun et des evals, faute de quoi le « Frankenstein » reviendra, cette fois sous forme de skills.

Selon l'auteur de l'analyse, OpenAI est arrivée à une conclusion similaire dans un billet sur les Forward Deployed Engineers. La tendance est claire : il y a un an, les orchestrateurs servaient de vitrine de maturité ; aujourd'hui, ils ressemblent de plus en plus à du legacy.