Compétences d'agent : arrêtez d'écrire des SOP, commencez à construire des systèmes de frontières

Un post récent sur r/ClaudeAI soutient que l'instinct courant de corriger les échecs d'un agent en ajoutant plus de compétences, d'outils, de prompts ou de règles d'exception est contre-productif. L'auteur affirme que cette approche rend les agents plus fragiles avec le temps : le contexte devient plus lourd, la sélection d'outils se complique et les règles entrent en conflit les unes avec les autres.

Compétences comme SOP vs. Systèmes de limites

Le problème central, selon l'auteur, est que de nombreux développeurs conçoivent les compétences comme des procédures opérationnelles standardisées (SOP) :

Étape 1 : faites ceci
Étape 2 : faites cela
Si X se produit, faites Y
Si Y se produit, faites Z
Ne faites pas B sauf si A, à moins que C se produise

Ce style fonctionne pour les workflows déterministes mais échoue pour les tâches ouvertes d'un agent. L'auteur propose plutôt de passer à une approche de systèmes de limites, où une bonne compétence répond à ces questions :

• Quand cette compétence doit-elle être déclenchée ?
• Quand ne doit-elle absolument pas être utilisée ?
• Que signifie le succès en termes métier ?
• Quel est le plus petit ensemble d'outils nécessaire, sans ambiguïté ?
• Quels faits doivent être vérifiés via une API ou une source externe ?
• Où l'agent doit-il s'arrêter et demander une confirmation humaine ?

« Nous ne devrions pas apprendre au modèle à respirer. Nous devrions lui donner une carte claire, des outils propres et des signaux d'arrêt évidents. »

Outils : moins c'est plus

Le même principe s'applique aux définitions d'outils. Plus d'outils ne signifie pas automatiquement plus de capacité. Si les limites entre les outils sont floues, le modèle consomme du contexte et du budget de raisonnement rien que pour décider lequel appeler. La règle d'or de l'auteur :

Ensemble d'outils complet minimal, clarté maximale des limites.

Évaluations plutôt que correction procédurale

Une bonne compétence ne doit pas être jugée sur le fait que l'agent ait suivi les étapes exactes de l'auteur, mais sur le fait qu'il ait :

• Choisi le bon outil
• Passé les bons paramètres
• Vérifié les bons faits
• Arrêté quand il était censé s'arrêter

L'auteur conclut : une mauvaise compétence est une SOP qui ne cesse de s'allonger ; une bonne compétence est un système de limites testé. Il demande à la communauté comment les autres gèrent cela — si les compétences sont gardées petites et modulaires ou transformées en longs paquets d'instructions, et comment savoir si une compétence améliore réellement l'agent ou crée plus de dette de contexte.