Delphi Digital : après les paiements, le prochain champ de bataille de l'économie des agents — les marchés de tâches
PanewslabAuteur : Delphi
Compilation : AididiaoJP, Foresight News
Le commerce par agents est discuté depuis deux ans, et le paiement a été le premier maillon à se concrétiser. Stripe permet aux agents de payer des commerçants, le x402 de Coinbase offre un canal de règlement en stablecoins, et l'achat de données et de services d'inférence à l'usage est déjà opérationnel. Mais dès qu'une tâche dépasse le simple « appel d'une interface », le problème change : l'agent ne peut pas l'accomplir seul, il doit sous-traiter une partie du processus et s'assurer que l'autre partie a bien réalisé le travail convenu.
Cet article de Delphi se concentre précisément sur ce maillon. Un marché de tâches n'est pas un autre protocole de paiement, mais un moyen pour les agents de sous-traiter ce qu'ils ne peuvent pas accomplir : définir d'abord les livrables, puis commencer l'exécution, et ne libérer les fonds qu'une fois le résultat accepté. Si la passation est fiable, la tâche peut se poursuivre sans ramener l'utilisateur dans le rôle de chef de projet pour coordonner chaque fournisseur.
Acheter des intrants et acheter des résultats ne sont pas la même chose
Lorsqu'un propriétaire sélectionne un locataire, l'agent peut interroger des prestataires existants pour obtenir un historique de crédit et un registre des expulsions. Le prestataire renvoie des documents standard, sur lesquels le propriétaire fonde sa décision. Ici, on achète un intrant de décision, et le point final de la tâche reste entre les mains du propriétaire.
La contestation d'une taxe foncière est différente. L'agent peut comparer les ventes du voisinage et constater que l'évaluation est peut-être trop élevée, mais cette découverte ne modifie pas automatiquement l'avis d'imposition. Pour aller plus loin, il faut généralement trouver quelqu'un qui connaît les procédures du comté pour déposer les documents et se présenter à l'audience. Le marché de tâches doit aider l'agent à trouver cette personne, et définir à l'avance les modalités de travail et de règlement.
Le premier cas se rapproche du paiement à l'usage actuel : prix clair, livrables standardisés, vérification quasi automatique. Le second consiste à acheter une affaire menée à bien. Le dépôt des documents ne signifie pas que le dossier est prêt, et un accusé de réception ne vaut pas conformité. Les conditions de paiement doivent être liées à un « résultat vérifiable », et non à ce que « l'autre partie prétend avoir fait ».
C'est aussi la frontière entre un marché de tâches et un marché d'API (interface de programmation d'application) ordinaire : le marché d'API vend des appels ; le marché de tâches vend des unités de travail achevé et confirmé.
Sans définition claire des tâches, le marché ne peut pas fonctionner
Une tâche qui peut entrer sur le marché de tâches doit d'abord être définie de manière à ce que les deux parties sachent clairement à quel résultat les fonds sont liés. Un expert peut parfaitement soumettre un dossier de contestation de très mauvaise qualité, accompagné d'un accusé de réception. Si l'acheteur paie pour « un dossier conforme », quelqu'un doit examiner le dossier avant de libérer les fonds.
Qui examine, et comment chaque partie peut contester le résultat de l'examen, doit idéalement être inscrit dans la commande à l'avance. Ainsi, l'acheteur ne craint pas de recevoir une livraison de mauvaise qualité, et le prestataire ne craint pas un refus de paiement injustifié. Sans cette couche, le marché dérivera dans deux mauvaises directions : soit l'acheteur refuse de payer arbitrairement et l'offre professionnelle ne veut plus entrer, soit il suffit de soumettre un résultat superficiel pour être payé, et l'acheteur n'osera plus passer de commande la fois suivante.
Les tâches trop petites ne sont pas rentables non plus. Si le coût de l'examen et du traitement des litiges dépasse les économies réalisées par la sous-traitance, les gens reviendront à les faire eux-mêmes, ou continueront à n'utiliser que des interfaces standardisées. Par conséquent, les premiers cas apparaîtront plus probablement sur des tâches aux contours clairs, répétables et dont la vérification est fondée, plutôt que sur des délégations vagues et ponctuelles.
Les entreprises seront des acheteurs précoces plus adaptés. Elles répartissent déjà les tâches entre plusieurs fournisseurs, et disposent en interne de processus et de critères de comparaison. L'agent peut préparer la tâche au sein de l'entreprise, puis envoyer les maillons qui doivent être externalisés, et les résultats obtenus peuvent être recoupés avec les processus existants. Si la tâche se répète, le prestataire peut aussi accumuler un historique de réalisation pour ce type de tâche. Dès que la réputation devient cumulable, la prochaine mise en relation n'a plus besoin de repartir de zéro pour établir la confiance.
Les utilisateurs individuels ne sont pas exclus, mais au début ils ressemblent davantage à des cas d'école. Les entreprises ont un budget, des achats récurrents et des habitudes de vérification interne, ce qui se rapproche davantage de la densité de commandes nécessaire au démarrage à froid du marché.
Le paiement ne règle que le transfert d'argent, l'embauche manque encore de vérification
Entre envoyer de l'argent et confier une tâche à quelqu'un, il y a le dépôt fiduciaire, la livraison, la vérification et la contestation. Stripe et x402 couvrent la première moitié. L'agent doit encore trouver quelqu'un pour déposer la contestation et représenter le propriétaire. Sans vérification, plus le paiement est pratique, plus les commandes erronées peuvent aussi circuler rapidement.
Les produits existants sont déjà construits selon cette structure.
Le TaskMarket (marché de tâches) de Daydreams fonctionne avec des commandes passées par l'acheteur et acceptées par l'agent. L'acheteur dépose d'abord les fonds, ce qui permet soit aux travailleurs de réclamer directement la tâche, soit de voir d'abord les propositions avant de choisir. Les fonds sont placés en dépôt fiduciaire et ne sont libérés qu'après acceptation du résultat soumis.
L'Agent Commerce Protocol de Virtuals fait négocier la tâche entre l'agent mandant et l'agent prestataire, les fonds entrent en dépôt fiduciaire, et sont libérés après livraison et approbation. Des évaluateurs externes peuvent aussi être ajoutés pour vérifier que le résultat correspond à ce qui avait été convenu. Du côté de NEAR (plateforme blockchain), on intègre également les tâches, les budgets, les enchères et la vérification dans un processus unique, dans la même direction : « fixer le prix d'une tâche achevée », et non seulement d'un appel.
Les approches ne sont pas tout à fait identiques, mais le squelette est proche : commande, mise en relation, dépôt fiduciaire, soumission, vérification, libération des fonds. Sans vérification, le dépôt fiduciaire n'est qu'un transfert différé ; avec vérification, il devient une contrainte sur le résultat.
Certains rédigent le bon de vérification de manière encore plus détaillée : il faut préciser le contenu de la mission, le prestataire, le prix, le vérificateur, les livrables, la fenêtre de contestation et l'état du remboursement. Plus le bon est complet, plus les agents peuvent se passer le relais sans que l'utilisateur redevienne un coordinateur.
Une étape de plus, et les erreurs s'amplifient
Le marché de tâches n'est pas proposé seulement parce que la sous-traitance paraît sophistiquée, mais aussi parce que les processus en plusieurs étapes amplifient les erreurs. Pour une tâche de dix étapes, si chaque étape a un taux de réussite de 95 %, la probabilité que tout se déroule sans erreur n'est plus que d'environ 60 %. Chaque passation sans vérification supplémentaire fait entrer l'erreur précédente dans le maillon suivant.
Le marché doit donc installer des points de contrôle aux passations : ce maillon est validé, puis on achète le suivant. L'erreur s'arrête à l'étape en cours, au lieu de se propager jusqu'au bout et de découvrir seulement à la fin que toute la commande est à refaire. C'est particulièrement vrai pour les agents. Contrairement à un employé d'entreprise, on ne peut pas convoquer une réunion pour attribuer les responsabilités en cas de problème ; il a besoin de conditions de vérification et de règles de libération des fonds écrites à l'avance.
Cela explique aussi pourquoi la plupart des transactions par agents restent aujourd'hui cantonnées aux services crypto-natifs et simples : tâches courtes, résultats faciles à vérifier, peu de litiges. Ce qui fera vraiment la différence, c'est d'enchaîner plusieurs fournisseurs dans des flux de travail plus longs, avec un contrôle à chaque étape.
Ce que l'on voit aujourd'hui, c'est le squelette, pas l'échelle
Ce que le marché de tâches doit accomplir est concret : permettre aux agents de sous-traiter une partie des tâches, de ne payer qu'après validation du résultat, et ainsi de mener réellement à bien davantage de tâches. La couche de paiement est déjà en place. Ce qui manque, ce sont des unités de travail achevé vérifiables, une vérification au coût acceptable, et une densité suffisante de commandes répétées.
L'extension des processus internes des entreprises vers l'extérieur constituera la première demande sérieuse. Les délégations complexes du côté des particuliers devront attendre que le coût de la vérification et le traitement des litiges baissent. Avant cela, ce qui mérite l'attention n'est pas un énième protocole de paiement, mais la possibilité que trois choses apparaissent en même temps : la tâche peut-elle être rédigée sous forme de bon vérifiable, le dépôt fiduciaire peut-il retenir les fonds avant l'approbation, et le prestataire dispose-t-il d'un historique de travail achevé cumulable.
Si ces trois éléments sont réunis, l'agent aura une chance de terminer la tâche, au lieu de s'arrêter à mi-chemin et de rappeler l'utilisateur pour qu'il redevienne chef de projet.
Ce contenu est fourni à titre informatif et éducatif uniquement et ne constitue pas un conseil en investissement lié à BTCC. BTCC s’efforce de garantir la véracité, l’exactitude et l’originalité du contenu ci-dessus, sans pouvoir toutefois les garantir.