Je n’arrêtais pas de remarquer le même schéma en passant du temps au sein du protocole Newton. La question n’était jamais de savoir si un agent d’IA avait accompli une tâche. Il s’agissait de savoir si je pouvais mesurer à quel point je devrais faire confiance au chemin qu’il a emprunté avant d’arriver à ce résultat. Cela paraît subtil, jusqu’à ce qu’un flux de travail échoue pour des raisons impossibles à examiner après coup. Le protocole Newton ramène cette couche cachée au premier plan, et je pense que c’est là que le projet devient vraiment passionnant.
La confiance devient utile uniquement lorsqu’on force quelqu’un à payer le coût opérationnel consistant à la prouver.
Un exemple revenait sans cesse à l’esprit pendant que je testais Newton Protocol. Un agent IA a effectué trois actions dépendantes avant de demander un paiement final on-chain. D’abord, il a récupéré des données de tarification, puis a sélectionné un itinéraire, et enfin a préparé la transaction pour exécution. Si seul le paiement final réussit, je ne sais toujours pas si l’itinéraire a été choisi à partir d’entrées cohérentes, ou si une étape précédente a discrètement dérivé. Le flux de vérification de Newton rend ces décisions intermédiaires observables au lieu de tout réduire à un événement de succès unique. Ça donne l’impression d’être plus lent, parce qu’une autre couche de validation doit s’exécuter avant que l’exécution continue, mais rejouer un succès inexpliqué devient beaucoup plus difficile. La friction quitte mon workflow de débogage et se déplace dans le protocole lui-même, où elle doit se trouver plutôt que de devenir l’enquête de demain.
Ça ressemble à une amélioration évidente, jusqu’au moment où la contrepartie commence à se manifester.
Supposons que la vérification mette en pause le workflow parce qu’une dépendance ne peut pas reproduire le même résultat deux fois. Au lieu de réessayer discrètement jusqu’à ce que, finalement, quelque chose passe, Newton demande en quelque sorte si le simple fait de réessayer mérite la confiance. J’ai d’ailleurs trouvé cela légèrement frustrant. Attendre un autre cycle de validation semble inefficace quand on essaie juste de terminer une opération de routine, pourtant j’ai aussi remarqué que je passais beaucoup moins de temps ensuite à remettre en question l’issue finale. Le délai s’est déplacé vers l’exécution au lieu de se manifester plus tard comme une incertitude. Je ne sais toujours pas si chaque workflow mérite cet échange, surtout quand les utilisateurs optimisent naturellement la vitesse avant d’optimiser la confiance.
Un autre détail a modifié ma façon de penser la fiabilité. Lors d’un workflow, j’ai imaginé un agent comparant les sorties de plusieurs modèles avant de décider s’il faut exécuter une transaction. Quatre réponses pointaient vers la même action, tandis qu’une produisait un résultat sensiblement différent. Dans beaucoup de systèmes, ce désaccord disparaît parce que la transaction finit tout de même par aboutir. Newton traite le désaccord comme faisant partie du registre d’exécution plutôt que comme quelque chose à lisser. La conséquence immédiate est que la logique incohérente devient visible avant l’engagement, au lieu de se transformer en session de débogage de demain. La question passe alors de « La transaction a-t-elle réussi ? » à « La logique était-elle suffisamment stable pour mériter l’exécution ? »
Je me demande sans cesse combien de workflows d’IA existants survivraient réellement à ce type d’exposition.
Si vous avez déjà expérimenté des agents autonomes vous-même, accepteriez-vous une étape de vérification en plus si elle éliminait systématiquement des heures de débogage a posteriori ? Ou est-ce que la latence supplémentaire deviendrait inacceptable dès que les requêtes commencent à s’empiler sous charge ? Je ne sais vraiment pas où se situe ce seuil, car différents workloads semblent échouer pour des raisons très différentes. On a l’impression que la réponse dépend moins de la philosophie d’ingénierie que du coût de l’échec après le déploiement.
Il y a une autre question qui me trotte dans la tête. À partir de quel moment la confiance mesurable devient-elle suffisamment coûteuse pour que les équipes cessent discrètement de la mesurer ? Chaque preuve supplémentaire, chaque tour de validation ou chaque contrôle d’exécution augmente quelque part la charge de calcul. Le protocole absorbe une grande partie de cette complexité, mais quelqu’un paie quand même : en temps, en infrastructure ou en exigences de participation. Les coûts cachés ne disparaissent que rarement. Ils migrent le plus souvent vers une autre couche.
C’est probablement aussi pour cela que le rôle du token $NEWT a commencé à me sembler plus clair seulement après avoir réfléchi à ces mécanismes. Si les participants sont censés contribuer à la vérification, à la sécurité et à la responsabilité économique, alors attacher des incitations à ces responsabilités ressemble moins à un dispositif de levée de fonds et davantage à de la maintenance d’infrastructure. Le token commence à représenter la responsabilité avant même de représenter la propriété.
J’ai toutefois un biais persistant. Je préfère naturellement les systèmes qui exposent l’incertitude plutôt que de la masquer ; peut-être suis-je donc plus tolérant à la friction opérationnelle que la plupart des utilisateurs. J’aimerais voir où d’autres personnes perdent patience. Est-ce après un cycle de vérification supplémentaire ? Deux ? Ou seulement après avoir vécu le premier échec qui peut réellement s’expliquer, au lieu d’être deviné ?
C’est ce qui ressemble à la mesure la plus intéressante. Pas de savoir si la confiance existe, mais plutôt la quantité de friction visible que les gens sont prêts à accepter avant de décider que la confiance ne vaut plus la peine d’être mesurée.