Tool, Skill ou Subagent ? Structurer des agents Claude Code qui passent à l'échelle

Chaque agent qui survit au contact de vraies exigences finit par se dégrader de la même manière. Vous livrez quelque chose qui fonctionne, puis vous ajoutez capacité sur capacité jusqu’à ce que le system prompt fasse 400 lignes, qu’il y ait une douzaine de tools, une poignée de subagents, et que les performances se détériorent en silence. La solution n’est pas un modèle plus intelligent. C’est de savoir vers quelle primitive agentique se tourner, et quand.

Les ingénieurs d’Anthropic décrivent exactement ce mode de défaillance, et leur cadre de décision entre tools, skills et subagents est le plus clair que j’aie vu. Il correspond à ce que j’ai appris en faisant tourner les pipelines d’agents derrière Geonimo, alors le voici, dans l’ordre où vous devriez réellement piocher.

Commencez par des primitives proches de celles d’un humain

Quand vous construisez un agent, partez des mêmes primitives qu’une personne à son bureau : un système de fichiers, la capacité d’écrire et d’exécuter du code, la recherche web, une to-do list. C’est l’intuition derrière Claude Code : ce n’est pas un millier de tools sur mesure, c’est Claude à qui on donne accès à un ordinateur. Le bénéfice se cumule : à mesure que de meilleurs modèles sortent, ils utilisent ces mêmes primitives plus efficacement, sans réécriture.

L’exécution de code est l’élément qui sort du lot. Si votre agent doit raisonner sur un gros CSV, ne déversez pas tout dans le contexte : donnez-lui un tool bash et laissez-le écrire un petit script. Un exemple réel a fait passer l’usage de tokens de plus de 200 000 à une fraction de ce chiffre, avec un coût et une latence moindres, juste en laissant l’agent calculer au lieu de tout « lire » dans sa tête. Commencez par les primitives, retirez celles dont vous n’avez pas besoin, et seulement ensuite ajoutez des tools custom.

Utilisez les skills pour la divulgation progressive

L’erreur la plus courante est d’entasser chaque politique et chaque procédure dans le system prompt. Il enfle jusqu’à des centaines de lignes, se contredit et embrouille le modèle, ce qui est à l’origine de bon nombre de bugs « le modèle a halluciné » qui sont en réalité des bugs de contexte. Les skills règlent ça. Un skill, c’est de l’information empaquetée et composable que le modèle charge dans son contexte uniquement quand il se rend compte qu’il en a besoin. Déplacez vos guidelines de prévision, vos règles de marque, votre processus de test dans des skills, et le system prompt se réduit à la poignée de choses dont le modèle a besoin à chaque fois.

Dans une démonstration, cela a fait passer un system prompt de 400 lignes à une quinzaine, en relocalisant la logique métier dans des skills, et les scores d’eval ont grimpé en conséquence directe. C’est la même idée que les « directives » dans mon système d’outbound : encoder le jugement une fois, le charger à la demande.

Utilisez les subagents pour exactement deux tâches

Les subagents sont puissants et trop souvent sollicités. Il n’y a vraiment que deux cas où ils justifient leur complexité :

En dehors de ces cas, soyez sceptique. Le coût caché des subagents, c’est la communication : réussir le passage de relais entre un orchestrateur et ses subagents est difficile, et une rupture à cet endroit est une défaillance classique, pénible à déboguer. Les modèles de pointe peuvent désormais retenir plus de choses dans un seul contexte qu’auparavant, donc une grande partie de ce qui nécessitait un subagent peut tout simplement vivre dans l’agent principal.

Les tools custom ensuite, MCP en dernier

Ce n’est qu’après les primitives et les skills que vous devriez ajouter des tools custom, et seulement pour une capacité que les primitives ne peuvent vraiment pas couvrir. MCP vient en dernier. Il est tentant de foncer d’abord vers MCP, mais on finit généralement avec une prolifération de serveurs qui se recoupent et polluent le contexte. Réservez-le aux cas où plusieurs agents ou clients ont besoin du même ensemble de tools standardisés et gouvernés. De plus en plus, le choix le plus sobre est de laisser l’agent appeler des CLI et des API via l’exécution de code plutôt que de câbler un serveur MCP.

Mesurez : grimpez la pente des evals

Aucune de ces décisions n’est une supposition. La façon de les prendre, c’est d’établir une baseline de votre agent sur un jeu d’evals, de changer une seule chose (l’architecture, les skills, les tools) et de relancer, en gardant ce qui améliore. Suivez à la fois les métriques déterministes (tours, latence, tokens) et les métriques floues (ton, qualité de sortie, via un LLM juge). Dans l’exemple dont je m’inspire, cette boucle a fait passer un agent d’un 62 % en échec à environ 92 %, surtout en simplifiant : moins de tools, un prompt court, la logique dans les skills. La discipline est la même que celle que j’applique aux systèmes que je construis : simplifier, mesurer, recommencer.

C’est ainsi que je garde mes agents fiables en production. Voyez les habitudes de l’équipe d’Anthropic et le manuel de prompting, ou contactez-moi si vous voulez de l’aide pour construire de cette façon.