Bloqué n'est pas un échec : les agents ont besoin de feedback sur les limites

La plupart des configurations d'agents traitent une action bloquée comme une défaillance d'outil.

Un agent appelle un outil. La requête enfreint une règle. Le système renvoie une erreur générique. L'appel de l'outil échoue.

Cela semble correct au premier abord. L'action non sécurisée a été stoppée. Mais cela ne résout que la moitié du problème.

Une erreur générique n'aide pas un agent à travailler dans ses limites. Elle transforme une décision de politique en bruit. L'agent pourrait essayer de deviner une correction. Il pourrait répéter la même erreur ou tenter une charge utile différente. Cela crée une boucle de tentatives inutiles.

Une action bloquée devrait être une décision structurée, et non un plantage inattendu.

Lorsqu'une requête est bloquée, le système externe ne doit pas changer. Cependant, la réponse doit indiquer à l'agent comment procéder en toute sécurité.

Au lieu d'une simple erreur, utilisez une réponse structurée.

Imaginez qu'un agent tente d'écrire dans un fichier qui a été modifié pendant sa phase de planification. Une erreur générique indique « échec ». Une réponse structurée indique :

  • État de la décision : conflit
  • État du résultat : aucun impact
  • Raison : état obsolète
  • Action suivante : relire l'état cible

Désormais, l'agent sait que l'objectif n'est pas impossible. Il doit simplement mettre à jour ses informations. Il cesse de deviner et prend la bonne étape suivante.

Cela fonctionne pour de nombreux scénarios :

  • Si un chemin est hors périmètre, suggérez un chemin autorisé.
  • Si un effet existe déjà, suggérez de réutiliser le résultat.
  • Si l'impact est trop élevé, suggérez d'attendre une révision humaine.

Cela ne rend pas la limite plus souple. L'action reste bloquée. Le système reste sûr. Vous transformez simplement une impasse en un chemin guidé.

Vous devez équilibrer cela avec la sécurité. Un feedback précis peut aider un agent malveillant à sonder vos limites.

Utilisez des codes de raison clairs pour les frictions opérationnelles comme les données obsolètes ou les entrées malformées. Si l'agent montre un comportement suspect ou ignore les indices, passez à des rejets génériques ou à des révisions humaines.

Séparez le feedback de l'agent des scores d'audit. L'agent doit savoir comment être conforme. Le système doit savoir si l'agent se comporte mal. Ne mélangez pas ces deux fonctions.

Les limites existent parce que les agents deviennent assez utiles pour agir sur des systèmes réels. Le travail réel comporte des règles et des limites.

Une limite qui ne renvoie qu'un échec est un mur. Une limite qui fournit des indications est un outil.

Bloqué devrait signifier :

  • L'impact demandé n'a pas eu lieu.
  • La raison est connue.
  • La prochaine action sûre est claire.

Source : https://dev.to/davidloibner/blocked-is-not-failed-agents-need-boundary-feedback-bbg

Communauté d'apprentissage optionnelle : https://t.me/GyaanSetuAi