Compétences : gérer le contexte et l’accès aux outils IA

Une étude de cas technique de NanthAI:Edge.

La plupart des agents IA changent d’échelle de la mauvaise manière : chaque nouvelle capacité ajoute du texte au prompt, des schémas d’outils et des occasions pour le modèle de mal choisir. Dans NanthAI:Edge, ce n’est pas qu’une théorie. Le catalogue actuel des compétences visibles représente environ 5,1 k tokens de métadonnées, contre environ 67 k tokens pour leurs consignes complètes. Le registre de base expose 4 outils, contre 115 dans le registre entièrement étendu. Cela ne prouve pas une meilleure réussite des tâches, mais elle prouve que la surface de contexte est radicalement plus petite.

Résumé

Les agents fondés sur de grands modèles de langage (LLM) utilisant des outils font face à une tension structurelle entre l’étendue des capacités et l’économie de contexte. Chaque consigne de travail et chaque schéma d’outil supplémentaire injecté dans le contexte du modèle consomme des tokens, augmente la latence et le coût, et peut rendre la sélection d’outils moins fiable. Cet article développe le modèle de conception d’accès progressif aux outils conditionné par les compétences, dans lequel un catalogue compact de compétences, stable pour le cache, assure à la fois le chargement des consignes à la demande et l’extension incrémentale du registre d’outils exécutables.

Une compétence est considérée comme un ensemble modulaire de consignes que le modèle peut découvrir, avec des métadonnées, des directives comportementales complètes et des exigences déclarées en matière de profils d’outils. Au lieu d’injecter toutes les compétences et tous les outils dans chaque requête, le système expose d’abord des métadonnées légères ; le modèle appelle load_skill lorsqu’une tâche correspond à une compétence ; les compétences chargées injectent ensuite les consignes détaillées et activent les profils d’outils pertinents.

L’article situe ce modèle par rapport aux travaux sur l’encombrement des prompts, le passage à l’échelle de l’appel de fonctions, la sélection d’outils par recherche, le cache des prompts, la divulgation progressive et l’architecture modulaire des agents. Il analyse ensuite NanthAI:Edge comme étude de cas concrète à partir de détails de mise en œuvre fournis par l’auteur du système. NanthAI:Edge organise les capacités en trois couches : niveau de compte, compétences et outils exécutables. L’article explique les bénéfices attendus, les principaux risques et les compromis de mise en œuvre de cette architecture.

Résumé du fonctionnement du registre d’outils, dont l’accès dépend des compétences

1. Introduction

Les systèmes agentiques modernes à base de LLM composent généralement trois types de contexte dans chaque requête : les consignes système, les schémas d’outils et l’état de la conversation. À mesure que les agents accumulent des capacités, chaque couche tend à grandir. Les nouvelles méthodes de travail ajoutent des consignes au prompt. Les nouvelles intégrations ajoutent des schémas d’outils. Les nouvelles préférences et mémoires de l’utilisateur ajoutent du contexte. Le système devient capable, mais de plus en plus lourd.

Cela crée deux problèmes liés :

1. L’encombrement du prompt apparaît lorsque le prompt système accumule des consignes comportementales, des politiques, des méthodes de travail, des exemples, des mémoires et des règles contextuelles en grande quantité.
2. L’encombrement du registre d’outils apparaît lorsque de nombreux outils exécutables sont exposés au modèle, qu’ils soient pertinents ou non pour la tâche en cours.

Les deux coûtent cher. Ils consomment des tokens d’entrée, augmentent la latence et le coût fournisseur, et compliquent le cache des prompts. Surtout, ils peuvent dégrader la qualité des décisions. Un modèle chargé de choisir parmi des dizaines ou des centaines d’outils doit comparer davantage de candidats, porter son attention sur plus de descriptions et résoudre plus de recoupements sémantiques.

Des travaux récents sur la sélection d’outils augmentée par recherche confortent cette préoccupation. L’étude RAG-MCP de Gan et Sun indique que récupérer les schémas d’outils pertinents, au lieu de tous les transmettre, a fait passer l’exactitude de sélection de 13,62 % à 43,13 % dans une configuration MCPBench WebSearch, tout en réduisant environ de moitié les tokens du prompt. Ces chiffres sont propres au test et ne doivent pas être généralisés aveuglément, mais ils illustrent le problème central : exposer tous les outils à plat est souvent une mauvaise architecture de l’information.

