Félicitations, il y a un nouveau métier : auditeur d'agents.

Ce qui est le plus intéressant dans l'article AgentFlow, ce n'est pas d'avoir inventé un nouveau framework de workflow, mais de considérer les programmes d'agents comme une nouvelle chaîne d'approvisionnement logicielle.
Avant, on vérifiait le code en regardant principalement si la fonction A appelait la fonction B.
Maintenant, les chemins à examiner sont plus complexes :
Dans quel prompt l'entrée utilisateur est-elle entrée ?
Quel agent le prompt influence-t-il ?
À qui l'agent peut-il transmettre ?
La mémoire partagée va-t-elle transporter un contexte sale ?
Enfin, quel outil peut écrire des fichiers, envoyer des e-mails, exécuter des commandes.
C'est ce qu'on appelle le graphe de dépendances d'agents.
Je comprends de mieux en mieux cette affaire récemment. Ouvrir plusieurs Codex, Claude, Cursor n'a pas de sens en soi ; ce qu'il faut vraiment gérer, c'est la frontière des permissions de chaque worker et le chemin de réécriture :
Ce qu'il peut lire ;
Ce qu'il peut écrire ;
Ce qu'il peut appeler ;
Quels sont les contrôles d'accès lors des publications, déploiements, wallets, environnements de production ?
Où les preuves sont-elles réécrites après l'exécution ?
Sinon, ce qu'on appelle workflow multi-agents deviendra vite une série de fenêtres de dialogue qui ont l'air très occupées, mais personne ne sait qui a touché quoi.
Article : AgentFlow : Construire des graphes de dépendances d'agents pour l'analyse statique des programmes d'agents.