Outil, compétence ou sous-agent : le spectre de la délégation et sa gouvernance

De toutes les distinctions établies par le glossaire des agents, celle entre outils, compétences et sous-agents est la plus floue — le glossaire lui-même admet que la frontière varie selon les frameworks. Mais le spectre sous-jacent est stable et mérite d'être pris en compte dans l'ingénierie : un outil est une action, une compétence est une procédure packagée, un sous-agent est un délégué qui raisonne. Ce sont trois types de délégation différents et — ce que la plupart des architectures oublient — trois problèmes de gouvernance distincts. Autorisez un outil, versionnez une compétence, donnez une identité à un sous-agent : si vous vous trompez de niveau, vous gouvernerez un délégué capable de raisonnement comme un simple appel de fonction, ce qui est la recette idéale pour des surprises liées à l'étendue des dégâts.

Ingrid, ingénieure principale, examinait un agent avant sa mise en production lorsqu'elle est tombée sur une ligne de sa liste d'outils qui l'a arrêtée : un « outil » n'en était pas un. Neuf entrées étaient de véritables appels de fonction — interroger la base de données des commandes, publier un message Slack. La dixième, « resolve-customer-issue », était un second agent complet portant l'étiquette d'un outil : il avait son propre prompt, son propre budget d'appels de modèle, son propre accès aux outils, et il raisonnait sur une quinzaine d'étapes avant de renvoyer une chaîne de caractères. Il avait hérité des permissions du parent en bloc — le mode de défaillance qu'une configuration gouvernée évite en définissant explicitement le périmètre du délégué plutôt que de le laisser hériter des droits du parent — apparaissait dans les traces comme un appel unique et opaque, et avait été validé par la sécurité en tant qu'« outil » — ce qui revient à dire qu'il n'avait pas vraiment été examiné. Rien en lui n'était malveillant. Tout en lui était mal classé.

Le mauvais classement est le mode de défaillance que ce vocabulaire vise à prévenir. Le glossaire des agents de Hugging Face — dont les termes sont suivis dans cette série, et mis en correspondance avec l'infrastructure dans notre article de référence — sépare les trois clairement tout en admettant que les frameworks les confondent. Cet article aborde le spectre niveau par niveau : ce qu'est chacun d'eux, quand y recourir et la surface de gouvernance qu'ils exigent. Car la dixième entrée d'Ingrid n'était pas un problème de nommage. C'était un problème de délégation classé sous le mauvais régime de gouvernance.

1. Le spectre, défini

Unoutils est une action. Le modèle émet une requête structurée — appeler cette fonction avec ces arguments — et le système l'exécute : un appel API, une requête en base de données, une commande shell, une récupération web. Le résultat revient dans le contexte et la boucle se poursuit. L'outil ne raisonne pas ; il s'exécute. Tout ce que le modèle sait à son sujet est sa description, et l'appel lui-même est un événement discret et inspectable, avec des arguments en entrée et un résultat en sortie.

Uncompétence est un savoir packagé. Là où un outil consiste à « exécuter cette commande », une compétence regroupe ce qui est nécessaire pour atteindre un objectif — enquêter sur ce type de bug, produire ce genre de rapport — généralement sous forme d'instructions structurées et de procédures (le modèle SKILL.md) chargées dans le contexte de l'agent à la demande. Une compétence n'exécute rien par elle-même ; elle façonne la manière dont l'agent utilise les outils dont il dispose. C'est une structure d'appui, rendue portable et réutilisable entre les agents.

Unsous-agent est un délégué. L'agent appelant confie une sous-tâche à un autre agent — doté de son propre modèle, de sa propre structure, de sa propre fenêtre de contexte, et éventuellement de ses propres outils — qui réfléchit au travail de manière indépendante et renvoie un résultat. Le parent reçoit le résultat plutôt que de gérer chaque étape intermédiaire, tout comme un manager ne tape pas lui-même les touches à la place de son subordonné. Cette opacité est l'objectif, mais aussi le problème de gouvernance. La distinction avec un outil est exactement celle sur laquelle Ingrid a buté : un outil exécute ; un sous-agent décide, peut lui-même utiliser des outils et peut se tromper de manières imprévisibles, contrairement à une fonction.