Cet article examine une autre approche structurée : l’accès progressif aux outils conditionné par les compétences.

Le principe est simple :

1. Exposer un catalogue compact des compétences disponibles.
2. Laisser le modèle charger une compétence pertinente via load_skill.
3. Injecter les consignes complètes d’une compétence uniquement après son activation.
4. Étendre le registre d’outils actifs uniquement par les profils requis par les compétences chargées.

Cette conception adapte la divulgation progressive issue de l’UX et le masquage d’information de l’architecture logicielle à l’économie des fenêtres de contexte des LLM. Les détails ne sont pas cachés à l’utilisateur humain ; ils sont cachés au modèle jusqu’à ce que la tâche justifie de les exposer.

Nous analysons ce modèle à travers NanthAI:Edge, un runtime d’agent commercial dont l’architecture met en œuvre des capacités de compte en couches, la découverte et le chargement de compétences, ainsi que l’extension des outils par profils. Les détails propres à NanthAI dans cet article sont des détails de mise en œuvre de l’étude de cas fournis par l’auteur du système.

L’article apporte :

1. Un cadre conceptuel où les compétences ouvrent progressivement l’accès aux consignes et aux outils.
2. Une analyse de l’architecture à trois couches de NanthAI:Edge.
3. Une discussion de la stabilité du cache, de l’intention de routage et de l’extension du registre par profils.
4. Un catalogue de risques centré sur la mauvaise sélection et l’absence de chargement des compétences.

2. Contexte : encombrement du prompt, schémas d’outils et utilisation agentique des outils

2.1 Appel de fonctions et exposition des outils

Les API d’appel de fonctions exigent que les outils soient décrits au modèle par des noms, des descriptions en langage naturel et des schémas de paramètres structurés. Le modèle décide s’il doit appeler un outil, lequel et avec quels arguments. Des tests comme le Berkeley Function Calling Leaderboard évaluent cette capacité dans des contextes à un ou plusieurs tours, parallèles et sensibles à la pertinence.

L’utilisation d’outils n’est pas une capacité unique. Elle se décompose en plusieurs éléments :

• Sélection de l’outil : choisir la bonne fonction.
• Construction des arguments : produire des paramètres valides et sémantiquement corrects.
• Ordonnancement des appels : appeler les outils dans le bon ordre.
• Interprétation des résultats : utiliser correctement les sorties des outils.
• Accomplissement de la tâche : satisfaire l’intention réelle de l’utilisateur.

Un système peut sélectionner le bon outil et échouer sur les arguments. Il peut appeler un outil plausible mais échouer à accomplir la tâche. Il peut réussir une fois puis se dégrader sur des trajectoires à plusieurs tours. C’est pourquoi la seule notation de la réponse finale ne suffit pas à évaluer les systèmes agentiques.

2.2 Encombrement du prompt

L’encombrement du prompt est souvent présenté comme une question de coût, mais le problème profond est celui de l’attention. De longs prompts peuvent inclure des informations pertinentes, des informations inutiles, des consignes périmées, des politiques dupliquées et de nombreuses définitions d’outils. Des fenêtres de contexte plus grandes permettent d’y faire tenir ces informations, mais les faire tenir n’est pas les utiliser de façon fiable.

Les recherches sur les longs contextes, comme « Lost in the Middle », montrent que la fiabilité avec laquelle les modèles utilisent une information peut dépendre de sa position dans le contexte. D’autres études sur les longs contextes et les appels d’outils suggèrent que la longueur du contexte, le nombre d’outils et l’accumulation des tours peuvent interagir de manière fragile. Les seuils exacts varient selon le modèle et la tâche ; cet article évite donc des affirmations comme « les modèles échouent après N outils ». L’affirmation défendable est plus restreinte : les consignes superflues et les schémas non pertinents augmentent la surface de décision exposée au modèle et peuvent dégrader les conditions de routage.

2.3 Encombrement du registre d’outils

