Graphe d’exécution

Le graphe d’exécution est l’historique de ce qu’un agent a réellement fait. Il est construit à partir des événements que le client envoie après chaque décision, et c’est lui qu’OpenLatch confronte à l’Autonomy Zone de l’agent.

Ce qu’il montre

Chaque agent a un onglet Execution Graph. Il se lit de gauche à droite, de l’agent jusqu’à ce qu’il a touché :

Couloir	Ce qu’il contient
Agent	L’agent concerné par le graphe
Exécutions	Ses sessions, une carte par exécution
Surfaces	Ce vers quoi il s’est tourné, déduit du nom des outils
Outils	Ce qu’il a invoqué
Artefacts	Ce qu’il a touché ou lancé : fichiers, domaines réseau et commandes

Les couloirs convergent vers ce que les exécutions partagent : vous voyez les chemins qu’un agent emprunte le plus et ceux qu’il emprunte rarement.

app.openlatch.ai/agents/ci-runner-payments-01/execution-graph

L’onglet Execution Graph d’un agent : exécutions, surfaces, outils et artefacts, de gauche à droite.

Deux plans l’alimentent

Plan	Ce que capture le client
Plan de commande	Chaque appel d’outil et chaque commande shell, interceptés au hook natif de l’agent avant leur exécution
Plan de requête	Chaque requête sortante vers un modèle, interceptée par un écouteur sur la même machine, avec son modèle, ses tokens et son coût

Les autres onglets d’un agent découpent le même historique par type : commandes, fichiers, domaines, serveurs MCP, skills, hooks, sessions et économie.

D’une action à une politique

Quand le graphe montre une commande que vous voulez encadrer, ouvrez-la et lancez une nouvelle politique d’intention à partir de cette action. Le brief part de ce que l’agent a réellement lancé, et la politique passe par la même relecture et la même ratification que toute autre. Politiques d’intention explique ce chemin.

Une action qu’aucune politique n’a décidée est enregistrée comme autorisée par défaut, et non comme permise par une décision. Le graphe distingue les deux.