La question porte sur les personnes, pas sur les agents
Donnez à un agent un moyen de payer et la réunion de revue change. Personne ne demande à quel point l'agent est malin. On demande à qui il est, ce qu'il a fait, ce qu'il aurait pu faire, et qui a dit oui.
Ce sont des questions de responsabilité, et la réponse doit pouvoir se consulter après coup, pas se reconstituer de mémoire. C'est à cela que sert une trace.
Une trace, de la demande au résultat
Dans Waggle, chaque action est un événement sur le bus d'événements. Un événement porte un identifiant, une heure, une source, un type, un workspace, un principal et un identifiant de trace. Le principal indique, par son identifiant, quel humain ou quel agent a agi. Les événements s'enchaînent grâce à l'identifiant de trace.
Une trace montre chaque tour d'agent : le workspace, l'agent, le compte auquel il appartient, ce qui l'a déclenché, le résultat, les outils et identifiants utilisés, ainsi que les approbations et la personne qui a tranché. Suivez une chaîne et vous pouvez relire un travail depuis la demande de la personne, en passant par le tour de l'agent, le bail d'identifiant accordé, l'approbation, jusqu'au résultat.
Cela existe aujourd'hui pour le travail des agents en général. La partie propre au paiement, un achat comme type d'événement à part entière, est ce que nous construisons ensuite.
Ce que demandent souvent les relecteurs de sécurité des paiements
Les relecteurs qui s'appuient sur des normes de cartes de paiement comme PCI DSS posent, en termes généraux, des questions semblables. Chaque personne est responsable à titre individuel. Les identifiants ne sont jamais exposés à ce qui les utilise. Il existe des limites à ce qui peut être dépensé. Et les journaux rattachent chaque action à un humain précis.
Nous ne prétendons à la conformité avec aucune norme. Ce que nous pouvons faire, c'est dire clairement comment la conception répond à ces questions. Responsabilité : chaque événement désigne son principal par son identifiant. Identifiants : ils sont sous séquestre, et un agent détient un bail, jamais la valeur. Journal : les événements partagent un identifiant de trace, donc une action remonte à la personne qui l'a demandée ou approuvée.
Les plafonds de dépense sont le seul point qui n'existe pas encore. Nous le dirons à chaque fois que le sujet reviendra.
Disponible aujourd'hui, et ce que nous construisons
Disponible aujourd'hui : des événements avec un principal et un identifiant de trace, des traces par tour d'agent, des approbations qui consignent qui a décidé, et des identifiants conservés sous séquestre avec des baux pour les agents. Rien concernant un paiement n'est en service. Un agent ne peut pas dépenser d'argent via Waggle aujourd'hui.
Nous construisons des événements de paiement sur le même bus : qui a autorisé un achat, quel agent a dépensé, un plafond de dépense par agent, et une approbation renforcée au-delà d'un seuil. Ainsi qu'un journal de paiement infalsifiable, et le masquage des numéros de carte dès l'entrée, pour qu'un numéro de carte collé dans un message n'atterrisse pas dans le journal.
Soyons précis sur le journal tel qu'il est. Le journal d'événements n'est ni signé ni chaîné par hachage, et il est conservé 90 jours par défaut, plus longtemps quand une archive est configurée. Un relecteur qui exige un journal que personne ne peut modifier discrètement, conservé un an ou plus, a besoin de plus que ce que nous avons. Signer ou chaîner par hachage le journal de paiement, et allonger la conservation, reste à ajouter.
Demandez à un modèle de relire la trace
Les traces sont des outils de l'endpoint MCP, vous pouvez donc y brancher un assistant. Ajoutez https://api.hachiflow.com/mcp à votre client, connectez-vous, et demandez en langage naturel ce que vos agents ont fait.
L'assistant appelle hachi_traces_ls pour lister les tours d'agent, en choisit un, et appelle hachi_trace_get dessus. Cela renvoie toute la chaîne d'événements liée à ce travail, et le modèle la restitue sous forme de court récit : qui a demandé, quel agent a agi, quel identifiant il a utilisé, qui a approuvé, ce qui s'est passé.
Aujourd'hui, cela répond à la question de qui a approuvé ce qu'un agent a fait. Les événements de paiement n'existent pas encore. Quand ils existeront, nous les construisons pour que la même question couvre la dépense, avec le montant et le plafond appliqué.
La question et les deux outils utilisés. La réponse vient de la trace, pas de la mémoire du modèle.
Les traces montrent aussi ce qu'il faut cesser de demander à un modèle
La lecture des traces a un second usage. Quand la même tâche revient tour après tour, avec les mêmes outils dans le même ordre et le même résultat, ce n'est plus vraiment une affaire de jugement. C'est une routine.
Ce sont les tâches à transformer en code déterministe. Gardez le modèle pour le travail qui varie, et laissez un simple script faire celui qui ne varie pas. La trace vous dit lequel est lequel, parce qu'elle enregistre ce qui s'est passé plutôt que ce dont chacun se souvient.
Où cela nous mène
La responsabilité du travail des agents est en service : principaux, chaînes de trace, approbations et baux d'identifiants. La responsabilité des dépenses des agents est planifiée : événements de paiement, plafonds de dépense, approbation renforcée et journal infalsifiable. Nous préférons vous dire lequel est lequel plutôt que de laisser croire que l'un couvre l'autre.