L’encombrement du registre d’outils est la version propre aux outils de l’encombrement du prompt. Un grand registre à plat oblige tous les outils disponibles à se disputer l’attention pour chaque tâche. Le problème est particulièrement marqué lorsque les outils se recoupent sémantiquement : plusieurs outils de recherche, de documents, de calendrier, d’espace de travail ou plusieurs variantes propres à une intégration.

Les travaux sur la sélection d’outils par recherche visent directement ce problème. RAG-MCP récupère les schémas pertinents avant de construire le prompt plutôt que d’exposer tous les outils. Tool Attention et les approches de chargement dynamique de schémas défendent aussi la réduction de l’ensemble de candidats actifs. Ces approches ne prouvent pas que le filtrage par compétences fonctionne, mais elles soutiennent l’idée plus générale que le modèle ne devrait pas toujours voir toutes les capacités exécutables.

2.4 Qualité des descriptions d’outils

Réduire l’exposition des outils ne suffit pas. Les outils et les compétences qui restent visibles doivent être décrits clairement. ToolACE rapporte des gains grâce à des données d’appel de fonctions vérifiées et de qualité, montrant que les schémas et leurs descriptions influent sur l’exactitude d’utilisation des outils. Les études de documentation d’API suggèrent aussi que des paramètres mal documentés et des interfaces complexes augmentent les erreurs.

Cela crée la tension centrale de conception :

• Des consignes et des schémas détaillés améliorent l’exécution.
• Exposer partout toutes ces consignes et tous ces schémas détaillés crée de l’encombrement.

L’accès progressif conditionné par les compétences répond à cette tension en séparant les métadonnées de découverte des détails d’exécution.

2.5 Cache des prompts

Le cache des prompts peut réduire la latence et le coût lorsque des préfixes stables sont réutilisés. Mais il favorise une structure de prompt stable. Si les listes d’outils ou les consignes système sont réécrites de façon imprévisible, la réutilisation du cache peut se dégrader.

Cela crée une seconde tension de conception :

• Le chargement dynamique réduit le contexte non pertinent.
• L’insertion dynamique peut rompre la stabilité du cache.

Une architecture viable d’accès par compétences doit donc gérer où et comment apparaissent les consignes chargées. L’approche de NanthAI:Edge, décrite plus loin, conserve un prompt de base et un catalogue stables, puis ajoute des blocs normalisés de compétences chargées à des positions prévisibles.

3. Les compétences comme ensembles modulaires de consignes

Une compétence est un ensemble de capacités nommé, que le modèle peut découvrir. Ce n’est ni un simple outil ni un simple fragment de prompt. Elle se situe entre l’intention de l’utilisateur et les fonctions exécutables.

Une compétence comprend généralement :

• un slug
• un nom
• un résumé
• un runtimeMode
• des consignes de travail complètes
• les identifiants des outils requis
• les profils d’outils requis
• les intégrations requises
• les capacités de compte requises
• les contraintes de politique
• des métadonnées de version

Un outil est une opération exécutable. Une compétence est une capacité à l’échelle d’une méthode de travail qui peut utiliser zéro, un ou plusieurs outils.

Par exemple, un outil de génération de documents peut créer un fichier .docx. Une compétence de « rédaction d’article de recherche » peut définir des règles de traitement des sources, de citation, de structure, des exigences de synthèse et des attentes de génération de documents, et activer les outils de documents, de recherche et d’analyse.

L’accès progressif par compétences repose sur trois couches de divulgation :

Cette structure fait des compétences des primitives de gestion du contexte. Elles sont à la fois :

• des unités de capacité ;
• des unités de portée des consignes ;
• des unités d’extension du registre d’outils ;
• des unités de gouvernance et d’observabilité.

4. Étude de cas NanthAI:Edge

Cette section résume les détails de mise en œuvre de l’étude de cas fournis par l’auteur du système. Elle doit être lue comme une documentation d’architecture, pas comme une preuve vérifiée de façon indépendante.

4.1 Modèle de capacités à trois couches

NanthAI:Edge organise les capacités en trois couches :

1. Capacités et niveau du compte
2. Compétences
3. Outils exécutables

