Comment maîtriser ce qu'un agent a le droit de faire ?
Un agent qui ne peut que lire n'est pas le même risque qu'un agent qui peut envoyer. PROMIVO rend cette distinction explicite au lieu de la confier au prompt, et le réglage est visible avant tout déploiement.
Dans ce guide
Comment les actions sont-elles classées ?
En trois niveaux. READ ne peut que lire et ne change rien. WRITE peut envoyer, publier et mettre à jour des enregistrements. DESTRUCTIVE peut en plus supprimer. Chaque outil qu'un agent peut appeler est classé : le niveau est donc une propriété de l'action, et non une promesse dans les instructions.
Que fait vraiment le plafond ?
Chaque version d'agent porte le niveau maximal qu'elle peut exécuter seule, et ce qui le dépasse n'a pas lieu. La tentative est bloquée, consignée avec les arguments exacts qu'elle allait employer, et affichée sur l'exécution comme retenue pour validation ; l'agent est informé que l'action n'a pas été effectuée et poursuit sans elle. Un agent réglé sur READ peut donc vous dire ce qu'il aurait envoyé, mais rien ne quitte votre compte.
Où voir ce qu'un agent peut atteindre ?
Sur sa fiche, avant déploiement. Elle énumère les outils qu'il peut appeler et les intégrations dont il a besoin. Un agent ne peut pas atteindre un système que vous n'avez pas connecté, et le connecter est une étape explicite.
Qu'est-ce qui empêche une exécution de durer indéfiniment ?
Chaque version d'agent a des limites : nombre maximal d'étapes, nombre maximal d'appels d'outils, plafond de jetons par exécution et délai d'expiration. Elles bornent une exécution qui s'emballe — ce que la dotation de la formule ne peut pas faire, puisqu'une formule est un budget mensuel et qu'un emballement tient dans un après-midi.
Puis-je valider une action retenue pour qu'elle s'exécute ?
Pas aujourd'hui. Une action retenue est un arrêt, pas une file d'attente : vous voyez ce qu'elle allait faire, mais aucun bouton ne la libère, et l'exécution est déjà terminée quand vous le lisez. Si vous voulez que cette action se produise automatiquement, la solution honnête est de relever délibérément le plafond de l'agent plutôt que de valider au cas par cas. Nous préférons le dire franchement que décrire une boîte de validation qui n'existe pas encore.
Reste-t-il une trace de ce qu'a fait un agent ?
Chaque exécution conserve son entrée, sa sortie, son journal d'étapes et les jetons consommés, et chaque appel d'outil apparaît comme une étape avec son niveau de risque. À part cela, le journal d'audit du compte enregistre ce que font les personnes — connecter une intégration, attribuer un agent, modifier un workflow, émettre une clé d'API — avec qui et quand.
Puis-je changer le plafond après déploiement ?
Le plafond appartient à la version de l'agent. Le modifier publie une nouvelle version plutôt que de retoucher celle qui a déjà tourné : la trace de ce qu'une exécution passée avait le droit de faire reste donc exacte.