2. Choisir un échelon : le plus bas qui fait l'affaire

Le spectre échange le contrôle contre la capacité à mesure que vous montez. Un outil est au maximum de sa lisibilité — son comportement est son implémentation, son invocation est un événement auditable — et au minimum de sa capacité : il gère exactement ce pour quoi il a été codé. Un sous-agent est au maximum de sa capacité — il peut absorber l'ambiguïté, s'adapter en cours de sous-tâche, se remettre d'imprévus — et au minimum de sa lisibilité : son comportement émerge d'un modèle raisonnant dans un contexte que vous ne voyez pas depuis le parent. Une compétence se situe entre les deux : elle augmente la compétence de l'agent sur une classe de tâches sans ajouter de nouveau mandataire délégué.

Cela donne une heuristique de sélection claire : choisissez l'échelon le plus bas qui fait l'affaire. Si la sous-tâche est déterministe et bien spécifiée — récupérer cet enregistrement, exécuter ces tests — c'est un outil ; l'envelopper dans un sous-agent ajoute du coût, de la latence et un mode de défaillance indéfini pour rien. Si la sous-tâche est une procédure qu'un expert du domaine pourrait rédiger — trier un bug de cette façon, structurer le rapport comme ceci — c'est une compétence : le raisonnement propre de l'agent parent, amélioré par un savoir-faire packagé, sans aucune délégation nécessaire. Réservez le sous-agent aux sous-tâches qui nécessitent un véritable jugement avec leur propre état de travail — analyser en profondeur ce corpus de logs, rechercher cette question — où le travail submergerait le contexte du parent ou nécessiterait un raisonnement que le parent ne devrait pas entremêler avec son fil conducteur principal. Le délégué mal classé d'Ingrid, jugé selon cette heuristique, était légitimement un sous-agent ; l'erreur n'était pas l'échelon, c'était le classement.

3. Outils : Gouverner l'appel

Parce qu'un outil est une action exécutée discrète, son unité de gouvernance est l'appel. Trois questions se rattachent à chaque invocation : cet appelant est-il authentifié, cet appelant est-il autorisé pour cet outil, et cet appel particulier est-il acceptable — le dernier point couvrant à la fois les arguments entrants (une instruction injectée dissimulée dans un paramètre) et le résultat sortant (un secret ou des données personnelles dans la réponse). C'est la surface par appel, et c'est exactement ce qu'une passerelle MCP est censée fournir : un registre pour que les agents n'atteignent que des outils autorisés, une authentification centrale pour que les agents n'aient pas à gérer des identifiants par outil, un contrôle d'accès basé sur les rôles (RBAC) par outil, et des garde-fous avant/après appel avec une piste d'audit par appel. La solution de TrueFoundry passerelle MCP implémente cet échelon de bout en bout, y compris des surfaces d'outils organisées selon le principe du moindre privilège par rôle via des serveurs MCP virtuels.

Une remarque sur la couche d'échafaudage s'impose ici, car il s'agit de l'une des défaillances d'outils les plus fréquentes en pratique : le modèle sélectionne les outils uniquement à partir de leurs descriptions, donc une description vague ou qui se chevauche produit une utilisation abusive qu'aucun contrôle par appel ne détectera — l'appel est autorisé, bien formé, mais erroné. Considérez les descriptions d'outils comme un échafaudage révisé et versionné, et considérez qu'un outil qui continue d'être mal utilisé a un bug de documentation avant de supposer que le modèle a un problème de raisonnement.

4. Compétences : Gouverner l'artefact

Une compétence n'exécute rien, donc la gouvernance par appel n'a rien à saisir ; son unité de gouvernance est l'artefact. Les questions qui comptent sont la provenance et le versionnage : qui a écrit cette procédure, qui l'a révisée, quelle version chaque agent exécute-t-il, et qu'est-ce qui a changé entre les versions — parce qu'une compétence est un comportement, et une modification non révisée d'une compétence largement utilisée est un changement de comportement silencieux pour chaque agent qui l'utilise. Le mode de défaillance des compétences non gouvernées est celui du copier-coller non gouverné : des procédures dérivées en variantes privées, des versions obsolètes exécutées indéfiniment, et aucun moyen de répondre à la question « quels agents sont affectés ? » lorsqu'une procédure s'avère erronée.