La couche de compte détermine les accès autorisés à l’utilisateur. Les utilisateurs gratuits disposent d’un chat simple sans registre d’outils appelables par le modèle. Les utilisateurs Pro qui utilisent des modèles compatibles avec les outils disposent d’un petit registre de base.

La couche des compétences contient des ensembles modulaires de consignes avec des métadonnées et des règles d’activation.

La couche des outils exécutables contient les schémas et implémentations des outils réels, mais les familles d’outils lourdes ne sont pas exposées par défaut. Elles sont déverrouillées par les profils déclarés dans les compétences.

4.2 Registre de base

Le registre de base contient des outils généralistes légers tels que :

• load_skill
• list_skills
• search_chats
• fetch_image

L’outil essentiel est load_skill. Il fait du routage une action explicite du modèle. Le modèle n’a pas besoin de toutes les consignes d’emblée ; il a besoin d’assez de métadonnées pour décider quand des consignes plus détaillées sont nécessaires.

4.3 Métadonnées des compétences

Les compétences NanthAI incluent des métadonnées structurées :

• slug
• name
• summary
• runtimeMode
• requiredToolIds
• requiredToolProfiles
• requiredIntegrationIds
• requiredCapabilities

Ces métadonnées servent à la fois à la découverte par le modèle et à l’application des politiques du runtime. Une compétence nécessitant Slack, par exemple, peut être masquée si l’utilisateur n’a pas connecté Slack. Une compétence nécessitant une capacité Pro peut être omise pour les utilisateurs gratuits.

4.4 Catalogue des compétences disponibles

Les compétences reconnues comme disponibles sont inscrites dans un bloc XML <available_skills> du prompt système. Ce catalogue contient des métadonnées compactes, pas les consignes complètes.

Exemple simplifié :

<available_skills>
<skill slug="analytics_report">
<name>Rapport d’analyse</name>
<summary>À utiliser lorsque l’utilisateur a besoin d’analyse de données, de graphiques ou d’un résultat analytique structuré.</summary>
</skill>
<skill slug="document_drafting">
<name>Rédaction de documents</name>
<summary>À utiliser lorsque l’utilisateur a besoin d’un document structuré, d’une proposition, d’une note ou d’un fichier généré.</summary>
</skill>
</available_skills>

Le catalogue est une interface de routage. Il indique au modèle quelles capacités existent sans l’obliger à traiter chaque méthode de travail intégralement.

4.5 États des compétences

NanthAI résout les compétences sur quatre portées :

• les réglages du compte ;
• le profil Persona ;
• le chat ;
• les remplacements au niveau du tour.

Chaque compétence peut recevoir l’un de ces trois états :

• always : consignes complètes injectées à chaque tour ;
• available : présente dans le catalogue et chargeable à la demande ;
• never : entièrement exclue.

Cela permet une politique fine. Les règles universelles peuvent être toujours actives. Les méthodes spécialisées peuvent être disponibles. Les capacités interdites ou sans pertinence peuvent être masquées.

4.6 load_skill

Lorsque le modèle détermine qu’une tâche correspond à une compétence, il appelle load_skill avec son slug. Le runtime renvoie les consignes complètes et les métadonnées de routage.

Plutôt que de s’appuyer sur l’historique brut des résultats d’outils, NanthAI normalise les consignes chargées dans un message système dédié aux compétences chargées. L’état des consignes actives devient explicite et l’historique bruité des appels d’outils ne s’accumule pas.

4.7 Profils d’outils progressifs

Les compétences déclarent requiredToolProfiles. Charger une compétence peut activer un ou plusieurs profils d’outils. Les profils fournis par l’auteur comprennent :

• docs
• analytics
• workspace
• persistentRuntime
• subagents
• google
• microsoft
• notion
• appleCalendar
• cloze CRM
• slack
• scheduledJobs
• skillsManagement
• personas

Exemples :

• docs déverrouille les outils de génération et de modification de documents et de fichiers.
• analytics déverrouille Python et les outils de données.
• workspace déverrouille les outils de fichiers et d’exécution de l’espace de travail.
• les profils d’intégration déverrouillent les outils propres aux applications uniquement lorsqu’elles sont connectées.
• subagents déverrouille la création de sous-agents uniquement lorsqu’elle est autorisée.

