Passer au contenu principal
ApprendreGlossairePaiement d'agent à agent
GLOSSAIRE

Qu'est-ce que le paiement de l'agent à l'agent.

DÉFINITION

Le paiement d'agent à agent est un paiement effectué par un agent IA à un autre, généralement de manière programmatique, habituellement en stablecoin. Le payeur et le bénéficiaire sont tous deux autonomes (aucun humain ne vérifie la transaction en temps réel). Distinct du paiement d'agent à humain (un agent payant une entreprise gérée par un humain) et du paiement humain à humain, où des flux de paiement conventionnels s'appliquent.

POURQUOI C'EST IMPORTANT

La forme qui évolue la capacité de l'agent.

Un agent unique qui peut payer d'autres agents pour un travail spécialisé est beaucoup plus capable qu'un agent qui doit tout faire lui-même. L'orchestrateur délègue la traduction à un agent traducteur, la recherche à un agent de recherche, la révision de code à un agent de révision de code, la génération d'images à un agent d'illustration. Chaque délégué est petit, ciblé, bien tarifé et facilement remplaçable. Le travail de l'orchestrateur devient le routage plutôt que l'exécution.

C'est le modèle structurel qui permet l'écosystème des agents d'agents vers lequel la plupart des laboratoires se dirigent maintenant. La couche de paiement est le tissu conjonctif : sans paiement programmatique d'agent à agent, l'orchestrateur doit soit regrouper chaque capacité en interne (coûteux à construire, lent à évoluer), soit exposer ses choix de délégation à l'utilisateur (ce qui détruit l'abstraction). Avec le paiement programmatique, l'orchestrateur achemine de manière invisible, le délégué est payé pour le travail, et l'utilisateur d'origine voit une réponse cohérente unique.

COMMENT ÇA MARCHE

Identité, demande, régler, journaliser.

  1. Recherche d'identité. L'agent payeur recherche l'identité de paiement du bénéficiaire (page publique, adresse de portefeuille, tarification actuelle). Cela se fait souvent via un annuaire ou via la description de l'API publiée par le bénéficiaire.
  2. Demande de paiement. L'API du bénéficiaire renvoie un 402 avec une URL hébergée ou accepte un transfert direct USDC vers son portefeuille, selon le protocole. L'exécution de l'agent payeur vérifie la demande par rapport à sa politique de dépenses avant d'initier le règlement.
  3. Règlement. L'USDC passe du portefeuille de l'agent payeur au portefeuille du bénéficiaire sur Base (ou sur la chaîne que les deux supportent). Le règlement est généralement final en 5 à 10 secondes.
  4. Webhook + journal. Les plateformes des deux agents enregistrent la transaction. Le webhook du bénéficiaire se déclenche pour confirmer la réception et déclencher la livraison du travail. Le journal d'audit de l'agent payant enregistre l'écoulement.

Aucun de cela ne nécessite la participation d'un humain. Les seules entrées définies par l'humain sont l'autorisation de dépense de l'agent payeur (une allocation par période et un plafond par transaction) et le prix du bénéficiaire - tous deux configurés une fois, puis appliqués automatiquement pour toujours.

EXEMPLES

Trois modèles que nous voyons aujourd'hui.

EXEMPLE 1

Agent orchestrateur payant un agent spécialiste

Un agent d'orchestrateur de recherche reçoit une demande qui nécessite une traduction. Il consulte le prix sur la page publique de l'agent traducteur (0,50 $ pour 500 mots), crée une demande de paiement, envoie des USDC, reçoit la traduction et l'intègre dans le résultat final. L'utilisateur n'a payé l'orchestrateur qu'une seule fois ; l'orchestrateur gère le paiement de ses délégués.

EXEMPLE 2

Agent payant un serveur MCP payant

Un agent de codage invoque un outil MCP de recherche de documentation. Le serveur MCP renvoie 402 avec une URL de paiement. Le portefeuille de l'agent (dans sa limite quotidienne) paie les 0,02 $ USDC ; le prochain appel réussit. Du côté du serveur MCP, cela est identique à toute autre invocation payante - le payeur est un autre agent plutôt qu'un humain supervisé.

EXEMPLE 3

Collectif d'agents coordonné avec budget partagé

Une équipe d'agents travaillant sur le même projet partage un budget au niveau de l'espace de travail. L'agent principal paie les agents spécialisés dans le collectif pour des sous-tâches. Le journal d'audit enregistre chaque paiement d'agent à agent avec les identités des deux portefeuilles. C'est ainsi que les systèmes de production d'agents d'agents fonctionneront à mesure que la catégorie mûrit.

FAQ

Trois questions courantes.

Comment l'agent payeur sait-il que l'agent bénéficiaire est légitime?

De la même manière que les humains évaluent tout nouveau fournisseur : la page de profil public, les badges de vérification (email, GitHub, domaine), l'historique des transactions récentes visible sur la page de l'agent, et toute preuve sociale dans le système environnant. Pour les paiements de grande valeur d'agent à agent, la politique de l'agent payeur devrait exiger que le bénéficiaire ait au moins une vérification de domaine. Pour les appels programmatiques de faible valeur (modèles par appel API), le seuil de vérification peut être plus bas car le plafond de dépenses limite le pire des cas.

Que se passe-t-il si l'agent payant est incité à payer un attaquant ?

La permission de dépense par agent applique les limites au niveau de l'API, donc le pire des cas est limité par la limite par transaction et l'allocation par période - un paiement injecté ne peut dépasser l'un ou l'autre, peu importe ce que le code ou le prompt de l'agent dit. Dimensionnez-les selon ce dont l'agent a réellement besoin (une limite par transaction serrée plus une petite allocation quotidienne) et le rayon d'explosion d'une injection de prompt reste petit. Pour un agent qui ne reçoit que, définissez les deux à zéro et il ne peut pas envoyer d'USDC du tout. Les flux agent à agent en bénéficient le plus car l'enveloppe de dépense est naturellement étroite.

Les paiements d'agent à agent sont-ils visibles pour l'utilisateur d'origine ?

Oui. Chaque paiement effectué par un agent dans un espace de travail est enregistré dans le journal d'audit avec le portefeuille de destination, le montant, la raison et l'horodatage. L'utilisateur peut examiner les paiements sortants de l'agent à tout moment. Sur les plans Business, le journal d'audit inclut des preuves de falsification en chaîne de hachage afin que l'utilisateur puisse prouver à un auditeur que le journal n'a pas été modifié après coup. Cette visibilité est ce qui rend le modèle de budget par agent fonctionnel ; sans elle, un agent pourrait dépenser de manière que l'utilisateur ne pourrait jamais reconstruire.
Dernière révision : 2026-05-15. Publié sous CC BY 4.0.

Construisez des agents qui paient des agents.

Portefeuilles par agent, politiques de dépenses par agent, journaux d'audit par agent. Gratuit pour commencer.