La solution est la même que celle adoptée pour le code : un registre. Le Registre de compétences de TrueFoundry traite les compétences comme des artefacts SKILL.md versionnés avec RBAC — publiés, révisés, avec des versions épinglées par les agents, et montés dans le contexte à la demande plutôt que collés dans chaque définition. Le montage à la demande est important à deux titres : c'est un gain en ingénierie de contexte (la procédure ne consomme de l'espace dans la fenêtre que lorsqu'elle est pertinente) et un gain en gouvernance (le registre sait exactement quels agents utilisent quelle compétence et quelle version, donc la question « quels agents sont affectés » a une réponse). Une compétence dans un registre est un savoir institutionnel ; une compétence dans un presse-papier est une rumeur.

5. Sous-agents : Gouverner le mandataire

Un sous-agent raisonne, donc ni l'appel ni l'artefact ne constituent la bonne unité de gouvernance — c'est le mandataire qui l'est. Quatre propriétés rendent un sous-agent gouvernable, et ces quatre propriétés manquaient à la dixième entrée d'Ingrid. Identité : le sous-agent agit en son nom propre, et non de manière anonyme au sein de son parent ; ses actions sont donc attribuables. Autorisations délimitées : il reçoit les outils nécessaires à sa sous-tâche, sans hériter des droits du parent ; un délégué chargé de l'analyse de logs n'a aucune raison de disposer des droits d'écriture du parent sur le système de commande. Ressources limitées : ses propres budgets d'étapes et de jetons, afin qu'un délégué qui s'égare ne puisse pas consommer silencieusement l'exécution du parent (la question de la prévention des boucles abordée dans notre article sur les agents multiples, un niveau plus bas). Sa propre trace : l'enregistrement du parent montre la délégation et le résultat ; celui du sous-agent montre les quinze étapes intermédiaires — une ligne opaque dans une trace est précisément le moyen par lequel un délégué mal assigné se dissimule.

C'est à ce niveau que le harness prend tout son sens, car ces propriétés sont des propriétés d'exécution. L' Agent Harness de TrueFoundry exécute les sous-agents comme des éléments de premier ordre de son mécanisme d'ingénierie de contexte : chaque délégué travaille dans une fenêtre de contexte isolée et renvoie des conclusions, et non des transcriptions, au parent — et chacun apparaît dans la trace étape par étape avec ses propres appels de modèle, appels d'outils et coûts. La délégation sans gouvernance par mandant transforme discrètement les autorisations d'un agent en un organigramme de copies non auditées ; avec une gouvernance, il s'agit simplement d'une bonne décomposition.

6. L'axe du contexte : le spectre comme instrument de gestion de fenêtre

Il existe un second axe traversant le spectre qui n'a rien à voir avec la sécurité et tout à voir avec la qualité : ce que chaque échelon coûte à la fenêtre de contexte du parent. Un outil préchargé coûte sa description à chaque étape où il est exposé (chaque description d'outil préchargé peut encombrer le contexte), en plus de ses résultats à mesure qu'ils arrivent — c'est pourquoi la gestion des résultats (troncature, déchargement) est le travail du harness, et pourquoi un agent doté de quatre-vingts outils largement préchargés peut payer un coût de contexte permanent pour chacun d'eux, qu'il les utilise ou non. C'est précisément pour cette raison que le chargement différé et à la demande des outils existe. Une compétence, montée à la demande, ne coûte rien tant qu'elle n'est pas pertinente, et sa procédure complète ne coûte que lorsqu'elle est utilisée. Un sous-agent est l'instrument de contexte le plus puissant de tous : il extrait l'intégralité de la sous-tâche hors de la fenêtre du parent — le délégué utilise son propre contexte frais pour l'investigation en quinze étapes et ne renvoie que trois phrases.