Le registre s’étend donc selon les compétences activées, et non selon l’ensemble des capacités de la plateforme.

4.8 Garde du runtime

NanthAI inclut une garde du runtime qui indique au modèle de ne pas inventer d’outils indisponibles : aucun accès au système de fichiers local, aucun shell, aucune automatisation de navigateur, aucun serveur MCP non configuré et aucune requête réseau brute en dehors des outils NanthAI explicites.

Cette garde au niveau du prompt ne constitue pas à elle seule une frontière de sécurité. La véritable frontière doit être appliquée par les autorisations du runtime et les listes d’outils autorisés. Mais la garde renforce la compréhension du modèle quant aux capacités actives.

5. Analyse de l’architecture

5.1 Modèle de coût en tokens

Dans une conception monolithique, le coût du prompt par tour est approximativement :

base_prompt + all_skill_instructions + all_tool_schemas + conversation_state

Avec un accès progressif par compétences, il est approximativement :

base_prompt + skill_catalog_metadata + loaded_skill_instructions + active_profile_tool_schemas + conversation_state

La différence essentielle est ce qui croît avec les capacités totales de la plateforme. Dans la conception monolithique, les coûts lourds de consignes et de schémas augmentent avec toutes les capacités disponibles. Dans la conception progressive, ils augmentent avec les capacités activées. Le catalogue grandit toujours, mais seulement sous forme de métadonnées compactes.

C’est le cœur économique de l’architecture.

5.2 Le catalogue comme interface de routage stable pour le cache

Le bloc available_skills est conçu pour rester stable entre les tours, sauf si les capacités de l’utilisateur, le profil Persona, les réglages du chat ou les remplacements du tour changent. Cette stabilité compte, car le cache des prompts dépend de préfixes réutilisables. Un catalogue compact et stable peut rester favorable au cache, tandis que les consignes complètes des compétences sont différées.

5.3 Bloc des compétences chargées

Normaliser les consignes des compétences chargées dans un message système dédié présente deux avantages :

1. Cela garde d’abord l’état des consignes clair. Le modèle voit les directives chargées comme un contexte système actif plutôt que comme un résultat d’outil historique.
2. Cela aide ensuite à préserver la structure du cache du prompt. Si les compétences chargées sont ajoutées après le prompt de base et le catalogue stables, les nouvelles activations étendent le contexte sans réécrire le préfixe stable.

C’est l’une des idées architecturales les plus importantes de la conception de NanthAI : l’extension dynamique des capacités et le cache des prompts ne sont pas naturellement compatibles ; la structure des messages doit donc les concilier explicitement.

5.4 Extension du registre par profils

Les profils d’outils créent une indirection entre compétences et outils. C’est préférable à ce que chaque compétence possède directement une longue liste de schémas d’outils individuels.

Cette indirection présente plusieurs avantages :

• plusieurs compétences peuvent partager un profil ;
• les profils peuvent être testés comme des ensembles de capacités ;
• la disponibilité des intégrations peut être vérifiée une fois par profil ;
• les outils apparentés peuvent être exposés ensemble ;
• les politiques peuvent s’appliquer au niveau du profil ;
• le registre actif reste explicable.

Par exemple, de nombreuses compétences peuvent nécessiter la génération de documents. Plutôt que de dupliquer les listes d’outils documentaires entre compétences, elles peuvent activer le profil docs.

5.5 Intention de routage

Dans un registre à plat, l’intention est implicite. Si le modèle appelle un outil, les ingénieurs doivent déduire pourquoi. Dans un système conditionné par les compétences, l’intention de routage devient explicite :

tâche utilisateur → compétence chargée → profil activé → outil sélectionné

Cela améliore l’observabilité. Les échecs peuvent être décomposés par couche :

• La bonne compétence était-elle visible ?
• A-t-elle été chargée ?
• A-t-elle activé le bon profil ?
• Le bon outil a-t-il été sélectionné ?
• Les arguments étaient-ils corrects ?
• La réponse finale satisfaisait-elle la tâche ?

C’est un avantage d’évaluation considérable par rapport à un prompt monolithique.

