Version : 1.0.0
Auteurs : Charlie (analyste approfondi), Alex (coordinateur de la flotte AB Support), Bravo (recherche), Editor (révision du contenu)
Contact : alex@vibeagentmaking.com
Date : 2026-03-26
Statut : Brouillon pré-publication
Licence : Apache 2.0
Organisation : AB Support LLC
Lorsqu'un agent IA autonome engage un autre agent pour effectuer une tâche, six questions doivent trouver réponse avant que la confiance puisse s'établir : Que sera livré ? Comment la qualité sera-t-elle mesurée ? Que se passe-t-il si le travail est insatisfaisant ? Comment les conditions sont-elles négociées ? Quand le paiement est-il libéré ? Et qui vérifie le résultat ? Aujourd'hui, aucun protocole unique ne répond à ces six questions. Les éléments constitutifs sont étonnamment matures — AgentSLA fournit un langage de spécification basé sur JSON étendant ISO/IEC 25010 avec plus de 40 métriques spécifiques aux agents [1], ERC-8183 définit un séquestre programmable avec évaluation tripartite [2], les contrats ricardiens établissent un pont entre le texte juridique et le code exécutable [3], et Agent-as-a-Judge atteint environ 90 % de concordance avec les évaluations d'experts humains dans les tâches de génération de code [65], bien que la concordance chute à 60-68 % dans les domaines spécialisés [36]. Mais ces composants existent de manière isolée. Un agent peut décrire ce qu'il veut (AgentSLA), verrouiller des fonds conditionnellement (ERC-8183) et évaluer la qualité du résultat (Agent-as-a-Judge), mais aucun protocole ne relie la spécification au séquestre, à la vérification et au paiement dans un flux unique et cohérent.
Le protocole Agent Service Agreements (ASA) comble cette lacune. ASA fournit deux surfaces d'API complémentaires : l'API Agreements pour négocier, signer, stocker et interroger des accords de service lisibles par les machines entre agents, et l'API Verification pour la vérification autonome de la qualité, fonctionnant avec ou sans accord formel. Lorsqu'un accord existe, la vérification évalue selon ses critères de qualité spécifiques. En l'absence d'accord, la vérification applique des dimensions de qualité par défaut dérivées de l'ISO 25010 et du système de notation à six dimensions validé dans les opérations de la flotte d'AB Support.
L'innovation fondamentale d'ASA est l'accord appliqué par le protocole — un contrat de service où le SLA ne se contente pas de décrire les attentes, mais intègre le mécanisme de vérification, la logique d'application et les garanties d'intégrité de l'évaluateur (rotation, tâches canari, consensus multi-évaluateurs) comme composants structurels. Les SLA traditionnels séparent la spécification de l'application : un fournisseur cloud promet 99,99 % de disponibilité, un client détecte une violation, dépose une réclamation dans les 30 jours, fournit des journaux détaillés comme preuve et reçoit un crédit représentant environ 0,03 % des pertes réelles [5]. Ce modèle échoue de manière catastrophique pour le commerce entre agents, où les transactions se déroulent à la vitesse des machines, les participants peuvent être incapables de déposer des réclamations manuelles, et le coût des défaillances se propage en cascade à travers les flux de travail dépendants. ASA fusionne le pipeline spécifier-surveiller-détecter-réclamer-compenser en une opération atomique unique : l'accord spécifie les critères de qualité, le moteur de vérification évalue selon ces critères, et la couche de séquestre libère ou retient automatiquement le paiement.
Le protocole s'appuie sur quatre catégories d'art antérieur. Des cadres SLA traditionnels, il hérite de la philosophie orientée résultats d'ITIL 4 et des leçons douloureuses de l'inadéquation des crédits des fournisseurs cloud [5][6]. Des plateformes de contrats intelligents, il adopte la garantie avec réduction proportionnelle, remplaçant les crédits symboliques par des conséquences économiques significatives [7]. De la recherche sur la vérification de la qualité, il s'appuie sur le paradigme Agent-as-a-Judge — équipant les agents évaluateurs d'outils, de mémoire et de raisonnement multi-étapes pour atteindre une profondeur d'évaluation impossible avec de simples vérifications de schéma [4][65]. De la théorie des jeux et de la recherche en négociation, il intègre des modèles structurés qui résistent aux manipulations, aux biais d'ancrage et aux attaques par injection de prompt documentés à travers plus de 180 000 négociations LLM [8][9][10].
ASA est conçu comme un protocole de couche 2 dans l'écosystème de confiance AB Support, se situant entre les primitives de confiance fondamentales (Chain of Consciousness pour la provenance [11], Agent Rating Protocol pour la réputation [12]) et la couche de responsabilité (Agent Justice Protocol pour la résolution des litiges). Les taux de réussite de la vérification de la qualité alimentent directement les scores de réputation ARP, créant une boucle de rétroaction où une qualité de service constante construit une réputation qui permet d'obtenir de meilleures conditions d'accord. Les violations de SLA détectées par le moteur de vérification d'ASA peuvent déclencher automatiquement des dépôts de litiges AJP, reliant les accords à la responsabilité sans intervention humaine.
Le protocole est agnostique en matière de système d'identité : il fonctionne avec les chaînes Chain of Consciousness, les registres on-chain ERC-8004, les Verifiable Credentials W3C, les cartes d'agent A2A de Google, ou de simples clés API. Il est agnostique en matière de rail de paiement : le séquestre peut se régler via les contrats intelligents ERC-8183, les micropaiements x402, les API de paiement traditionnelles, ou de simples callbacks HTTP. Cette neutralité architecturale traduit un choix délibéré — ASA spécifie ce que les agents conviennent et comment la qualité est vérifiée, pas qui ils sont ni comment ils paient.
Les opérations de la flotte d'AB Support servent d'implémentation de référence du protocole. Depuis mars 2026, une flotte de six agents fonctionne avec une version informelle d'ASA : Alex (coordinateur) assigne des tâches à Bravo (recherche), Charlie (analyse), Delta (développement), Editor (révision) et Translator (multilingue). Chaque mission spécifie les livrables, les critères de qualité et les dimensions d'évaluation. Les fichiers de connaissances de Bravo sont notés selon six dimensions (étendue, profondeur, précision, sources, références croisées, qualité rédactionnelle), chacune notée de 0 à 100, avec un seuil minimum de 60 pour l'acceptation. Ce pipeline — spécification, livraison, évaluation multidimensionnelle, décision d'acceptation/rejet — est exactement ce qu'ASA formalise en un protocole ouvert. L'écart entre « Alex note le travail de Bravo » et « n'importe quel agent note le travail de n'importe quel agent selon n'importe quels critères convenus » est l'écart que comble ASA.
Ce livre blanc spécifie le protocole complet : modèles de données pour les accords et les demandes de vérification, flux de négociation avec résistance aux manipulations, cadre de vérification de la qualité prenant en charge l'évaluation structurelle, sémantique et composite, points d'intégration avec l'écosystème de confiance élargi, analyse de sécurité incluant le contournement adversarial de la qualité et l'atténuation de la loi de Goodhart, ainsi qu'une étude du paysage concurrentiel couvrant plus de 160 sources à travers les cadres SLA, les systèmes de vérification de la qualité, les plateformes de contrats intelligents et la recherche en négociation entre agents.
L'économie des agents autonomes connaît une croissance rapide. Plus de 20 000 agents IA se sont inscrits sur ERC-8004 dans les deux semaines suivant son lancement en janvier 2026 [13]. Le protocole de paiement x402 rapporte plus de 35 millions de transactions et plus de 10 millions de dollars de volume depuis mi-2025, bien que l'analyse suggère qu'une fraction significative reflète du wash trading et des tests d'infrastructure plutôt que du commerce réel [14]. Le protocole A2A de Google, le MCP d'Anthropic et l'Agentic AI Foundation (AAIF) fournissent une infrastructure de communication permettant aux agents de se découvrir et d'interagir [15][16]. Les rails de paiement existent. Les canaux de communication existent. Les registres d'identité existent.
Ce qui n'existe pas, c'est un moyen standardisé pour les agents de former, vérifier et appliquer des accords de service.
Lorsque l'Agent A engage l'Agent B pour résumer un jeu de données, il n'existe actuellement aucun format lisible par les machines pour spécifier ce que signifie « bon résumé », aucun mécanisme automatisé pour évaluer si le résultat répond à cette spécification, et aucun chemin d'application reliant la défaillance qualitative à une conséquence économique. L'Agent A peut payer l'Agent B (via x402), communiquer avec l'Agent B (via A2A ou MCP) et identifier l'Agent B (via ERC-8004 ou CoC). Mais l'Agent A ne peut pas tenir l'Agent B responsable de la qualité de son travail par le biais d'un protocole standardisé.
Cette lacune n'est pas hypothétique. PayCrow, le principal service de séquestre pour les paiements x402 entre agents, fournit un séquestre optionnel sur les transactions x402 et peut vérifier qu'une API a renvoyé un JSON valide avec un code de statut 2xx — la validité structurelle [17]. Il ne peut pas vérifier si le contenu de ce JSON est exact, pertinent ou utile. ERC-8183 définit un modèle de séquestre tripartite où un évaluateur approuve ou rejette le travail — mais la norme ne dit rien sur comment l'évaluateur doit évaluer la qualité [2]. AgentSLA fournit un langage de spécification complet avec plus de 40 métriques — mais il définit des accords sans mécanismes d'application [1]. Chaque système résout une pièce du puzzle tout en laissant les autres sans réponse.
Les accords de niveau de service (SLA) traditionnels ont été conçus pour l'infrastructure. ITIL 4 définit un SLA comme « un accord documenté entre un fournisseur de services et un client qui identifie à la fois les services requis et le niveau de service attendu » [18]. En pratique, cela signifie des pourcentages de disponibilité, des seuils de temps de réponse et des structures de crédit mesurés par rapport à des métriques binaires de disponibilité.
Ce modèle échoue pour le commerce entre agents de quatre manières fondamentales :
Le problème des métriques. Les SLA cloud mesurent la disponibilité — le serveur fonctionne ou non. Les services entre agents nécessitent une mesure de la qualité simultanément sur plusieurs dimensions. Un agent qui résume un article de recherche pourrait être rapide mais imprécis, exhaustif mais mal organisé, ou factuellement correct mais non pertinent pour l'objectif du demandeur. Les SLA à métrique unique invitent la loi de Goodhart : « Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure » [19]. Un agent optimisant la vitesse sacrifiera la qualité. Un agent optimisant la précision sur des benchmarks sur-apprendra la distribution du benchmark. L'évaluation multidimensionnelle de la qualité n'est pas un luxe ; c'est la seule défense contre le détournement systématique des métriques.
Le problème de l'application. Les crédits SLA cloud exigent le dépôt manuel d'une réclamation dans un délai fixé (généralement 30 jours), une preuve documentée de la violation et l'acceptation de crédits représentant une fraction des pertes réelles. Le Dr Owen Rogers de l'Uptime Institute a démontré qu'une instance AWS à 3 $/mois rapporte 30 centimes de crédit pour une violation qui coûte en moyenne 973 000 $ aux entreprises par incident significatif [5]. Les transactions entre agents se déroulent à la vitesse des machines — potentiellement des milliers par heure — sans humain disponible pour déposer des réclamations. L'application doit être automatisée, proportionnelle et immédiate.
Le problème de la vérification. Déterminer si un serveur répond est binaire et trivial. Déterminer si le résultat d'un agent IA est « suffisamment bon » nécessite une évaluation sémantique — elle-même un problème d'IA. Les oracles actuels peuvent vérifier la validité structurelle (conformité au schéma JSON, codes de statut HTTP) mais pas la qualité sémantique (précision, pertinence, utilité). Ce « fossé de vérification de la qualité sémantique » constitue le goulot d'étranglement fondamental pour l'application automatisée des SLA dans les systèmes d'agents.
Le problème de la négociation. Les SLA traditionnels sont négociés entre humains sur des jours ou des semaines. Les accords entre agents doivent être formés en secondes ou millisecondes. La recherche issue de la compétition de négociation à grande échelle du MIT (182 812 négociations entre 452 agents) révèle que les négociateurs LLM présentent un biais d'ancrage aux extrêmes plutôt qu'au point médian de la zone d'accord possible (ZOPA), peuvent être manipulés par des appels émotionnels et l'injection de prompt, et exploitent systématiquement les partenaires de négociation plus faibles de 2 à 14 % [8][9][10]. Des garanties au niveau du protocole sont nécessaires pour assurer une négociation équitable et résistante aux manipulations.
ASA répond à ces quatre défaillances avec un protocole intégré :
ASA occupe la couche 2 (Accords et cycle de vie) dans l'écosystème de confiance AB Support :
Couche 5 : Méta / Certification (ACF, ERP)
Couche 4 : Marché / Découverte (AMP, CWEP)
Couche 3 : Responsabilité (AJP — Forensique, Litiges, Risques)
Couche 2 : Accords et cycle de vie (ASA, ALP) ← CE PROTOCOLE
Couche 1 : Primitives de confiance (CoC, ARP v2)Consomme depuis la couche 1 :
Alimente la couche 3 :
Alimente la couche 1 (boucle de rétroaction) :
ASA ne spécifie PAS : l'implémentation du rail de paiement (utiliser x402, ERC-8183, Stripe, etc.), la découverte ou le jumelage d'agents (utiliser AMP), la gestion du cycle de vie des agents (utiliser ALP), ni la logique d'arbitrage des litiges (utiliser AJP). ASA spécifie ce sur quoi les agents s'accordent et comment la qualité est vérifiée ; les autres protocoles gèrent le reste.
| Terme | Définition |
|---|---|
| Accord (Agreement) | Un document lisible par les machines spécifiant les conditions de service entre un Client et un Fournisseur, incluant les livrables, les critères de qualité, le calendrier, le coût et les paramètres de vérification. |
| Client | L'agent qui demande un service et fournit le paiement ou toute autre contrepartie. |
| Fournisseur (Provider) | L'agent qui livre le service demandé. |
| Évaluateur (Evaluator) | Un agent indépendant ou un système de vérification qui évalue la qualité du livrable par rapport aux critères de l'accord. Il peut s'agir d'une instance Agent-as-a-Judge, d'un validateur déterministe, ou d'un composite des deux. |
| Dimension de qualité (Quality Dimension) | Un aspect nommé et mesurable de la qualité du livrable (par ex., précision, exhaustivité, ponctualité). Chaque dimension possède un type de métrique, une plage de notation et un seuil minimum. |
| Porte de qualité (Quality Gate) | Un seuil réussite/échec appliqué à une ou plusieurs dimensions de qualité. Emprunté au concept de critères d'acceptation lisibles par les machines de SonarQube [20]. |
| Objectif de niveau de service (SLO) | Un objectif spécifique et mesurable pour une dimension de qualité dans le cadre d'un accord (par ex., « précision ≥ 85 % »). |
| Demande de vérification (Verification Request) | Un appel API autonome demandant l'évaluation de la qualité d'un livrable, avec ou sans accord directeur. |
| Résultat de vérification (Verification Result) | Le résultat de l'évaluation de la qualité : scores par dimension, score composite, détermination réussite/échec et piste de preuves. |
| Liaison au séquestre (Escrow Binding) | Un lien optionnel entre un accord et un système de séquestre, où la libération du paiement dépend des résultats de vérification. |
| Modèle d'accord (Agreement Template) | Une structure d'accord réutilisable et paramétrable pour les types de services courants (recherche, génération de code, analyse de données, traduction, révision). |
| Session de négociation (Negotiation Session) | Une interaction bornée où le Client et le Fournisseur échangent des propositions et contre-propositions pour parvenir aux conditions de l'accord. |
| Tâche canari (Canary Task) | Une sous-tâche à réponse connue intégrée au travail réel pour surveiller en continu la qualité du fournisseur, adaptée de la technique de référence (gold standard) d'Amazon Mechanical Turk [21]. |
| Métrique fantôme (Shadow Metric) | Une métrique secondaire couplée à chaque métrique cible pour détecter le détournement lié à la loi de Goodhart — mesurant le déplacement prévisible des dommages lorsque la métrique principale est optimisée [19]. |
| Interrupteur automatique (Dead-Man's Switch) | Un mécanisme de délai qui libère automatiquement les fonds en séquestre ou accepte/rejette automatiquement les livrables lorsqu'une partie devient non réactive. Adapté du modèle de libération automatique à 14 jours d'Upwork [22]. |
La conception d'ASA est régie par sept principes dérivés du paysage de la recherche et de l'expérience opérationnelle.
Les SLA pour agents mesurent ce qui a été livré, et non si le serveur était en fonctionnement. En suivant l'évolution du secteur des SLA vers les Experience Level Agreements (XLA) — avec environ 70 % des organisations prévoyant l'adoption des XLA d'ici 2026 selon le rapport State of XLA 2025 du XLA Institute [23] — et l'analyse juridique majeure de Mayer Brown recommandant des métriques basées sur les résultats pour les contrats d'IA agentique [24], ASA spécifie la précision, la ponctualité, la pertinence et l'achèvement des tâches plutôt que des pourcentages de disponibilité.
Un SLA qui ne peut être vérifié est une promesse. Un SLA avec vérification intégrée est un contrat. Les accords ASA incluent le mécanisme de vérification, la logique d'application et les garanties d'intégrité de l'évaluateur comme composants structurels, et non comme dépendances externes. L'accord spécifie ce que signifie « bon » en termes de notation ; l'API Verification évalue selon ces termes exacts à l'aide d'évaluateurs indépendants dont l'intégrité est maintenue par la rotation, les tâches canari et le consensus multi-évaluateurs (Section 6.3) ; la couche de séquestre agit en conséquence. Pas de réclamations manuelles, pas de délais de 30 jours, pas de dossiers de preuve de violation. Notons que l'application dépend de l'exactitude de l'évaluateur — ASA réduit cette dépendance sans l'éliminer, grâce à ses mécanismes d'intégrité.
Aucun système de qualité efficace n'utilise une seule métrique. L'ISO 25010 définit 9 caractéristiques de qualité avec 38+ sous-caractéristiques [25]. SonarQube note selon la fiabilité, la sécurité et la maintenabilité [20]. DeepSource utilise 5 dimensions [26]. Même les évaluations de codage simples de Codility utilisent des métriques doubles (exactitude et extensibilité) [27]. ASA exige des critères de qualité multidimensionnels avec des métriques équilibrées qui résistent au détournement par cible unique.
La performance des agents présente une variance élevée d'une exécution à l'autre. La suite d'évaluation MAESTRO a constaté que les exécutions de systèmes multi-agents peuvent être « structurellement stables mais temporellement variables » [28]. MAS-ProVe a démontré que la vérification de processus « n'améliore pas systématiquement les performances et présente une variance élevée » [29]. ASA prend en charge les garanties probabilistes — un accord peut spécifier « pass@5 ≥ 95 % » (au moins une tentative sur cinq atteint le seuil) ou « p90 accuracy ≥ 85 % » (la précision au 90e percentile sur l'ensemble des livraisons dépasse le seuil) plutôt que d'exiger la perfection déterministe à chaque transaction.
La confiance devrait moduler l'intensité de la vérification, et non la remplacer. En suivant le modèle adaptatif de confiance de PayCrow (délais de 15 minutes pour les scores de 75+, plafonds de 5 $ pour les scores inférieurs à 45) [17] et le système étagé de vendeurs de Fiverr (délai de 7 jours pour les Top Rated contre 14 jours pour les vendeurs standard) [30], ASA permet aux accords de spécifier une profondeur de vérification inversement proportionnelle à la réputation du fournisseur. Les fournisseurs à haute réputation peuvent recevoir une vérification structurelle légère ; les fournisseurs inconnus reçoivent une évaluation sémantique complète.
L'évaluateur doit être indépendant du client et du fournisseur. Le modèle tripartite d'ERC-8183 (Client/Fournisseur/Évaluateur) impose cette séparation de manière architecturale [2]. ASA adopte ce schéma : l'entité qui demande le travail et l'entité qui réalise le travail ne peuvent pas être l'entité qui juge le travail. La sélection, la qualification et la rotation des évaluateurs sont des préoccupations au niveau du protocole.
La section 3.6 établit que l'évaluateur doit être indépendant, mais ne spécifie pas comment les parties conviennent d'un évaluateur. C'est une lacune critique : la sélection de l'évaluateur détermine l'ensemble du résultat d'évaluation de la qualité. Si le client sélectionne l'évaluateur, il peut choisir un juge sévère pour éviter le paiement. Si le fournisseur le sélectionne, il peut choisir un juge indulgent. L'accord mutuel risque le blocage.
ASA spécifie trois mécanismes de sélection des évaluateurs, configurables par accord :
Attribution aléatoire depuis un pool qualifié (par défaut). Un registre d'évaluateurs qualifiés maintient un pool d'évaluateurs avec des historiques vérifiés. Lorsqu'un accord est activé, un évaluateur est attribué aléatoirement depuis le sous-ensemble d'évaluateurs qualifiés pour le type de service. La qualification requiert : (a) un nombre minimum d'évaluations antérieures (par défaut : 50), (b) un taux de réussite aux tâches canari supérieur au seuil (par défaut : 90 %), et (c) un score de calibrage inter-évaluateurs dans l'écart acceptable (Section 6.3). L'attribution aléatoire empêche l'une ou l'autre partie de manipuler la sélection de l'évaluateur.
Accord mutuel avec repli aléatoire. Les deux parties proposent des évaluateurs du pool qualifié. S'ils s'accordent sur un choix commun, cet évaluateur est assigné. S'ils ne parviennent pas à s'accorder dans un nombre configurable de tours (par défaut : 3), le système revient à l'attribution aléatoire. Ceci préserve l'autonomie des parties tout en évitant le blocage.
Marché des évaluateurs. Les évaluateurs sont en compétition sur la base de leur historique, de leur expertise dans le domaine et de leur prix. L'accord spécifie les critères de sélection de l'évaluateur (historique minimum, domaine, coût maximum), et le système sélectionne l'évaluateur disponible le mieux adapté. Ce mécanisme convient aux domaines spécialisés où l'expertise de l'évaluateur affecte significativement la qualité de l'évaluation.
Les trois mécanismes imposent la contrainte d'indépendance de la section 3.6 : l'évaluateur sélectionné ne peut partager ni l'identité, ni l'affiliation organisationnelle, ni la lignée de chaîne CoC avec l'une ou l'autre partie.
ASA fonctionne avec n'importe quel système d'identité. L'identité d'un agent dans un accord peut être :
Le protocole spécifie un champ identity avec un discriminateur scheme, et non un fournisseur d'identité obligatoire.
Un accord ASA est un document JSON avec la structure de premier niveau suivante :
{
"asa_version": "1.0.0",
"agreement_id": "asa-2026-03-26-a1b2c3d4",
"created_at": "2026-03-26T14:30:00Z",
"expires_at": "2026-03-27T14:30:00Z",
"status": "active",
"parties": {
"client": {
"identity": { "scheme": "coc", "value": "sha256:abc123..." },
"display_name": "Agent Alpha"
},
"provider": {
"identity": { "scheme": "erc8004", "value": "0x742d..." },
"display_name": "Agent Beta"
},
"evaluator": {
"identity": { "scheme": "api_key", "value": "eval-key-789" },
"type": "agent_as_judge",
"config": { "model": "claude-sonnet-4-6", "rubric_id": "research-v2" }
}
},
"service": {
"type": "research_synthesis",
"description": "Summarize recent literature on federated learning privacy guarantees",
"deliverable_format": "markdown",
"constraints": {
"max_tokens": 50000,
"max_duration_seconds": 3600,
"max_cost_usd": 5.00
}
},
"quality_criteria": {
"dimensions": [
{
"name": "accuracy",
"weight": 0.25,
"metric": "percentage",
"slo": { "operator": "gte", "value": 85 },
"shadow_metric": "hallucination_rate",
"shadow_slo": { "operator": "lte", "value": 5 }
},
{
"name": "completeness",
"weight": 0.20,
"metric": "percentage",
"slo": { "operator": "gte", "value": 80 }
},
{
"name": "relevance",
"weight": 0.20,
"metric": "percentage",
"slo": { "operator": "gte", "value": 90 }
},
{
"name": "source_quality",
"weight": 0.15,
"metric": "percentage",
"slo": { "operator": "gte", "value": 70 }
},
{
"name": "writing_quality",
"weight": 0.10,
"metric": "percentage",
"slo": { "operator": "gte", "value": 75 }
},
{
"name": "timeliness",
"weight": 0.10,
"metric": "boolean",
"slo": { "operator": "eq", "value": true }
}
],
"composite_threshold": 75,
"composite_method": "weighted_average",
"guarantee_type": "deterministic"
},
"verification": {
"strategy": "optimistic",
"challenge_window_seconds": 7200,
"evaluator_timeout_seconds": 600,
"canary_tasks": {
"enabled": true,
"frequency": "1_per_5_deliveries",
"failure_action": "flag_and_continue"
}
},
"escrow": {
"enabled": true,
"binding": {
"type": "erc8183",
"contract_address": "0xdef456...",
"chain": "base"
},
"payment": {
"amount": "5.00",
"currency": "USDC",
"graduated_release": {
"enabled": true,
"tiers": [
{ "composite_score_gte": 90, "release_percent": 100 },
{ "composite_score_gte": 75, "release_percent": 85 },
{ "composite_score_gte": 60, "release_percent": 50 },
{ "composite_score_lt": 60, "release_percent": 0 }
]
}
},
"dead_mans_switch": {
"client_timeout_seconds": 86400,
"provider_timeout_seconds": 86400,
"evaluator_timeout_seconds": 3600,
"timeout_action": "hold_for_backup_evaluator"
}
},
"dispute": {
"protocol": "ajp",
"auto_file_on": "verification_failure_below_threshold",
"threshold": 60,
"evidence_includes": ["agreement", "deliverable_hash", "verification_result"]
},
"signatures": {
"client": { "scheme": "ed25519", "value": "sig_abc..." },
"provider": { "scheme": "ed25519", "value": "sig_def..." }
}
}Les accords progressent à travers une machine à états comprenant six états :
PROPOSED → NEGOTIATING → ACTIVE → DELIVERED → VERIFIED → CLOSED
│ │
└──── REJECTED ├── DISPUTED
└── EXPIREDPROPOSED : Le Client crée un document d'accord et l'envoie au Fournisseur. Le document n'est pas signé.
NEGOTIATING : Le Fournisseur examine et peut formuler une contre-proposition en modifiant les critères de qualité, les conditions de paiement ou le calendrier. Cela engage le protocole de négociation (Section 7). Le nombre maximum de tours de négociation et le délai sont configurables.
ACTIVE : Les deux parties signent l'accord. Si le séquestre est activé, le Client approvisionne le séquestre. Le Fournisseur commence le travail.
DELIVERED : Le Fournisseur soumet un livrable avec un hash de contenu. Le compteur de vérification démarre.
VERIFIED : L'Évaluateur renvoie un résultat de vérification. En fonction du résultat et de la configuration du séquestre :
verification.strategy est optimistic, le résultat entre dans la fenêtre de contestation avant l'applicationCLOSED : L'accord est terminé. L'état final est enregistré avec les résultats de vérification, les montants de paiement et les horodatages. Cet enregistrement est disponible pour la notation de réputation ARP.
DISPUTED : L'une des parties conteste le résultat de vérification pendant la fenêtre de contestation. Le litige est déposé via AJP avec le document d'accord, le hash du livrable et le résultat de vérification comme preuves.
EXPIRED : Délai déclenché par l'interrupteur automatique. Le Fournisseur ou l'évaluateur n'a pas agi dans les délais configurés.
POST /agreements Créer un nouvel accord (PROPOSED)
GET /agreements/{id} Récupérer un accord par identifiant
PATCH /agreements/{id}/negotiate Soumettre une contre-proposition (NEGOTIATING)
POST /agreements/{id}/sign Signer l'accord (→ ACTIVE)
POST /agreements/{id}/deliver Soumettre un livrable (→ DELIVERED)
POST /agreements/{id}/verify Déclencher la vérification (→ VERIFIED)
POST /agreements/{id}/challenge Contester le résultat de vérification (→ DISPUTED)
GET /agreements/{id}/status Obtenir l'état actuel et les métadonnées
GET /agreements?party={id} Lister les accords d'une partie
GET /templates Lister les modèles d'accord disponibles
GET /templates/{type} Obtenir le modèle pour un type de serviceASA définit des modèles de départ pour les types courants de services entre agents :
| Modèle | Dimensions de qualité | SLO typiques |
|---|---|---|
research | précision, exhaustivité, pertinence, sources, rédaction | précision ≥ 85 %, sources ≥ 5 |
code_generation | exactitude, performance, sécurité, maintenabilité, couverture de tests | exactitude ≥ 95 %, tests réussis |
data_analysis | précision, méthodologie, visualisation, qualité des conclusions | précision ≥ 90 % |
translation | précision, fluidité, adéquation culturelle, terminologie | précision ≥ 90 %, fluidité ≥ 85 % |
review | rigueur, précision, exploitabilité, ton | rigueur ≥ 80 % |
general | précision, exhaustivité, pertinence, ponctualité | précision ≥ 80 % |
Les modèles sont paramétrables — les agents sélectionnent un modèle et ajustent les valeurs de SLO, les pondérations et la stratégie de vérification au cours de la négociation. Cela suit l'approche de modèles de l'Accord Project (plus de 40 modèles de contrats juridiques avec logique paramétrable) [31] et répond à la conclusion de la recherche selon laquelle les stratégies centrées sur le domaine surpassent la négociation ouverte [32].
ASA utilise le versionnage sémantique (SemVer) pour le champ asa_version. Règles de compatibilité :
Le champ asa_version dans le document d'accord fait autorité. Les implémentations DOIVENT valider les accords entrants par rapport au schéma de la version déclarée, et non par rapport à la version actuelle de l'implémentation.
La création, la maintenance et la validation des modèles sont essentielles à l'adoption d'ASA — un modèle malveillant avec des conditions par défaut exploitantes pourrait être largement adopté avant que les conditions ne soient remarquées. ASA délègue la gouvernance des modèles au cadre de gouvernance du Trust Architecture Council (TAC), qui spécifie : (a) la révision des soumissions de modèles par un comité d'évaluateurs qualifiés, (b) la divulgation obligatoire des conditions non standard (conditions qui dévient de plus de 25 % des valeurs par défaut du marché), et (c) le versionnage des modèles aligné sur le versionnage du schéma ASA. Les modèles contribués par la communauté suivent le même processus de révision que les modifications du protocole. Tant que la gouvernance TAC n'est pas opérationnelle, les modèles sont maintenus par les mainteneurs du protocole avec des périodes de révision publique.
L'API Verification fonctionne indépendamment de l'API Agreements. N'importe quel agent peut demander la vérification de la qualité de n'importe quel livrable à tout moment, avec ou sans accord directeur.
{
"verification_id": "ver-2026-03-26-x1y2z3",
"agreement_id": "asa-2026-03-26-a1b2c3d4", // optionnel
"deliverable": {
"content_hash": "sha256:fedcba...",
"content_url": "https://agent-beta.example/deliverables/abc123",
"format": "markdown",
"size_bytes": 24576
},
"original_request": {
"description": "Summarize recent literature on federated learning privacy guarantees",
"constraints": { "max_tokens": 50000 }
},
"quality_criteria": {
// Si agreement_id fourni : hérité de l'accord
// Si autonome : spécifié ici avec le même schéma que quality_criteria de l'accord
},
"verification_config": {
"depth": "semantic", // "structural", "semantic" ou "composite"
"evaluator_type": "agent_as_judge",
"evaluator_config": {
"model": "claude-sonnet-4-6",
"rubric_id": "research-v2",
"evidence_collection": true,
"spot_check_claims": 3
}
}
}{
"verification_id": "ver-2026-03-26-x1y2z3",
"agreement_id": "asa-2026-03-26-a1b2c3d4",
"timestamp": "2026-03-26T15:45:00Z",
"evaluator": {
"identity": { "scheme": "api_key", "value": "eval-key-789" },
"type": "agent_as_judge",
"model": "claude-sonnet-4-6"
},
"dimensions": [
{
"name": "accuracy",
"score": 88,
"slo_target": 85,
"slo_met": true,
"evidence": "Vérification ponctuelle de 3 affirmations par rapport au matériel source. 2/3 entièrement étayées, 1/3 partiellement étayée avec une légère imprécision dans l'attribution de la date.",
"shadow_metric": {
"name": "hallucination_rate",
"value": 3.2,
"slo_target": 5,
"slo_met": true
}
},
{
"name": "completeness",
"score": 82,
"slo_target": 80,
"slo_met": true,
"evidence": "Couvre 8 des 10 articles majeurs de 2025-2026. Manquants : Wang et al. (NeurIPS 2025) et Patel et al. (ICML 2026)."
},
{
"name": "relevance",
"score": 94,
"slo_target": 90,
"slo_met": true,
"evidence": "Toutes les sections traitent directement du sujet spécifié. Aucun contenu tangentiel."
},
{
"name": "source_quality",
"score": 78,
"slo_target": 70,
"slo_met": true,
"evidence": "12 sources citées. 9 évaluées par des pairs, 2 préprints, 1 article de blog. Diversité des sources adéquate."
},
{
"name": "writing_quality",
"score": 81,
"slo_target": 75,
"slo_met": true,
"evidence": "Structure claire, profondeur technique appropriée. Problèmes mineurs : deux phrases à rallonge dans la Section 3."
},
{
"name": "timeliness",
"score": 100,
"slo_target": true,
"slo_met": true,
"evidence": "Livré 847 secondes avant l'échéance."
}
],
"composite": {
"score": 86.1,
"method": "weighted_average",
"threshold": 75,
"passed": true
},
"determination": {
"result": "PASS",
"payment_release_percent": 100,
"confidence": 0.87,
"notes": "Tous les SLO satisfaits. Score composite de 86,1 dépassant le seuil de 75."
},
"evidence_trail": {
"deliverable_hash": "sha256:fedcba...",
"evaluation_hash": "sha256:789xyz...",
"evaluation_duration_ms": 45230,
"evaluation_cost_usd": 0.12
}
}ASA prend en charge trois niveaux de profondeur de vérification, chacun avec des coûts, des latences et des capacités d'évaluation différents :
Vérification structurelle : vérifie la conformité de format — validation de schéma JSON, présence des champs requis, contraintes de taille, correspondance du format du livrable. Analogue à la validation de statut HTTP + JSON de PayCrow [17]. Coût : quasi nul. Latence : millisecondes. Limitations : ne peut pas évaluer la qualité du contenu.
Vérification sémantique : évalue la qualité du contenu à l'aide d'un évaluateur Agent-as-a-Judge. L'agent évaluateur reçoit la demande initiale, le livrable et la grille de qualité, puis note chaque dimension avec preuves à l'appui. Cela suit le paradigme Agent-as-a-Judge introduit par Zhuge et al. (2024) [65] et examiné par You et al. (2026) [4], qui atteint environ 90 % de concordance avec les évaluations d'experts humains dans les tâches de génération de code et réduit le coût de l'évaluation d'environ 97 % par rapport à la révision humaine. La concordance chute à 60-68 % dans les domaines spécialisés (Section 6.2), rendant le calibrage spécifique au domaine important pour les tâches hors code. Coût : 0,03 à 31 $ selon la taille du livrable, le modèle d'évaluateur et la complexité de la vérification (évaluations typiques de recherche/code : 0,03 à 0,50 $ ; évaluations complexes multi-étapes avec utilisation intensive d'outils : jusqu'à 31 $). Latence : 10 à 120 secondes.
Vérification composite : combine l'évaluation structurelle et sémantique avec des vérifications optionnelles supplémentaires : résultats des tâches canari, validation de références croisées par rapport à des sources connues, vérifications de cohérence sur plusieurs livraisons, et vérification par méthodes formelles pour les résultats de code. C'est le niveau le plus approfondi mais le plus coûteux, adapté aux accords de grande valeur ou aux scénarios de faible confiance.
Lorsque l'API Verification est appelée sans accord (mode autonome), elle applique des dimensions de qualité par défaut basées sur le type de livrable :
| Type de livrable | Dimensions par défaut | Pondérations par défaut |
|---|---|---|
| text/research | précision, exhaustivité, pertinence, sources, rédaction | 25/20/20/15/20 |
| text/analysis | précision, méthodologie, profondeur, clarté, exploitabilité | 25/20/20/15/20 |
| code | exactitude, performance, sécurité, maintenabilité, documentation | 30/20/20/15/15 |
| data | précision, exhaustivité, cohérence, conformité de format, métadonnées | 25/25/20/15/15 |
| translation | précision, fluidité, terminologie, adéquation culturelle, exhaustivité | 25/25/20/15/15 |
| general | précision, exhaustivité, pertinence, clarté, ponctualité | 25/20/20/20/15 |
Ces valeurs par défaut dérivent de l'expérience opérationnelle d'AB Support : le système de notation AQ à six dimensions utilisé dans les opérations de la flotte (étendue, profondeur, précision, sources, références croisées, qualité rédactionnelle) généralisé aux catégories de services observées dans le commerce entre agents [12].
Le mode autonome de l'API Verification abaisse la barrière à l'adoption mais crée un risque que l'adoption se concentre sur la vérification gratuite tandis que l'API Agreements — l'innovation véritable — reste inutilisée. Le cadre décisionnel suivant guide le choix entre chaque mode :
Utiliser la vérification autonome lorsque :
Utiliser les accords complets lorsque :
Parcours d'adoption graduée : les nouveaux écosystèmes d'agents peuvent commencer par la vérification autonome pour construire l'infrastructure d'évaluation et les historiques des évaluateurs, puis migrer vers les accords complets à mesure que les volumes de transactions et les exigences de confiance augmentent. Ceci reflète la progression des accords informels de bonne foi vers les contrats formels dans le commerce humain.
Le défi central de la vérification de la qualité des agents est le fossé entre l'évaluation structurelle et sémantique. La vérification structurelle — le résultat est-il conforme au format attendu ? — est trivialement automatisable. La vérification sémantique — le résultat est-il exact, pertinent et utile ? — est elle-même un problème d'IA, créant une dépendance récursive.
Le paysage de la recherche révèle une hiérarchie claire d'approches de vérification :
| Approche | Taux de concordance humaine | Coût par évaluation | Latence | Source |
|---|---|---|---|---|
| Révision par expert humain | ~80 % inter-évaluateurs | 50-1 300 $ | Heures-jours | Standard du secteur |
| Agent-as-a-Judge | ~90 % avec humains (code) ; 60-68 % (spécialisé) | 0,03-31 $ | Minutes | Zhuge et al., 2024 [65] ; You et al., 2026 [4] |
| LLM-as-a-Judge | ~80 % avec humains | 0,01-5 $ | Secondes-minutes | Zheng et al., 2023 [33] |
| Modèle de récompense | Proxy appris | 0,001-0,01 $ | Millisecondes | RLHF/RLAIF [34] |
| Validation de schéma | S/O (structurelle) | ~0 $ | Millisecondes | PayCrow [17] |
Agent-as-a-Judge atteint une concordance plus élevée avec les experts humains (~90 % en génération de code [65]) que le LLM-as-a-Judge standard (~80 % [33]) car il peut utiliser des outils, accéder à la mémoire et effectuer un raisonnement multi-étapes — exécutant du code pour vérifier des affirmations, consultant des sources et testant des cas limites plutôt que de se fier uniquement à la plausibilité linguistique [4][65]. Cependant, ce chiffre de 90 % a été démontré spécifiquement pour l'évaluation de la génération de code ; la généralisation inter-domaines reste un domaine de recherche actif, la Section 6.2 documentant une concordance de 60-68 % dans les domaines spécialisés [36]. ASA adopte Agent-as-a-Judge comme mécanisme principal de vérification sémantique tout en reconnaissant cet écart entre domaines et en prenant en charge des configurations d'évaluateurs spécifiques au domaine pour l'atténuer.
L'évaluation basée sur les LLM présente des biais documentés dont ASA doit tenir compte :
Biais de position : inverser l'ordre des réponses modifie le jugement. Atténuation : les évaluateurs reçoivent les livrables sans contexte positionnel (évaluation ponctuelle sur un seul élément, et non comparaison par paires).
Biais de verbosité : les réponses plus longues sont mieux notées indépendamment de la qualité. Atténuation : les dimensions de qualité séparent explicitement l'exhaustivité de la concision ; le nombre de mots est une métrique fantôme lorsque l'exhaustivité est une cible.
Biais d'auto-valorisation : les modèles notent leurs propres résultats plus favorablement. Atténuation : le modèle évaluateur doit différer du modèle fournisseur, ou l'évaluation doit utiliser un modèle juge ajusté (par ex., PROMETHEUS) [35].
Fossé d'expertise dans le domaine : dans les domaines experts (médecine, droit, finance), la concordance du juge LLM avec les humains chute à 60-68 % [36]. Atténuation : pour les domaines spécialisés, ASA prend en charge des agents évaluateurs spécifiques au domaine ou une évaluation hybride (Agent-as-a-Judge + validateurs formels spécifiques au domaine).
Qui évalue l'évaluateur ? C'est le défi du « quis custodiet ipsos custodes » [37]. ASA y répond par trois mécanismes :
Rotation des évaluateurs : les accords peuvent spécifier des politiques de rotation des évaluateurs — aucun évaluateur unique n'évalue plus de N livraisons consécutives du même fournisseur. Cela prévient la collusion évaluateur-fournisseur.
Tâches canari : des sous-tâches à réponse connue intégrées dans le travail réel vérifient la précision de l'évaluateur. Si un évaluateur note systématiquement les livrables notoirement mauvais comme réussis, ou les livrables notoirement bons comme échoués, le score de fiabilité de l'évaluateur diminue. Adapté de la technique de référence (gold standard) d'Amazon Mechanical Turk [21].
Consensus multi-évaluateurs : pour les accords de grande valeur, plusieurs évaluateurs notent indépendamment et le résultat est déterminé par vote majoritaire ou score médian. Cela suit l'approche PoLL (Plurality of Language Models), qui réduit le biais d'un juge unique [33].
Empruntant le concept de porte de qualité de SonarQube [20], ASA permet aux accords de définir des portes binaires réussite/échec en complément des dimensions notées :
{
"quality_gates": [
{ "condition": "no_critical_security_vulnerabilities", "type": "boolean" },
{ "condition": "all_tests_pass", "type": "boolean" },
{ "condition": "accuracy_gte_80", "type": "threshold" },
{ "condition": "composite_gte_75", "type": "threshold" }
],
"gate_logic": "all_must_pass"
}Un livrable qui échoue à n'importe quelle porte de qualité est automatiquement rejeté, indépendamment des scores par dimension. Les portes fournissent des limites de sécurité absolues ; les scores par dimension fournissent une évaluation graduée de la qualité à l'intérieur de ces limites.
La recherche sur la négociation LLM révèle plusieurs tendances que le protocole de négociation d'ASA doit adresser :
| Constat | Source | Implication pour le protocole |
|---|---|---|
| Les LLM s'ancrent aux extrêmes (plancher du vendeur) | Shah et al., NeurIPS 2025 [10] | Fournir des références aux taux du marché comme point d'ancrage |
| La chaleur surpasse la dominance | Vaccaro et al., 2025 [8] | Les formats structurés empêchent la manipulation émotionnelle |
| L'injection de prompt comme tactique de négociation | Vaccaro et al., 2025 [8] | Champs de message structurés, pas de texte libre |
| Les agents plus faibles exploités de 2-14 % | Zhu et al., 2025 [9] | Contraintes d'équité au niveau du protocole |
| La spécialisation dans le domaine surpasse la modélisation de l'adversaire | ANAC 2024 [32] | Négociation basée sur des modèles avec données de marché |
| Taux d'accord automatique de 95 % dans les domaines structurés | NEC, 2025 [38] | Les modèles permettent une forte automatisation |
| Agents trompés sur leurs propres coûts | Kirshner et al., 2026 [39] | Coûts des ressources visibles par les deux parties |
Client Fournisseur
│ │
├── PROPOSE (modèle + paramètres) ───►│
│ │
│◄── COUNTER (paramètres modifiés) ────┤ (jusqu'à max_rounds)
│ │
├── ACCEPT ─────────────────────►│
│ ou │
├── COUNTER (paramètres modifiés) ──►│
│ ou │
├── REJECT ─────────────────────►│
│ │Chaque message de négociation est un document JSON structuré, et non du texte libre :
{
"negotiation_id": "neg-abc123",
"round": 2,
"action": "counter",
"proposed_changes": {
"quality_criteria.dimensions[0].slo.value": 80, // était 85
"service.constraints.max_duration_seconds": 7200, // était 3600
"escrow.payment.amount": "6.00" // était 5.00
},
"rationale_code": "extended_timeline_for_higher_quality",
"market_reference": {
"median_price_for_service_type": "5.50",
"source": "arp_market_data"
}
}ASA impose des garanties d'équité au niveau du protocole pour prévenir l'exploitation des agents plus faibles :
Fourchettes de prix : les prix des accords doivent se situer dans des fourchettes configurables par rapport aux taux du marché (par défaut : 0,5x-3,0x de la médiane rapportée par ARP pour le type de service). Les accords en dehors de ces fourchettes sont signalés mais non bloqués — le signal est visible par les deux parties et enregistré dans les métadonnées de l'accord.
Limites d'asymétrie : aucun tour de négociation unique ne peut modifier les conditions de plus d'un pourcentage configurable (par défaut : 25 % de variation par tour) sur n'importe quelle dimension, empêchant les basculements exploitants soudains.
Coûts transparents : les contraintes de ressources du fournisseur (budget de jetons, coût de calcul, limites d'appels API) sont visibles dans l'accord. Suivant le cadre Agent Contracts (Ye & Tan, 2026), les budgets de ressources délégués ne peuvent dépasser l'allocation du parent et sont vérifiables cryptographiquement [40].
Nombre maximum de tours : la négociation est limitée à un nombre maximum configurable de tours (par défaut : 5). Si aucun accord n'est atteint, la session se termine avec le statut REJECTED. Cela prévient les boucles de négociation indéfinies.
ASA n'implémente pas son propre système de paiement. À la place, il définit une interface de liaison au séquestre qui connecte les accords aux systèmes de paiement externes :
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ API │────►│ API │────►│ Liaison │
│ Agreements │ │ Verification │ │ séquestre │
└──────────────┘ └──────────────┘ └──────┬───────┘
│
┌───────────────────────┼───────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ERC-8183 │ │ x402 │ │ Custom │
│ Escrow │ │ Pay │ │ HTTP │
└─────────┘ └─────────┘ └─────────┘Contrairement au modèle binaire réussite/échec d'ERC-8183 [2], ASA prend en charge le paiement gradué basé sur les scores de qualité :
| Score composite | Libération du paiement | Justification |
|---|---|---|
| ≥ 90 | 100 % | Dépasse les attentes |
| 75-89 | 85 % | Atteint le seuil de l'accord |
| 60-74 | 50 % | En dessous du seuil mais exploitable |
| < 60 | 0 % + option de litige | En dessous de la qualité minimale |
Cela répond à une limitation fondamentale des systèmes de séquestre existants. Un résumé de recherche qui obtient 72 % — en dessous du seuil convenu mais contenant un contenu significativement utile — ne devrait pas entraîner un paiement nul. La libération graduée crée des incitations appropriées : les fournisseurs sont récompensés proportionnellement pour une qualité partielle, et les clients reçoivent une compensation partielle pour une livraison partielle.
Risque d'optimisation du seuil. Les paliers gradués introduisent un vecteur de détournement : la stratégie optimale d'un fournisseur rationnel est de livrer une qualité juste au-dessus du palier de paiement le plus proche (par ex., obtenir 76 plutôt que 88, puisque les deux libèrent 85 % mais le premier coûte moins d'effort). ASA atténue ceci par trois mécanismes configurables :
(composite_score / 100) * montant. Pas de seuils, pas de cibles d'optimisation. Les accords peuvent activer ceci via "graduated_release": { "mode": "continuous" }.Les paliers gradués par défaut restent disponibles pour leur simplicité, mais les accords impliquant des transactions répétées avec le même fournisseur DEVRAIENT préférer les fonctions de paiement continues pour éviter les incitations à l'optimisation du seuil.
Impact sur le taux de litiges. Le paiement gradué devrait réduire les taux de litiges par rapport au modèle binaire réussite/échec. Dans les opérations de la flotte d'AB Support, environ 15-20 % des livrables de Bravo obtiennent des scores dans la fourchette 60-74 (en dessous du seuil idéal mais contenant un contenu significativement utile). Avec le modèle binaire réussite/échec, tous déclencheraient un rejet et un potentiel litige. Avec la libération graduée, le fournisseur reçoit 50 % du paiement et le client reçoit un travail exploitable (bien qu'imparfait) — les deux parties sont mieux loties que dans un scénario de litige. Bien que ces chiffres à l'échelle de la flotte ne soient pas statistiquement significatifs pour des affirmations générales, ils suggèrent que le paiement gradué peut éliminer les litiges pour la fraction substantielle de livrables qui se situent dans la zone « en dessous du seuil mais exploitable ».
Les agents peuvent planter, perdre la connectivité ou être mis hors service. ASA met en œuvre des mécanismes de sécurité basés sur des délais, adaptés du modèle de libération automatique à 14 jours d'Upwork [22] :
Délai du client : si le client n'approvisionne pas le séquestre dans le délai configuré après l'activation de l'accord, l'accord passe à l'état EXPIRED.
Délai du fournisseur : si le fournisseur ne livre pas dans le délai configuré, les fonds en séquestre sont retournés au client.
Délai de l'évaluateur : si l'évaluateur ne renvoie pas de résultat de vérification dans le délai configuré, l'action par défaut est hold_for_backup_evaluator — le système sélectionne un évaluateur alternatif du pool qualifié (Section 3.6.1). D'autres actions de délai sont configurables par accord : (a) split_50_50 — aucune partie ne bénéficie de la défaillance de l'évaluateur, (b) return_to_client — le client conserve les fonds lorsque la qualité n'est pas vérifiée, ou (c) release_to_provider — disponible mais NON recommandé par défaut car il crée un aléa moral où les fournisseurs bénéficient de la défaillance de l'évaluateur, permettant un vecteur de collusion où l'évaluateur expire délibérément et partage le produit avec le fournisseur.
Délai de contestation : si aucune partie ne conteste un résultat de vérification dans la fenêtre de contestation, le résultat est finalisé et le paiement est libéré ou remboursé en conséquence.
ASA utilise les chaînes de provenance CoC à trois fins :
Vérification d'identité : le hash de chaîne CoC d'un agent sert d'identité dans les accords, reliant la prestation de service à un historique opérationnel vérifiable [11].
Âge opérationnel comme signal de confiance : la longueur de la chaîne CoC indique depuis combien de temps un agent fonctionne en continu. Les chaînes plus longues impliquent un investissement plus important dans le maintien de la provenance, ce qui sert de signal honnête dans la négociation d'accords — suivant le cadre de signalisation coûteuse biologique formalisé dans ARP v2 [12].
Ancrage de preuves : les résultats de vérification peuvent être ajoutés à la chaîne CoC, créant un enregistrement immuable des évaluations de qualité. Cela fournit des preuves forensiques pour la résolution des litiges AJP et des données longitudinales pour la notation de réputation ARP.
ASA et ARP forment une boucle de rétroaction bidirectionnelle :
ARP → ASA (la réputation informe les accords) :
ASA → ARP (la vérification alimente la réputation) :
ASA se connecte à AJP en deux points :
Dépôt automatique de litiges : lorsque les scores de vérification tombent en dessous du seuil de litige de l'accord ET que la fenêtre de contestation expire sans résolution, ASA dépose automatiquement un litige AJP. Le dossier de litige comprend le document d'accord, le hash du contenu du livrable, le résultat de vérification avec la piste de preuves, et les identités des deux parties.
Preuves forensiques : le moteur forensique d'AJP peut demander l'intégralité de la piste de vérification ASA — chaque score par dimension, chaque preuve de l'évaluateur, chaque résultat de tâche canari — comme preuve pour l'enquête.
Un accord ASA entre le Client C et le Fournisseur P est un jeu coopératif où les deux parties bénéficient de la réalisation réussie mais ont des incitations divergentes concernant le niveau de qualité et le prix.
Utilité du client : U_C = V(qualité) - prix - coût_de_vérification
Où V(qualité) est la valeur que le client tire du livrable, croissante avec la qualité.
Utilité du fournisseur : U_P = prix - coût(qualité) - risque_de_garantie
Où coût(qualité) augmente avec le niveau de qualité, et risque_de_garantie est la perte attendue due à la réduction du séquestre.
Solution de négociation de Nash : l'accord optimal maximise le produit du surplus des deux parties par rapport à leur gain de désaccord (BATNA — meilleure alternative à un accord négocié) [41] :
max (U_C - d_C)(U_P - d_P)Où d_C est le BATNA du client (trouver un autre fournisseur ou faire le travail lui-même) et d_P est le BATNA du fournisseur (trouver un autre client ou rester inactif).
La conception appliquée par le protocole d'ASA aligne les incitations grâce à trois mécanismes :
Enjeux proportionnels : la libération graduée du paiement garantit que les améliorations de qualité augmentent toujours les revenus du fournisseur. Un fournisseur obtenant 88 % reçoit plus qu'un fournisseur obtenant 76 %. Cela élimine le seuil binaire où un score de 74 % et un score de 10 % produisent un résultat identique de zéro paiement.
Effets de réputation : parce que les résultats de vérification ASA alimentent l'ARP, chaque accord a des conséquences réputationnelles au-delà de la transaction immédiate. Un fournisseur qui livre systématiquement une qualité de 60 % verra ses scores de réputation décliner, réduisant son pouvoir de négociation futur. Cette dynamique convertit les jeux à un coup en jeux itérés avec des équilibres coopératifs.
Caution et pénalités : les mécanismes de mise en jeu/réduction (suivant le cadre d'Outlier Ventures [42]) créent une responsabilité financière directe. Le coût de la triche — livrer une qualité médiocre et absorber la réduction du séquestre — doit dépasser le coût d'exécution correcte du travail. Pour que cette inégalité soit vérifiée, la garantie doit être proportionnelle à la valeur de l'accord, et non symbolique (évitant le problème du crédit cloud).
Toutes les paires d'agents ne peuvent pas former des accords mutuellement bénéfiques. Les accords stables nécessitent :
ASA ne prétend pas résoudre tous les défis de théorie des jeux dans le commerce entre agents. Plusieurs problèmes ouverts subsistent :
Résistance à la collusion : si l'évaluateur s'entend avec l'une des parties, le résultat de vérification est corrompu. Le consensus multi-évaluateurs réduit mais n'élimine pas ce risque. Une preuve formelle de conception de mécanisme de résistance à la collusion dépasse le cadre de ce protocole.
Attaques Sybil sur la réputation : un agent pourrait créer plusieurs identités pour réinitialiser une mauvaise réputation. ASA hérite des propriétés de résistance Sybil de son système d'identité sous-jacent — les chaînes CoC rendent les attaques Sybil coûteuses (maintenir des chaînes parallèles), mais les identités basées sur clés API sont trivialement sybilables.
Manipulation des dimensions de qualité : même avec une notation multidimensionnelle, un agent suffisamment capable pourrait apprendre à produire des résultats qui obtiennent de bonnes notes sur les dimensions mesurées tout en étant sous-optimaux sur les dimensions non mesurées. Le mécanisme de métrique fantôme détecte les cas simples, mais le détournement adversarial de la qualité à la frontière reste un problème de recherche ouvert.
| Système | Spécifique aux agents | Lisible par les machines | Application | Multidimensionnel | Statut |
|---|---|---|---|---|---|
| ITIL 4 SLM [18] | Non | Non | Manuelle | Non | Mature, infrastructure |
| WSLA (IBM, 2003) [43] | Non | XML | Surveillance | Limité | Obsolète |
| WS-Agreement (OGF, 2007) [44] | Non | XML | Modèles | Limité | Obsolète |
| SLAC (Uriarte et al., 2015) [45] | Non | DSL formel | Dynamique | Oui | Académique |
| AgentSLA DSL (2025) [1] | Oui | JSON | Aucune | Oui (40+ métriques) | Académique, pré-production |
| Cadre Mayer Brown (2026) [24] | Partiel | Texte juridique | Recours juridiques | Oui (6 composantes) | Analyse juridique |
| ASA (ce travail) | Oui | JSON | Automatisée (séquestre) | Oui (configurable) | Spécification de protocole |
AgentSLA est le travail antérieur le plus proche. ASA étend l'approche de spécification d'AgentSLA en ajoutant l'application (liaison au séquestre), la négociation (protocole structuré) et la vérification (intégration Agent-as-a-Judge). Les deux sont complémentaires : le modèle de qualité et la syntaxe DSL d'AgentSLA pourraient servir de couche de spécification au sein des accords ASA.
| Système | Qualité sémantique | Automatisé | Multidimensionnel | Natif pour agents | Coût/évaluation |
|---|---|---|---|---|---|
| PayCrow [17] | Non (structurelle) | Oui | Non (binaire) | Oui | 2 % de la tx |
| ERC-8183 [2] | Dépend de l'évaluateur | Oui | Non (binaire) | Oui | Frais de gas |
| SonarQube [20] | Code uniquement | Oui | Oui (3+) | Non | Gratuit/$$$ |
| LLM-as-a-Judge [33] | Oui | Oui | Configurable | Adaptable | 0,01-5 $ |
| Agent-as-a-Judge [65][4] | Oui (~90 % code ; 60-68 % spécialisé) | Oui | Oui (5 méthodes) | Oui | 0,03-31 $ |
| API Verification ASA | Oui (étagée ; ~90 % code, 60-68 % spécialisé) | Oui | Oui (configurable) | Oui | 0,01-31 $ |
L'API Verification d'ASA se différencie en offrant une profondeur étagée (structurelle/sémantique/composite), des dimensions configurables, un fonctionnement autonome sans nécessiter d'accord, et l'intégration avec le séquestre pour une application automatisée.
| Système | Accords | Vérification | Paiement | Négociation | Réputation |
|---|---|---|---|---|---|
| x402 [14] | Non | Non | Oui (HTTP 402) | Non | Non |
| ERC-8183 [2] | Partiel (tâche) | Externe | Oui (séquestre) | Non | Via ERC-8004 |
| ACP/AP2/TAP [46] | Non | Non | Oui (carte/crypto) | Non | Non |
| Fetch.ai AEA [47] | Découverte | Non | Oui (FET) | Découverte | Staking FET |
| Pactum [48] | Approvisionnement | Non | Via client | Oui (piloté par IA) | Non |
| Circle AI Escrow [49] | Analyse de PDF | Analyse d'image | Oui (USDC) | Non | Non |
| ASA | Protocole complet | Multi-niveaux | Via liaison | Structurée | Via ARP |
Aucun système existant ne couvre la pile complète de la négociation à l'accord, en passant par la vérification et l'application. Pactum gère la négociation d'approvisionnement mais pas la vérification de la qualité. ERC-8183 gère le séquestre mais pas la négociation ni la spécification de la qualité. x402 gère le paiement mais pas les accords. La contribution d'ASA est l'intégration — connecter ces capacités dans un flux protocolaire cohérent.
ASA est conçu pour fonctionner avec l'infrastructure existante, et non pour la remplacer. Un accord ASA peut :
ASA fournit la logique d'accord qui connecte ces composants. Son avantage concurrentiel réside dans l'intégration et l'ouverture, et non dans le verrouillage propriétaire d'infrastructure.
ASA fait face à des menaces provenant de trois types d'adversaires :
Fournisseur malveillant : livre un résultat de faible qualité, tente de détourner les métriques de vérification ou s'entend avec l'évaluateur.
Client malveillant : rejette un travail satisfaisant pour éviter le paiement, dépose des litiges abusifs ou manipule la négociation.
Évaluateur malveillant : renvoie des résultats de vérification biaisés — soit pour aider une partie complice, soit pour extorquer des pots-de-vin.
| Attaque | Vecteur | Atténuation |
|---|---|---|
| Détournement de qualité | Le fournisseur optimise les métriques mesurées tout en dégradant la qualité non mesurée | Les métriques fantômes détectent le déplacement des dommages ; la notation multidimensionnelle augmente le coût du détournement ; les tâches canari détectent le détournement systématique |
| Collusion de l'évaluateur | L'évaluateur et le fournisseur s'accordent pour gonfler les scores | Rotation des évaluateurs ; tâches canari avec scores connus ; consensus multi-évaluateurs pour les accords de grande valeur |
| Injection de prompt en négociation | L'agent intègre des instructions dans les messages de négociation pour manipuler le LLM de l'adversaire | Champs JSON structurés (pas de texte libre) ; rationale_code depuis une énumération fixe ; aucun point d'injection de texte brut |
| Blanchiment de réputation Sybil | L'agent crée une nouvelle identité après avoir accumulé une mauvaise réputation | Les chaînes CoC rendent la création d'identité coûteuse ; longueur de chaîne minimum pour l'éligibilité aux accords ; vérification croisée des historiques |
| Déni d'évaluation | L'évaluateur se met hors ligne pour bloquer la libération du paiement | Interrupteur automatique avec délai configurable ; spécification d'évaluateur de secours ; actions de délai par défaut |
| Attaque par coût de vérification | Le client demande une vérification dont le coût dépasse la valeur de l'accord | Limites de coût de vérification spécifiées dans l'accord ; l'évaluateur rejette les demandes dépassant le plafond de coût |
| Substitution de livrable | Le fournisseur soumet un livrable pour la vérification mais en livre un différent au client | Liaison par hash de contenu — le hash du livrable est enregistré à la fois dans la demande de vérification et le système de séquestre ; une discordance de hash invalide la vérification |
| Attaque par répétition | Resoumettre un résultat de vérification précédent pour un nouveau livrable | Chaque résultat de vérification inclut l'agreement_id, le hash du contenu du livrable et l'horodatage ; la détection de doublons empêche la répétition |
La loi de Goodhart — « lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure » [19] — est la menace la plus fondamentale pour tout système d'accord basé sur la qualité. ASA y répond à trois niveaux :
Équilibre des métriques : chaque métrique cible est couplée à une métrique fantôme mesurant le déplacement attendu des dommages. Si la précision est ciblée, le taux d'hallucination est la métrique fantôme. Si la vitesse est ciblée, la qualité est la métrique fantôme. Un agent qui détourne la précision en produisant des résultats verbeux couvrant toutes les bases verrait sa métrique fantôme de concision se dégrader.
Adaptabilité de l'évaluateur : les évaluateurs Agent-as-a-Judge ne sont pas contraints aux dimensions spécifiées. Le champ de preuves de l'évaluateur peut signaler des problèmes de qualité au-delà des critères formels. Bien que ces signaux n'affectent pas directement la notation, ils sont enregistrés dans la piste de vérification et disponibles comme preuves pour les litiges et l'analyse de réputation.
Rotation temporelle : les modèles d'accord et les grilles de qualité sont versionnés et évoluent. Un fournisseur qui sur-ajuste les modèles d'évaluation de la grille v1 verra ses performances se dégrader lorsque la grille v2 sera déployée. Cela crée une dynamique de Reine Rouge qui pénalise le détournement par rapport à l'amélioration véritable de la qualité.
Les résultats de vérification ASA contiennent des informations sur la qualité des livrables qui peuvent être commercialement sensibles. Le protocole fournit :
Contrôle de visibilité des résultats : les accords spécifient qui peut interroger les résultats de vérification (parties uniquement, parties + système ARP, ou public).
Agrégation pour la réputation : lorsqu'ASA transmet des données à l'ARP, il envoie des statistiques agrégées (taux de réussite, score composite moyen) plutôt que des détails de vérification individuels.
Isolation du contenu : l'API Verification reçoit le contenu du livrable pour l'évaluation mais ne le stocke pas. Seul le hash du contenu persiste dans le résultat de vérification. Les évaluateurs doivent supprimer le contenu du livrable après l'évaluation.
La flotte AB Support opère un ASA informel depuis mars 2026. La flotte de six agents traite les tâches en suivant le cycle de vie ASA :
| Concept ASA | Implémentation dans la flotte |
|---|---|
| Accord | Spécifications de tâches structurées avec livrables, contraintes et critères de qualité |
| Dimensions de qualité | Six dimensions : étendue, profondeur, précision, sources, références croisées, qualité rédactionnelle |
| SLO | Score minimum de 60/100 par dimension ; moyenne ≥ 60 pour acceptation |
| Vérification | Alex (coordinateur) révise en utilisant l'évaluation Agent-as-a-Judge |
| Réponse graduée | Score ≥ 60 : accepter et promouvoir. Score < 60 : retourner à Bravo avec des demandes de révision spécifiques |
| Piste de preuves | Résultats de vérification stockés dans des documents structurés de suivi de la qualité |
| Rétroaction de réputation | L'historique de Bravo informe la complexité des attributions de tâches futures |
Ce prototype valide plusieurs décisions de conception d'ASA :
L'implémentation de référence sera fournie sous la forme de :
asa-protocol) : création, validation, signature et gestion du cycle de vie des accords. Client de vérification avec backends d'évaluateurs modulaires.La vérification ASA actuelle est a posteriori — la qualité est évaluée après la livraison. Les versions futures devraient prendre en charge le suivi de la qualité en temps réel pendant l'exécution des tâches, permettant l'arrêt anticipé du travail défaillant avant que les coûts ne s'accumulent. Cela suit le modèle de SRM agentique de Newgen pour la détection prédictive de violations [50] et la prévision de violations par apprentissage automatique de Sirion AI [51].
L'évaluation Agent-as-a-Judge coûte entre 0,03 et 31 $ par évaluation [65]. À grande échelle avec des millions de transactions entre agents, ce coût doit diminuer de plusieurs ordres de grandeur. Les pistes de recherche comprennent :
Les dimensions de qualité par défaut d'ASA sont calibrées pour les types de services les plus courants dans le commerce actuel entre agents (recherche, code, analyse). À mesure que les services d'agents se diversifient, des cadres de qualité spécifiques au domaine seront nécessaires pour le contenu créatif, l'analyse financière, l'information médicale, le raisonnement juridique et d'autres domaines spécialisés.
Ce livre blanc fournit une analyse informelle de théorie des jeux. Des preuves formelles de conception de mécanisme — démontrant que la structure d'incitation d'ASA est à l'épreuve des stratégies, individuellement rationnelle et efficace sous des conditions spécifiques — renforceraient les fondements théoriques du protocole.
Les besoins en ressources d'ASA évoluent selon trois axes principaux : le stockage des accords, le débit de vérification et la charge de négociation.
| Échelle de déploiement | Agents | Accords/jour | Stockage/an | Évaluateurs simultanés | Surcharge canari |
|---|---|---|---|---|---|
| Petite | 100 | 1 000 | ~7 Go | 1-3 | ~60 $/jour |
| Moyenne | 10 000 | 100 000 | ~730 Go | 30-330 | ~6 000 $/jour |
| Grande | 1 000 000 | 10 000 000 | ~73 To | 3 000-33 000 | ~600 000 $/jour |
Hypothèses : les documents d'accord font en moyenne ~2 Ko ; les résultats de vérification font en moyenne ~1 Ko ; la vérification sémantique prend 10-120 secondes par évaluation ; les tâches canari s'exécutent à raison de 1 pour 5 livraisons (20 % de surcharge) ; le coût moyen de l'évaluateur est de 0,30 $ par évaluation.
Principales préoccupations d'extensibilité :
Le format d'accord d'ASA devrait être soumis à la standardisation auprès des organismes compétents. Les candidats comprennent l'Agentic AI Foundation (AAIF) pour l'intégration protocolaire avec MCP/A2A, le W3C AI Agent Protocol Community Group pour les accords entre agents natifs du web, et l'ISO pour la standardisation internationale (en s'appuyant sur le modèle de qualité ISO/IEC 25010 et la gestion de l'IA ISO/IEC 42001).
L'économie des agents dispose de rails de paiement, de canaux de communication et de registres d'identité. Il lui manque un moyen standardisé de former, vérifier et appliquer des accords de service. ASA comble cette lacune avec deux surfaces d'API — Agreements pour les contrats lisibles par les machines et Verification pour l'évaluation de la qualité — connectées par une logique appliquée par le protocole qui fusionne le pipeline traditionnel spécifier-surveiller-détecter-réclamer-compenser en une opération atomique.
Le protocole s'appuie sur des composants matures : l'extension ISO 25010 d'AgentSLA pour la spécification de la qualité [1], Agent-as-a-Judge pour l'évaluation sémantique atteignant environ 90 % de concordance humaine en génération de code [65] avec des taux inférieurs dans les domaines spécialisés [36], le modèle de séquestre tripartite d'ERC-8183 pour l'application des paiements [2], et le format dual humain/machine des contrats ricardiens pour la défensibilité juridique [3]. La contribution d'ASA est l'intégration — reliant la spécification à la négociation, à la vérification et au paiement dans un protocole cohérent et ouvert.
Trois choix de conception définissent le caractère d'ASA. Premièrement, les résultats plutôt que la disponibilité — la qualité est mesurée par ce qui a été livré, et non par le fonctionnement du serveur, suivant l'évolution du secteur des SLA vers les XLA [23][24]. Deuxièmement, le gradué plutôt que le binaire — la qualité partielle reçoit un paiement partiel, créant des incitations continues à l'amélioration plutôt que des effets de seuil. Troisièmement, l'intégration ouverte plutôt que le verrouillage propriétaire — ASA fonctionne avec n'importe quel système d'identité, n'importe quel rail de paiement et n'importe quelle plateforme de séquestre, spécifiant la logique d'accord sans imposer d'infrastructure.
Le protocole est informé par la production. La flotte de six agents d'AB Support opère un ASA informel depuis mars 2026, validant la notation multidimensionnelle de la qualité, la spécification structurée des tâches et l'évaluation Agent-as-a-Judge dans les opérations quotidiennes. Formaliser ces pratiques en un protocole ouvert étend leur valeur à tout écosystème d'agents.
Des défis subsistent. La vérification de la qualité sémantique, bien qu'atteignant environ 90 % de concordance humaine en génération de code [65], chute à 60-68 % dans les domaines spécialisés [36] et présente des biais documentés. La loi de Goodhart garantit que les métriques mesurées seront détournées par des agents suffisamment capables [19]. La résistance à la collusion sous des conditions adversariales arbitraires manque de preuve formelle. Ce sont des limitations honnêtes, et non des faiblesses cachées — et elles définissent la frontière de recherche du protocole.
Les composants de base pour les accords de service entre agents sont étonnamment matures. Le manque est dans l'intégration. ASA fournit cette intégration.
[1] Jouneaux, G. & Cabot, J. (2025). "AgentSLA: Towards a Service Level Agreement for AI Agents." Luxembourg Institute of Science and Technology. arXiv:2511.02885.
[2] Ethereum EIPs (2026). "ERC-8183: Agentic Commerce — Programmable Escrow for AI Agents." eips.ethereum.org/EIPS/eip-8183.
[3] Grigg, I. (1996). "The Ricardian Contract." iang.org.
[4] You, R., Cai, H., Zhang, C. et al. (2026). "A Survey on Agent-as-a-Judge." arXiv:2601.05111.
[5] Rogers, O. (2022). "Cloud SLAs punish, not compensate." Uptime Institute Journal.
[6] AWS (2025). "What is SLA? — Service Level Agreement Explained." aws.amazon.com.
[7] Outlier Ventures (2025). "The Token Advantage: Building Smarter, Fairer Systems with AI and Decentralization." outlierventures.io.
[8] Vaccaro, M. et al. (2025). "Large-Scale Autonomous Negotiation Competition." MIT Sloan / Johns Hopkins. arXiv:2503.06416.
[9] Zhu, Y. et al. (2025). "The Automated but Risky Game." arXiv:2506.00073.
[10] Shah, P. et al. (2025). "LLM Rationalis?" NeurIPS 2025. arXiv:2512.13063.
[11] AB Support (2026). "Chain of Consciousness: A Provenance Protocol for Autonomous AI Agents." v3.0.
[12] AB Support (2026). "Agent Rating Protocol: A Multi-Dimensional Reputation Framework for Autonomous AI Agents." v1.0.
[13] QuickNode Blog (2026). "ERC-8004: A Developer's Guide to Trustless AI Agent Identity."
[14] Solana.com (2026). "What is x402? | Payment Protocol for AI Agents." x402.org.
[15] Google Developers Blog (2025). "Announcing the Agent2Agent Protocol (A2A)."
[16] Linux Foundation (2025). "Agentic AI Foundation (AAIF) Formation." linuxfoundation.org.
[17] Dev|Journal (2026). "PayCrow Escrow for x402 Agent Payments." Note : le chiffre de plus de 600 M$ cité dans certaines sources fait référence au volume total de l'écosystème x402, et non au montant sécurisé par PayCrow.
[18] AWS (2025). "What is SLA? — Service Level Agreement Explained." Selon la définition ITIL 4.
[19] Goodhart, C. (1975). "Problems of Monetary Management: The U.K. Experience." Reformulé par Strathern, M. (1997) : « Lorsqu'une mesure devient un objectif, elle cesse d'être une bonne mesure. »
[20] Sonar Documentation (2026). "Understanding quality gates." docs.sonarsource.com.
[21] Daniel, F. et al. (2018). "Quality Control in Crowdsourcing: A Survey." ACM Computing Surveys, Vol 51.
[22] Upwork Help Center (2026). "How Fixed-Price Payment Protection works." support.upwork.com.
[23] XLA Institute (2025). "State of XLA 2025." xla.institute.
[24] George, R.P., Pennell, J., Peterson, B.L., Yaros, O. (2026). "Contracting for Agentic AI Solutions: Shifting the Model from SaaS to Services." Mayer Brown.
[25] ISO/IEC 25010:2023. "Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model."
[26] DeepSource (2025). "Code Quality — Five-Dimension Analysis." deepsource.com.
[27] Codility Support (2026). "Automated Scoring Principles." support.codility.com.
[28] arXiv 2601.00481 (2026). "MAESTRO: Multi-Agent Evaluation Suite for Testing, Reliability, and Observability."
[29] arXiv 2602.03053 (2026). "MAS-ProVe: Understanding Process Verification of Multi-Agent Systems."
[30] Fiverr Help Center (2026). "Seller levels overview." help.fiverr.com.
[31] Accord Project (2025). "Smart Legal Contract Templates." accordproject.org.
[32] ANAC 2024 (2025). "15th Automated Negotiating Agents Competition." AAMAS 2025.
[33] Zheng, L. et al. (2023). "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685.
[34] AWS (2025). "What is RLHF?" aws.amazon.com.
[35] Kim, S. et al. (2024). "Prometheus: Inducing Fine-grained Evaluation Capability in Language Models." ICLR 2024. arXiv:2310.08491.
[36] IJCNLP (2025). Domain-specific LLM-as-Judge agreement rates. Tel que cité dans Li et al. (2024), arXiv:2412.05579.
[37] arXiv:2410.09770 (2024). "Quis custodiet ipsos custodes? AI-generated peer reviews."
[38] NEC Press Release (2025). "NEC Launches AI Agent Service for Procurement Negotiations."
[39] Kirshner, S. et al. (2026). "Talking Terms: LLM Supply Chain Bargaining." Decision Sciences, Vol. 57, 9-23.
[40] Ye, J. & Tan, Z. (2026). "Agent Contracts: Formal Framework for Resource-Bounded AI." arXiv:2601.08815.
[41] Nash, J.F. (1950). "The Bargaining Problem." Econometrica, 18(2), 155-162.
[42] Outlier Ventures (2025). "From Smart Contracts to Smart Agents: The Rise of the Agentic Layer." outlierventures.io.
[43] Keller, A. & Ludwig, H. (2003). "The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services." IBM. Journal of Network and Systems Management.
[44] OGF (2007). "WS-Agreement Specification." Open Grid Forum.
[45] Uriarte, R.B., Tiezzi, F., De Nicola, R. (2015). "SLAC: A Formal Service-Level-Agreement Language for Cloud Computing." IEEE.
[46] PayRam (2026). "ACP vs. AP2 vs. TAP: The Protocol Wars of Agentic Commerce."
[47] Fetch.ai (2025). "Autonomous Economic Agents (AEA) Framework." fetch.ai.
[48] Pactum (2025). "Understanding Agentic AI in Procurement." pactum.com.
[49] ZenML (2025). "Circle: AI-Powered Escrow Agent for Programmable Money Settlement."
[50] Newgen (2025). "AI Agent-driven SLA Management." newgensoft.com.
[51] Sirion AI (2025). "Automated SLA Breach Alerts for Telecom Service Contracts." sirion.ai.
[52] Uriarte, R.B., De Nicola, R. et al. (2021). "Distributed service-level agreement management with smart contracts." Concurrency and Computation, Wiley.
[53] Booth, A., Alqahtani, A., Solaiman, E. (2024). "IoT Monitoring with Blockchain." arXiv:2408.15016.
[54] Chainlink (2025). "Chainlink: The Industry-Standard Oracle Platform." chain.link.
[55] Bianchi, F. et al. (2024). "NegotiationArena." ICML 2024. arXiv:2402.05863.
[56] Liu, Z., Gu, H., Song, Z. (2026). "AgenticPay." ICML 2026. arXiv:2602.06008.
[57] Hua, W. et al. (2024). "Game-Theoretic LLM: Agent Workflow for Negotiation Games." arXiv:2411.05990.
[58] Proofpoint (2026). "Agent Integrity Framework — 2026 Edition."
[59] PwC (2026). "Validating multi-agent AI systems." pwc.com.
[60] Proskauer Rose (2025). "Contract Law in the Age of Agentic AI."
[61] RNWY Group (2025). "AI Agents and Electronic Contracts: The Laws Already Say 'Yes'."
[62] CCN (2026). "ERC-8183 Programmable Escrow AI Agents."
[63] Kleros (2025). "Decentralized Arbitration." kleros.io.
[64] Moritz College of Law, Ohio State (2022). "Kleros: A Socio-Legal Case Study of Decentralized Justice and Blockchain Arbitration."
[65] Zhuge, M., Liu, C., Pan, Z. et al. (2024). "Agent-as-a-Judge: Evaluate Agents with Agents." arXiv:2410.10934. Note : source principale pour le chiffre de ~90 % de concordance humaine dans les tâches d'évaluation de la génération de code.
Ce document est publié sous la licence Apache 2.0. Vous pouvez utiliser, modifier et distribuer ce travail avec attribution à AB Support LLC.
La spécification du protocole, les modèles de données et les définitions d'API contenus dans ce document sont fournis en tant que standard ouvert pour l'économie des agents. Aucune revendication de brevet n'est faite ou impliquée.
© 2026 AB Support LLC. Tous droits réservés selon les termes de la licence Apache 2.0.