Je modifie un script d’agent en pleine nuit, et à mi-parcours je découvre qu’il change de modèle trois fois. Dans les logs, il ne reste qu’une suite de monologue. Une fois que ça a merdé, impossible de retracer quoi que ce soit. Avant d’éteindre mon ordinateur, j’ai sorti le x402 Gateway de @OpenGradient , pour voir si ce que disait l’agent sur l’eau, l’électricité, le chauffage et l’eau courante (bref, “l’infrastructure”) est juste du packaging, ou s’il a vraiment transformé le fait de régler le modèle et de conserver les preuves en une seule et même chose.
J’ai fait tourner le même agent sur le x402 Gateway, avec quatre chaînes de tâches différentes : chacune a été exécutée trois fois, au total douze exécutions. À chaque fois, j’ai consigné l’ordre des appels, les montants facturés, la signature, les nœuds où le middleware de routage des capacités tombait, ainsi que le reçu émis par la couche Verification Layer, et j’ai tout mis dans un tableau pour vérifier ligne par ligne. À chaque saut de modèle, la chaîne enregistre simultanément deux éléments : d’une part un micro-paiement basé sur la négociation HTTP 402, d’autre part un reçu d’exécution correspondant. Les deux sont liés par le même hash d’appel : l’un ne peut pas exister sans l’autre.
Dans la discussion grand public autour du x402 Gateway, le focus est presque entièrement sur la fonctionnalité qui ajuste le modèle en un clic, ressentie “à la sensation”. OpenGradient fait quelque chose de plus froid : il compresse l’appel et la conservation des preuves en une opération atomique. Avec HTTP 402, le paiement devient un champ de l’appel lui-même ; le middleware de routage des capacités, lui, fait correspondre les nœuds selon les prix. La couche Verification Layer fait en sorte que chaque déduction de frais corresponde à un reçu vérifiable par n’importe qui. Pour l’agent, vouloir dépenser = devoir laisser des preuves ; vouloir laisser des preuves = devoir d’abord payer.
Il faut aussi changer les indicateurs. Je ne regarde pas combien d’agents OpenGradient a fait connecter sur le x402 Gateway ; je surveille plutôt une donnée anti-consensus : parmi les appels qui font plusieurs sauts par jour, la part où les frais et les reçus correspondent parfaitement, de façon un-à-un. La première mesure la “chaleur”, la seconde mesure si cette histoire d’eau, électricité, chauffage, etc. relie vraiment la chaîne de responsabilité.
$RAVE
Si $OPG ne fait que prendre des frais de rapprochement pour un appel d’agent, alors c’est davantage une sorte de jeton-carburant pour agents. Mais si, à l’avenir, les enchères de prix des nœuds, la génération des reçus, la responsabilisation des actions de l’agent, la compensation inter-appels et le partage des revenus d’arbitrage sur de longues chaînes se mettent à tourner en circuit fermé autour de lui, alors la fonction qu’il remplit ne sera plus celle d’un simple jeton-carburant : ce sera un actif “noyau” de nettoyage/clearing dans le réseau de comptabilité des responsabilités de l’agent. $BASED
Pas de conclusions hâtives. L’infrastructure “eau, électricité, etc.” de l’agent doit supporter un vrai poids : il faut qu’elle traverse des chaînes réelles, longues. Je suis prêt à continuer d’observer les échantillons que montrent le mainnet d’OpenGradient et l’intégration des agents à venir. #opg