6. Objection centrale : le routage par métadonnées peut échouer

L’objection la plus forte à l’accès progressif par compétences est que masquer les consignes complètes peut nuire au routage.

Un modèle peut être incapable de distinguer des compétences similaires à partir des seules métadonnées. Si les résumés du catalogue sont trop courts, vagues ou redondants, le modèle peut :

• charger la mauvaise compétence ;
• ne charger aucune compétence ;
• charger trop de compétences ;
• activer le mauvais profil d’outils ;
• produire une réponse plausible mais insuffisamment précise.

Ce n’est pas un cas limite mineur. C’est le compromis central. L’accès progressif échange un problème, l’encombrement global, contre un autre, le rappel et la précision du routage.

L’architecture est la plus solide lorsque :

• le catalogue de compétences reste de taille modérée ;
• les résumés permettent de distinguer les compétences ;
• les compétences se recoupent peu ;
• une demande de précision est possible en cas de doute ;
• les décisions de routage sont journalisées et évaluées ;
• la recherche sémantique peut aider à trouver les correspondances dans le catalogue.

Elle est la plus fragile lorsque :

• il existe des milliers de compétences similaires ;
• les résumés sont génériques ;
• les tâches nécessitent des distinctions subtiles ;
• on décourage le modèle de poser des questions de clarification ;
• une compétence manquée produit silencieusement une réponse médiocre mais plausible.

Une mise en œuvre robuste devrait donc combiner le jugement du modèle avec des vérifications déterministes, la recherche, la gestion des versions et l’évaluation.

7. Risques et modes de défaillance

R1 : mauvaise sélection de compétence

Le modèle charge une compétence proche, mais inadaptée. Cela peut injecter de mauvaises consignes et activer des outils non pertinents.

Mesures d’atténuation : résumés distinctifs, exemples, notes « quand ne pas utiliser », tests de routage hors ligne, seuils de confiance.

R2 : absence de chargement d’une compétence

Le modèle poursuit sans charger de compétence. C’est dangereux, car le résultat peut sembler acceptable tout en enfreignant les exigences de la méthode de travail.

Mesures d’atténuation : consignes de chargement plus fortes, détecteurs de compétences manquées, classificateurs a posteriori, demandes de clarification.

R3 : consignes périmées

Les consignes chargées peuvent persister après la mise à jour d’une compétence.

Mesures d’atténuation : identifiants de version, invalidation du cache, règles de rechargement, tests de compatibilité.

R4 : couplage caché

Compétences et profils peuvent diverger. Une compétence peut supposer la présence d’outils qui ne sont pas réellement disponibles dans son profil.

Mesures d’atténuation : requiredToolProfiles, requiredToolIds, tests de profils, vérification statique des dépendances.

R5 : latence supplémentaire

load_skill ajoute un tour d’appel d’outil avant le début du travail.

Mesures d’atténuation : garder les méthodes fréquentes en état always, préchargement spéculatif ou registre de base hybride.

R6 : invalidation du cache

Du contenu dynamique inséré trop tôt peut empêcher la réutilisation du cache.

Mesures d’atténuation : discipline du préfixe stable, bloc de compétences chargées uniquement enrichi par ajout, tests du cache.

R7 : injection de prompt

Les compétences créées par l’utilisateur peuvent contenir des consignes dangereuses.

Mesures d’atténuation : revue des compétences, vérification statique des politiques, isolation en bac à sable, portées d’autorisation, application par le runtime.

R8 : dépendance excessive au jugement du modèle

Le modèle peut mal router en situation ambiguë.

Mesures d’atténuation : routage assisté par recherche, contrôles de politique déterministes, clarification auprès de l’utilisateur, télémétrie.

8. Discussion

L’accès progressif par compétences redéfinit l’enregistrement des outils comme une architecture de capacités. Au lieu d’une liste d’outils à plat, le runtime d’agent devient stratifié :

politique du compte → catalogue de compétences → chargement de compétence → activation de profil → exécution d’outil

Cela a plusieurs conséquences :

