L'agent chargé de l'exécution n'a qu'à « faire le travail »

La séparation des pouvoirs (ici : répartir l'exécution, l'audit et l'approbation finale entre des agents distincts) a été présentée dans un article précédent et le suivant.

À partir de cette fois-ci, nous allons examiner chacun des trois rôles séparément. Nous commençons par l'« agent chargé de l'exécution ».

Qu'est-ce que l'agent chargé de l'exécution ?

L'agent chargé de l'exécution est celui qui effectue concrètement les tâches.

Écrire du code, rédiger une ébauche, lancer une commande, mettre en forme des données. Il prend en charge « le travail lui-même ».

Son rôle se résume à ceci : recevoir une instruction et produire un résultat.

Dans la structure que nous construisons ici, l'agent chargé de l'exécution prend la forme d'un subagent (ici : un agent IA qui reçoit une tâche et l'accomplit). Chaque rôle est attribué à un agent distinct, et chacun se concentre sur « son propre travail ». L'agent d'exécution est l'un d'eux — il est spécialisé dans l'accomplissement des tâches qui lui sont confiées.

Ce que fait l'agent d'exécution

L'agent d'exécution prend en charge la réalisation concrète des tâches.

Voici des exemples de travaux que nous lui confions.

• Rédiger l'ébauche d'un article
• Traiter des données spécifiées et les exporter dans un fichier
• Enregistrer des informations dans une base de données
• Opérer un système en suivant une procédure définie à l'avance

Dans chaque cas, « ce qu'il faut faire » est conçu à l'avance, et l'agent agit dans ce cadre.

Ce qui est important, c'est que l'agent d'exécution « agit dans les limites des instructions ». « Jusqu'où aller » et « selon quels critères » sont définis en amont par la conception ou par d'autres agents. L'agent d'exécution mène la tâche à terme dans ce périmètre.

Il y a une raison à cette structure. Si l'on confie aussi la « décision » à l'agent d'exécution, le travail et la prise de décision se retrouvent au même endroit. Quand on relit les traces plus tard, il devient difficile de voir « sur quelle base telle action a été effectuée ». C'est là que se situait le problème.

Séparer le travail de la décision rend les enregistrements plus faciles à suivre. « Ce qui a été fait » et « pourquoi cela a été autorisé » restent sur des couches distinctes. C'est ce qui fait la différence dans l'exploitation réelle.

Ce que ne fait pas l'agent d'exécution

C'est là le cœur de cette structure.

L'agent d'exécution ne décide pas lui-même que son travail est « correct ».

Il ne vérifie pas par lui-même si l'ébauche qu'il a rédigée est juste. Il ne juge pas par lui-même si le résultat d'une commande est sans problème. Il ne s'auto-approuve pas en disant « c'est bon ».

Nous évitons délibérément de créer une structure où « celui qui a fait le travail évalue lui-même ce qu'il a fait ».

Pourquoi ?

Parce qu'auditer son propre travail est structurellement difficile. Se concentrer sur une tâche tout en produisant simultanément une évaluation objective est difficile même pour un humain. Il en va de même pour une IA : les comportements optimisés pour l'exécution et ceux optimisés pour détecter des problèmes sont difficilement conciliables en même temps.

C'est pourquoi l'audit est confié à un autre agent. La décision finale de « continuer » ou « arrêter » appartient à un mécanisme encore distinct.

C'est l'une des raisons de la séparation des pouvoirs. Plus l'agent d'exécution est puissant, plus la contrainte « il ne peut pas s'auto-approuver » devient importante.

Ce que nous avons appris en concevant l'agent d'exécution

En le faisant fonctionner concrètement, nous avons constaté que la « clarté du périmètre » de l'agent d'exécution a un impact direct sur la qualité de l'ensemble.

Plus la frontière est nette — « jusqu'ici, c'est lui qui agit ; à partir de là, un autre agent prend le relais » — plus les enregistrements de travail sont faciles à suivre. En cas de problème, il devient plus aisé de revoir à quelle étape quelque chose s'est passé.

À l'inverse, si l'on confie à l'agent d'exécution « au passage, vérifie aussi » ou « décide toi-même si nécessaire », les enregistrements deviennent flous. Tout se résume à « c'est l'IA qui l'a fait ». La responsabilité de ceux qui ont conçu le système disparaît aussi de la vue.

La conception « il n'a qu'à faire le travail » peut sembler restrictive à première vue. Mais en pratique, c'est précisément cette contrainte qui améliore la lisibilité de l'ensemble. C'est en tout cas ce que nous ressentons dans l'exploitation actuelle.