Par Tsuky 
Pour automatiser un service client, certaines entreprises construisent aujourd'hui de véritables organigrammes d'agents IA. Un premier modèle identifie le problème, un second détermine la procédure, un troisième consulte les données et un quatrième rédige la réponse.
L'ensemble est supervisé par un orchestrateur chargé de répartir les tâches et de récupérer les résultats.
Cette architecture paraît logique : chaque agent possède sa spécialité, à la manière d'une équipe humaine.
Mais elle présente un défaut que les démonstrations techniques ne montrent pas toujours. Chaque transfert introduit du délai, des coûts et un risque de perdre une partie du contexte.
Anthropic vient de publier un guide qui remet en question cette approche dans certaines applications professionnelles.
Son message n'est pas que les sous-agents sont inutiles. Il est qu'ils devraient avoir une raison technique mesurable d'exister.
Quand l'architecture des agents devient un organigramme d'entreprise
L'article, signé Diane Sarkis et publié sur les ressources officielles de Claude, décrit un problème rencontré dans plusieurs déploiements accompagnés par l'équipe Applied AI d'Anthropic.
Les entreprises organisent souvent leurs agents selon leurs départements ou les catégories de demandes qu'elles reçoivent.
Un spécialiste traite la facturation, un autre les retours, un autre le support technique. Un routeur central décide à qui envoyer chaque question.
Cette séparation facilite parfois la répartition des responsabilités, mais elle peut reproduire dans le logiciel les complications de l'organisation humaine.
Les équipes ajoutent leurs propres prompts, leurs propres outils et leurs propres critères de réussite.
À mesure que le système grandit, personne ne possède nécessairement une vision complète de la qualité de l'expérience finale.
Anthropic rapproche ce phénomène de la loi de Conway : la structure d'un système informatique tend à reproduire les relations entre les équipes qui le construisent.
Un découpage compréhensible pour une organisation n'est pourtant pas nécessairement le meilleur découpage pour un modèle d'intelligence artificielle.
Chaque transfert entre agents fait perdre une partie de l'information
Prenons une application chargée de résoudre un problème de livraison.
Un agent lit d'abord la demande et identifie la commande. Il transmet ensuite un résumé à un spécialiste des expéditions, qui consulte le transporteur.
Un troisième agent reçoit le résultat pour préparer la réponse.
À chaque passage, certaines informations de la demande initiale risquent de disparaître du résumé.
Un détail apparemment secondaire pour le premier agent peut devenir essentiel pour le suivant.
Anthropic décrit cet effet comme un jeu du téléphone : plus les transferts se multiplient, plus le contexte risque de se dégrader.
Le phénomène est particulièrement problématique lorsque les tâches sont fortement dépendantes.
Un agent qui a préparé un plan connaît les raisons de ses décisions. Un autre, qui reçoit seulement le résultat, peut ne pas disposer des éléments nécessaires pour l'adapter correctement.
Pour ces tâches, conserver les informations dans une boucle d'exécution commune peut améliorer la cohérence.
Un client a obtenu une exécution environ deux fois plus rapide
Anthropic avance plusieurs observations issues de ses déploiements en entreprise.
L'une des organisations accompagnées avait conçu un système comportant une douzaine de sous-agents spécialisés pour une application destinée aux clients.
Cette architecture rendait difficile le maintien d'un ton homogène et ajoutait de la latence aux interactions.
Dans un autre cas cité, la comparaison entre une architecture multi-agents et une boucle unique a montré un temps d'exécution approximativement divisé par deux.
Le chiffre est intéressant, mais il faut préciser sa portée.
Il s'agit d'une observation rapportée par Anthropic pour un cas particulier, pas d'un benchmark indépendant démontrant que toutes les applications deviennent deux fois plus rapides avec un agent unique.
Le gain dépend du nombre d'appels évités, des tâches effectuées et du coût de la coordination.
Une organisation où plusieurs agents travaillent réellement en parallèle peut obtenir des résultats très différents.
La solution proposée : un agent principal et des compétences à la demande
L'approche recommandée repose sur une boucle d'exécution principale.
L'agent reçoit un objectif, construit un plan, utilise des outils, examine les résultats et poursuit son travail jusqu'à obtenir une réponse ou atteindre une limite définie.
La différence vient de la manière dont les compétences sont organisées.
Au lieu de créer un nouveau sous-agent pour chaque métier, les développeurs peuvent mettre les instructions spécialisées dans des skills.
Un skill contient des procédures, des règles et des connaissances opérationnelles dont l'agent peut avoir besoin pour une tâche.
Il n'est pas nécessaire de charger immédiatement toutes ces informations dans le contexte.
L'agent peut d'abord disposer de descriptions succinctes, puis charger les instructions détaillées lorsqu'elles deviennent pertinentes.
Anthropic appelle ce mécanisme la divulgation progressive du contexte.
Le même principe s'applique aux outils, qui peuvent être recherchés et exposés à l'agent uniquement lorsqu'ils sont utiles.
L'objectif est de conserver une intelligence centrale sans saturer son contexte de centaines de règles et de fonctions inutilisées.
Anthropic affirme avoir réduit de plus de 80 % le prompt de Claude Code
Pour expliquer l'intérêt de cette organisation, Anthropic cite un changement apporté à Claude Code.
L'entreprise indique avoir réduit de plus de 80 % son prompt système pour les modèles les plus avancés, notamment en déplaçant certaines informations vers des ressources chargées progressivement.
Cette réduction ne signifie pas que Claude Code utilise automatiquement 80 % de tokens en moins sur toutes les tâches.
Le prompt système ne représente qu'une partie du contexte total.
Les documents consultés, les résultats des outils, l'historique de travail et les réponses générées contribuent également à la consommation.
Le bénéfice recherché est surtout d'éviter de présenter au modèle, dès le départ, des consignes qui ne concernent pas la mission en cours.
Cette approche devient d'autant plus intéressante que les modèles récents peuvent gérer eux-mêmes davantage de décisions d'orchestration.
Une partie de la logique auparavant codée dans des routeurs et des planificateurs spécialisés peut ainsi être prise en charge par la boucle principale.
Pourquoi un agent unique peut produire de meilleures réponses
La qualité d'une réponse dépend rarement d'une seule opération.
Un assistant chargé d'étudier un incident informatique peut découvrir des informations nouvelles pendant ses recherches.
Ces informations peuvent modifier le diagnostic initial et rendre nécessaire une autre série de vérifications.
Dans une architecture très segmentée, le premier agent peut avoir terminé son travail avant que le dernier ne découvre un élément décisif.
Le système doit alors organiser de nouveaux transferts ou demander à un orchestrateur de reconstruire le contexte.
Avec une boucle unique, le même agent conserve une vision de son plan, de ses recherches et des résultats obtenus.
Il peut modifier sa stratégie en fonction des découvertes.
Anthropic indique avoir observé, dans plusieurs comparaisons d'entreprise, des résultats plus satisfaisants avec un agent principal doté de skills qu'avec certaines architectures multi-agents.
Mais ce constat ne supprime pas une difficulté majeure : une fenêtre de contexte partagée peut elle-même devenir trop longue.
C'est pourquoi la gestion du contexte reste un élément central de l'architecture recommandée.
Les sous-agents restent utiles pour le travail parallèle
Anthropic insiste sur une nuance importante : il existe toujours de bonnes raisons de créer plusieurs agents.
La première concerne la recherche parallèle.
Si plusieurs sources indépendantes doivent être examinées, des agents distincts peuvent travailler simultanément.
Leur résultat peut ensuite être transmis sous une forme compacte à l'agent principal.
La deuxième concerne la vérification indépendante.
Un agent chargé de produire du code et un autre chargé de tester ce code ne doivent pas nécessairement disposer du même contexte.
Lorsque le vérificateur a uniquement besoin d'exécuter les tests et de rapporter les résultats, son indépendance peut être utile.
La troisième situation apparaît lorsqu'un agent unique devient moins performant parce que son contexte est trop volumineux ou que ses instructions sont contradictoires.
Créer un sous-agent disposant d'un contexte neuf peut alors être préférable.
Les sous-agents peuvent également contribuer à séparer des permissions ou des environnements d'exécution.
L'important est de démontrer leur utilité par des mesures plutôt que de les ajouter par habitude.
Une architecture simplifiée ne signifie pas moins de sécurité
Réduire le nombre d'agents peut simplifier l'organisation des permissions, mais cela ne garantit pas automatiquement la sécurité du système.
Un agent principal disposant de nombreux outils doit rester soumis à des contrôles techniques.
Anthropic recommande de conserver certaines limites dans l'infrastructure qui exécute les actions.
Il peut s'agir de budgets de coût, d'un nombre maximal d'étapes ou d'autorisations nécessaires avant certaines opérations.
Ces contrôles ne doivent pas dépendre uniquement des instructions données au modèle.
Si une action modifie des données ou déclenche une opération sensible, le système qui héberge l'agent peut imposer une validation.
Dans une application utilisée par plusieurs salariés, les outils doivent également vérifier les droits de chaque utilisateur.
Une boucle agentique commune ne doit pas devenir un moyen de contourner les frontières entre comptes et services.
La simplification porte sur l'orchestration de l'intelligence, pas sur la suppression des protections.
Le véritable problème des grands systèmes : personne ne mesure le résultat final
Anthropic identifie une autre faiblesse dans les architectures conçues par de nombreuses équipes.
Chaque groupe développe son sous-agent et construit des tests correspondant à son propre périmètre.
Le spécialiste des commandes mesure la qualité de la recherche de commandes. Celui des livraisons évalue la précision du suivi. Celui des retours surveille les procédures de remboursement.
Mais ces scores ne garantissent pas que l'application complète résout correctement la demande de l'utilisateur.
Un transfert entre deux spécialistes peut introduire une erreur qui n'apparaît dans aucun de leurs tests individuels.
Anthropic recommande donc de maintenir des évaluations de bout en bout.
Elles doivent mesurer si le système accomplit effectivement les tâches représentatives des utilisateurs.
Les tests spécialisés restent utiles, mais ils ne peuvent pas remplacer cette vision globale.
Une petite équipe centrale devrait également conserver la responsabilité du prompt principal et des règles communes.
Les équipes métiers peuvent continuer d'entretenir leurs propres skills et outils, sans ajouter toutes leurs exigences directement au prompt partagé.
Un kit GitHub pour migrer progressivement
La publication s'accompagne d'un dépôt public intitulé single-agent-loop-kit, accessible sur le compte GitHub d'Anthropic.
Il propose un ensemble de fichiers de référence, de scripts et d'exemples permettant d'analyser une architecture existante.
La méthode commence par un inventaire des sous-agents et de leurs interactions.
Le développeur établit ensuite une base de comparaison : qualité des tâches terminées, latence, nombre d'appels, consommation de tokens et coût.
Le kit aide à identifier les sous-agents qui pourraient être fusionnés, remplacés par des skills ou exposés comme outils.
Chaque modification doit être suivie d'une nouvelle évaluation.
Si la suppression d'un sous-agent dégrade les résultats, Anthropic recommande de le conserver ou de revoir la migration.
Le dépôt inclut un exemple de service client avec plusieurs agents spécialisés ainsi qu'une boucle de référence.
Il est important de préciser qu'il s'agit d'un outil d'aide à la migration, pas d'un service qui transforme automatiquement n'importe quel système en architecture optimale.
Son README indique explicitement que le projet constitue une implémentation de référence non maintenue et sans garantie d'évolution.
Le kit ne prouve pas que l'agent unique est toujours supérieur
Anthropic publie des exemples d'exécution du kit sur un système de démonstration.
Mais la documentation précise que certaines étapes n'ont pas encore été évaluées sur de véritables modèles et que le kit n'a pas été testé sur toutes les architectures qu'il pourrait rencontrer.
Cette transparence limite la portée des conclusions que l'on peut tirer de son existence.
Le kit fournit une méthode reproductible pour comparer plusieurs organisations.
Il ne constitue pas une étude scientifique démontrant la supériorité universelle des boucles uniques.
Le résultat intéressant n'est donc pas une promesse de performances automatiquement meilleures.
C'est l'obligation de confronter les choix d'architecture à des mesures concrètes.
Une entreprise peut découvrir que deux sous-agents gagnent à être fusionnés, tandis qu'un troisième reste indispensable pour ses vérifications indépendantes.
La bonne architecture peut ainsi combiner une boucle principale simplifiée et quelques spécialistes réellement nécessaires.
Pourquoi cette recommandation arrive maintenant
L'évolution des modèles explique une partie du changement de doctrine.
Anthropic estime que les modèles récents sont capables de conduire des tâches longues et de choisir leurs outils avec moins d'intermédiaires.
Des architectures conçues pour compenser les limites de générations précédentes peuvent donc devenir inutilement rigides.
L'entreprise cite notamment l'amélioration des capacités de planification, d'utilisation d'outils et de vérification.
Un modèle plus performant peut reprendre des fonctions auparavant confiées à des classificateurs ou à des planificateurs séparés.
Cette évolution ne signifie pas que les logiciels entourant les modèles deviennent inutiles.
Les permissions, la gestion des données, les limites d'exécution et les contrôles de sécurité restent indispensables.
Le changement concerne plutôt l'endroit où placer la logique de décision.
Faut-il définir chaque étape dans une infrastructure rigide, ou donner à un agent principal la possibilité d'adapter son plan ?
La réponse dépendra des capacités du modèle, de la nature des tâches et du niveau de prévisibilité nécessaire.
Le vrai conseil : mesurer avant de multiplier les agents
L'article publié le 22 octobre ne marque pas l'abandon par Anthropic des sous-agents.
L'entreprise continue d'en documenter l'utilisation dans Claude Platform et les considère pertinents pour de nombreux scénarios.
Elle invite surtout les développeurs à remettre en question les architectures où chaque fonction métier est automatiquement représentée par un agent distinct.
La démarche proposée est pragmatique : mesurer les performances actuelles, simplifier un composant à la fois et conserver uniquement les séparations qui apportent un bénéfice réel.
Pour les entreprises, l'enjeu dépasse quelques secondes de latence.
Une architecture plus simple peut être plus facile à faire évoluer, à maintenir et à contrôler.
Mais elle peut aussi perdre les avantages du parallélisme ou de l'isolation si la simplification est poussée trop loin.
La conclusion d'Anthropic est donc moins spectaculaire qu'une annonce de nouveau modèle, mais potentiellement importante pour les logiciels professionnels.
La multiplication des agents n'est pas une fin en soi. Leur nombre devrait dépendre de ce qu'ils permettent effectivement d'accomplir, et non de la complexité apparente du système.