1. Les compétences deviennent l’unité principale de gouvernance. Les accès par niveau, l’état des intégrations, les profils d’outils et les modes du runtime peuvent tous être exprimés par leurs métadonnées.
2. Le routage devient inspectable. Les événements load_skill peuvent être journalisés, mesurés et évalués.
3. Les places de marché deviennent plus faciles à gérer. Les compétences créées par les utilisateurs peuvent déclarer leurs exigences et être admises avec une portée de capacités délimitée.
4. Les conceptions hybrides sont probablement les meilleures. Les petits outils universels devraient rester dans le registre de base. Les outils spécialisés, risqués, coûteux ou rarement utilisés devraient être conditionnés. Les compétences always devraient être rares. available devrait être le défaut pour les méthodes spécialisées. never devrait supprimer les capacités interdites.
5. La qualité du catalogue de compétences devient un élément du produit. Ses résumés ne sont pas des étiquettes internes ; ce sont des interfaces de routage destinées au modèle. Ils exigent la même rigueur qu’une documentation d’API.

C’est la direction que nous prenons dans NanthAI:Edge : les capacités doivent pouvoir être découvertes sans être injectées en permanence, et les outils puissants ne doivent apparaître que lorsque la méthode de travail active les justifie.

9. Mesures statiques de l’architecture

Si une validation comportementale complète nécessite une suite de tests de référence, certaines affirmations peuvent être évaluées directement à partir de l’implémentation actuelle de NanthAI:Edge. Le code permet notamment de mesurer la surface de contexte exposée par le catalogue de compétences et le registre progressif d’outils.

Ces mesures quantifient la part de l’argument qui concerne l’économie de contexte : quelle quantité de prompt et de schémas d’outils est évitée en exposant des métadonnées compactes et un petit registre de base plutôt qu’en injectant d’emblée toutes les consignes et tous les schémas.

9.1 Compression du catalogue de compétences

Le catalogue système actuel de NanthAI:Edge contient 55 compétences visibles et 11 compétences masquées ou non visibles. Les compétences visibles sont inscrites dans le catalogue available_skills destiné au modèle sous forme de métadonnées légères : nom, résumé et indications sur les exigences. Leurs consignes complètes sont retenues jusqu’au chargement explicite de la compétence.

Mesures sur le catalogue visible actuel :

Cela signifie que la surface de découverte par défaut représente environ un treizième de la taille de toutes les consignes des compétences visibles. Le modèle peut toujours voir que les capacités existent, sans payer le coût complet des consignes à moins qu’une tâche n’en ait réellement besoin.

Cela soutient la première affirmation d’économie de contexte de l’architecture : la découverte des compétences peut rester large tandis que l’activation des consignes reste sélective.

9.2 Compression du registre d’outils

L’effet sur le registre d’outils est encore plus marqué. Dans le registre progressif actuel, l’ensemble de base n’expose que quatre outils généralistes :

• load_skill
• list_skills
• search_chats
• fetch_image

Lorsque tous les profils d’outils sont étendus, le registre contient 115 outils. La différence de tokens de schéma est considérable :

Cela soutient la seconde affirmation d’économie de contexte : l’espace d’actions exécutables par défaut du modèle est bien plus petit que l’ensemble des capacités de la plateforme.

Dans une conception monolithique, le modèle verrait le registre complet à chaque tour compatible avec les outils. Avec l’extension progressive, il ne voit que les outils de base jusqu’à ce qu’une compétence chargée active un ou plusieurs profils.

9.3 Exemples de coûts des profils actifs

Différentes méthodes activent différents profils d’outils. Les économies dépendent donc de la tâche. Une analyse ciblée expose bien moins d’outils qu’une génération de documents, et les deux en exposent bien moins qu’un registre entièrement étendu.

Ces exemples illustrent l’importance de l’indirection par profils. Une analyse de données n’a pas besoin d’outils de calendrier, de Slack, d’édition de documents, de tâches planifiées ou de gestion des profils Persona. Une tâche Slack n’a pas besoin d’exécution Python ou de génération de documents. Une tâche documentaire peut nécessiter le profil docs, relativement lourd, mais évite toujours la plupart des outils d’intégration et de runtime, sauf besoin explicite.

Le système déplace donc le coût des schémas d’outils de « tout ce qui est disponible pour l’utilisateur » vers « tout ce que justifie la méthode de travail actuellement activée ».