Lu sous cet angle, le spectre fait également office de boîte à outils d'ingénierie de contexte, ce qui est exactement la manière dont la suite d'ingénierie de contexte du harness le traite : des surfaces d'outils sélectionnées maintiennent le coût de description permanent à un niveau bas, les compétences chargent les procédures juste à temps, et les sous-agents isolent les sous-tâches gourmandes en contexte afin que la fenêtre du parent reste légère tout au long d'une exécution longue. La même décision de décomposition — quel échelon gère ce travail — est simultanément une décision de gouvernance et une décision de budget de fenêtre, et les architectures qui semblent naturelles sont celles où ces deux aspects ont été décidés intentionnellement.

7. Composer les échelons : un exemple concret

Les échelons se composent, et un agent réaliste utilise les trois. Prenons l'agent de service client d'Ingrid, correctement reclassé :

Un agent, trois échelons — chacun régi à son propre niveau (illustratif)

agent:
  name: customer-ops
  model: customer-ops-default
  mcp_servers:                       # TOOLS — per-call governance at MCP Gateway
    - orders-db: [lookup_order, update_status]   # curated, least-privilege
    - slack: [post_message]
  skills:                            # SKILLS — versioned artifacts from the registry
    - refund-policy@v7               # pinned; registry knows who runs what
    - escalation-runbook@v2
  subagents:                         # SUB-AGENTS — principals with their own scope
    - name: issue-investigator       # Ingrid's "tenth tool," filed correctly
      mcp_servers: [logs-readonly]   # scoped: NOT the parent's grants
      max_steps: 20                  # bounded; traced as itself

La composition se lit naturellement : les outils sont ce qu'il peut faire, les compétences sont ce qu'il sait faire, et le sous-agent est ce à quoi il délègue. Chaque ligne aboutit à un système de gouvernance différent qui sait déjà comment la traiter — la passerelle MCP autorise et audite les appels, le registre des compétences suit les versions, et l'infrastructure exécute le délégué avec sa propre identité, son budget et son suivi. L'architecture ne repose pas sur trois cas particuliers ; c'est un spectre où la gouvernance est pré-attachée à chaque échelon. C'est ce que signifie « encoder le spectre, pas les étiquettes » dans la pratique : peu importe comment un framework nomme ces éléments, classez chacun selon ce qu'il est — action, procédure ou mandataire — et les contrôles appropriés suivront.

8. Refactorisation le long du spectre

L'échelon qui convient aujourd'hui finit par dériver. Un outil qui accumule des options et des comportements conditionnels tend à devenir une procédure — demandez-vous si la logique ne devrait pas plutôt résider dans une compétence qui orchestre des outils plus simples. Une compétence qui ne cesse de dire « jugez si... » tend à devenir un délégué — les procédures ne devraient pas nécessiter de jugement ; c'est le signal qu'il faut promouvoir ce jugement dans un sous-agent doté de son propre périmètre. Et un sous-agent dont les exécutions s'avèrent quasi identiques à chaque fois tend à redescendre vers le bas — si le délégué n'exerce jamais réellement de jugement, rétrogradez la tâche en une compétence associée à des outils pour retrouver lisibilité et économie.

Deux pratiques rendent cette refactorisation sûre. Premièrement, le suivi vous indique quand l'effectuer : les enregistrements par étape montrent l'outil invoqué avec des arguments de plus en plus étranges, la compétence outrepassée par un raisonnement ad hoc, ou le sous-agent produisant les cinq mêmes étapes à chaque exécution. Deuxièmement, l'évaluation vous indique si cela a fonctionné : un changement d'échelon est un changement de comportement — un changement de politique, selon le vocabulaire du glossaire, que la boucle d'évaluation devrait contrôler comme n'importe quelle autre. La décomposition n'est pas une décision de conception ponctuelle ; c'est une propriété maintenue, et le spectre donne une direction à cette maintenance.

9. Foire aux questions

Les frameworks ne sont vraiment pas d'accord sur ces termes — la distinction est-elle toujours pertinente ? Les étiquettes varient, mais pas le spectre, et le glossaire est très clair à ce sujet. Ce qui compte sur le plan opérationnel, c'est de classer chaque capacité selon ce qu'elle est — une action exécutée, une procédure chargée, un mandataire de raisonnement — car ce classement détermine la gouvernance. L'incident d'Ingrid n'a pas été causé par la nomenclature d'un framework ; il a été causé par une gouvernance qui a suivi le nom au lieu de la nature.

Un sous-agent est-il simplement un outil du point de vue de l'appelant ? Techniquement, il est souvent invoqué via la même interface, ce qui facilite les erreurs de classement. La différence se situe de l'autre côté de l'appel : le comportement d'un outil est son implémentation ; le comportement d'un sous-agent est celui d'un modèle qui raisonne dans son propre contexte, avec ses propres outils, capable de se tromper de manières imprévisibles. Même convention d'appel, espèces différentes — et la gouvernance doit suivre l'espèce.

Quand une compétence est-elle préférable à de simples instructions plus longues ? Lorsque la procédure est réutilisable, partagée ou mérite d'être gouvernée. Les instructions intégrées conviennent pour le comportement ponctuel d'un agent. Dès qu'une procédure est utilisée par plusieurs agents, maintenue par quelqu'un d'autre que l'auteur de l'agent, ou suffisamment importante pour que vous souhaitiez savoir quelle version s'exécute et où — c'est une compétence, et elle doit figurer dans un registre avec des versions et un contrôle d'accès (RBAC) plutôt que dans un presse-papiers.

Un sous-agent doit-il hériter des permissions de son parent ? Par défaut, non. L'héritage est pratique et silencieusement maximaliste — le délégué obtient tout ce que possède le parent, que ce soit nécessaire ou non, ce qui inverse le principe du moindre privilège là où l'autonomie de raisonnement le rend crucial. Limitez le sous-agent aux outils de sa sous-tâche. Si cela semble laborieux, c'est que l'architecture vous indique que la limite de délégation mérite le même soin que toute autre limite de confiance, car c'en est une.

Monter dans le spectre ne signifie-t-il pas simplement plus de coûts et de latence ? En général, oui — un sous-agent consomme des appels de modèle qu'un outil n'utiliserait pas — et cela fait partie de l'heuristique du niveau le plus bas. Mais la comparaison ne se fait pas niveau par niveau dans le vide ; elle se fait par rapport à l'alternative où le parent effectue le travail dans sa propre fenêtre. Une sous-tâche gourmande en contexte effectuée par le parent peut dégrader l'ensemble de l'exécution (et son coût s'ajoute à la fenêtre croissante du parent) ; la même sous-tâche déléguée s'exécute dans un contexte frais et peu coûteux. Mesurez par tâche terminée, pas par appel.

La dixième entrée d'Ingrid n'avait pas besoin d'être bannie, elle avait besoin d'être classée. Une fois classée pour ce qu'elle était, elle a obtenu une identité, un périmètre, un budget et une trace, et est passée en production une semaine plus tard en tant que composant le plus examiné de l'agent plutôt que le moins. C'est toute la promesse du spectre : les capacités d'un agent ne sont pas une liste plate d'« outils », mais trois types de délégation, chacun avec une gouvernance qui connaît déjà son nom. Action, procédure, mandant. Classez en conséquence.

Références

• Hugging Face — glossaire des agents (Mai 2026) — les définitions d'outil/compétence/sous-agent sur lesquelles cet article s'appuie, paraphrasées avec crédit.
• Passerelle MCP TrueFoundry — gouvernance par appel pour le niveau outil : registre, authentification, RBAC, garde-fous, audit.
• Registre des compétences TrueFoundry — gouvernance par artefact pour le niveau compétence : versions, provenance, RBAC, montage à la demande.
• Harnais d'agent TrueFoundry — gouvernance par mandant pour le niveau sous-agent : isolation, budgets, traces.
• Le glossaire des agents, appliqué à la production — le pilier de cette série.

Ingrid est un personnage composite illustratif et ne représente aucune personne, organisation ou incident réel. Le vocabulaire utilisé suit le glossaire des agents de Hugging Face (mai 2026), qui souligne que les frontières entre outils, compétences et sous-agents varient selon les frameworks. Les extraits de configuration sont simplifiés pour faciliter la lecture et ne constituent pas des schémas de produits littéraux. Les fonctionnalités de TrueFoundry reflètent la documentation publique disponible au moment de la rédaction ; veuillez vous référer à la documentation actuelle pour vérification.

‍