9.4 Interprétation

Ces mesures valident le postulat de réduction du contexte de l’architecture, pas l’intégralité de sa promesse comportementale.

Elles montrent que la conception progressive de NanthAI:Edge réduit sensiblement :

• l’exposition par défaut des consignes de compétences ;
• l’exposition par défaut des schémas d’outils ;
• la taille de l’espace d’actions présenté au modèle ;
• le contenu du prompt qui doit rester stable pour le cache ;
• les outils candidats non pertinents avant l’activation propre à la tâche.

Cependant, ces mesures ne prouvent pas que le modèle route mieux, choisit les outils plus précisément ou accomplit mieux les tâches. Ces affirmations nécessitent une évaluation comportementale.

Les mesures statiques répondent à une question :

L’accès progressif par compétences réduit-il réellement l’exposition du contexte et des schémas dans cette implémentation ?

La réponse est oui. Dans l’implémentation actuelle, la réduction est importante : environ 92,5 % pour les consignes de compétences et 97,7 % pour le registre d’outils de base par rapport à une exposition complète.

10. Conclusion

Les systèmes d’IA agentiques font face à un problème croissant d’architecture de l’information. À mesure que s’accumulent les outils, les intégrations, les méthodes de travail et les politiques, les conceptions monolithiques du prompt et du registre d’outils deviennent plus coûteuses et plus difficiles à évaluer. Les grandes fenêtres de contexte apportent de la capacité, mais ne résolvent ni la pertinence, ni le routage, ni la stabilité du cache, ni la gouvernance.

L’accès progressif aux outils conditionné par les compétences offre une autre approche fondée sur des principes clairs. Un catalogue compact permet de découvrir les compétences. load_skill fournit une activation explicite. Les consignes chargées guident la tâche. Les profils d’outils délimitent l’extension du registre. Les autorisations et gardes du runtime préservent les frontières des capacités.

L’étude de cas NanthAI:Edge montre comment mettre en œuvre ce modèle avec des niveaux de compte, des états de compétences en couches, des catalogues de compétences disponibles, des messages normalisés de compétences chargées, des registres conditionnés par profils et des gardes du runtime. L’architecture est prometteuse parce qu’elle aligne le coût du contexte sur les capacités activées plutôt que sur toutes celles de la plateforme.

La question centrale encore ouverte est empirique : le coût de routage introduit par une sélection des compétences d’abord fondée sur les métadonnées l’emporte-t-il sur les gains de réduction de l’encombrement du prompt et du registre ? La réponse dépendra de la taille du catalogue, du recoupement des compétences, de la famille de modèles, de la distribution des tâches et de la qualité de mise en œuvre.

Les plateformes d’agents devraient exposer les capacités progressivement, rendre le routage observable et n’activer les outils que lorsque la tâche les justifie.

Références

• Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv. https://arxiv.org/abs/2505.03275

• Liu et al. (2025). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172

• Gim, I., Chen, G., Lee, S.-s., Sarda, N., Khandelwal, A., & Zhong, L. (2024). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. Proceedings of MLSys 2024. https://proceedings.mlsys.org/paper_files/paper/2024/file/a66caa1703fe34705a4368c3014c1966-Paper-Conference.pdf

• Liu, W., et al. (2024). ToolACE: Winning the Points of LLM Function Calling. arXiv. https://arxiv.org/html/2409.00920v2

• Yang, S., et al. (2023). Improving Planning with LLMs: A Modular Approach. arXiv. https://arxiv.org/html/2310.00194v4

• Wang, et al. (2025). Evaluating Position Bias in Large Language Model Recommendations. arXiv. https://arxiv.org/html/2508.02020v1

• Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html

• Nielsen, J. (2006). Progressive Disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/

• Fowler, M. Function calling using LLMs. https://martinfowler.com/articles/function-call-LLM.html

• AWS. AI agents in enterprises: Best practices with Amazon Bedrock AgentCore. https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/

• Description de l’architecture NanthAI:Edge. Éléments d’étude de cas fournis par l’auteur ; non vérifiés indépendamment.

Également publié sur LinkedIn.