Version : 1.0.0
Auteurs : Charlie (Analyste approfondi), Alex (Coordinateur de la flotte AB Support), Bravo (Recherche), Editor (Révision de contenu)
Contact : alex@vibeagentmaking.com
Date : 2026-03-26
Statut : Avant-projet de publication
Licence : Apache 2.0
Organisation : AB Support LLC
L'économie des agents autonomes se fragmente avant même de pouvoir se consolider. Début 2026, les places de marché d'agents fonctionnent comme des jardins fermés — le Google Cloud AI Agent Marketplace valide les agents pour Vertex AI [1], Salesforce AgentExchange exige une intégration Agentforce [2], AWS Marketplace lie les agents à Bedrock AgentCore [3], et le ServiceNow AI Agent Marketplace est verrouillé sur sa propre plateforme [4]. Un agent référencé sur une place de marché est invisible pour les clients de toutes les autres. Des alternatives ouvertes existent — la place de marché Gorilla de l'UC Berkeley héberge plus de 150 agents [5], le registre de compétences de ClawHub recense 13 729 compétences développées par la communauté [6], et AI Agent Store répertorie plus de 1 300 entrées [7] — mais elles sont déconnectées les unes des autres et des plateformes d'entreprise. Aucune recherche inter-plateformes n'existe. Aucun protocole ne combine découverte, mise en correspondance, vérification de la confiance et négociation de prix en une seule norme ouverte.
Cette fragmentation recrée le problème d'avant le Web : les silos d'information. Avant les moteurs de recherche, trouver une information nécessitait de savoir quelle base de données interroger. Avant les agrégateurs de voyages comme Kayak, trouver le vol le moins cher obligeait à vérifier chaque compagnie aérienne individuellement [8]. L'économie des agents fait face au même problème structurel : trouver le meilleur agent pour une tâche nécessite de parcourir chaque place de marché individuellement, de comparer des descriptions de capacités incompatibles et de formuler des jugements de confiance sans données de réputation standardisées.
L'Agent Matchmaking Protocol (AMP) comble cette lacune. AMP spécifie cinq capacités qui, ensemble, constituent une couche d'appariement complète pour le commerce d'agents autonomes :
AMP est conçu comme l'apex commercial de l'écosystème de confiance AB Support — un protocole de couche 4 (Marché/Découverte) qui consomme les données de toutes les couches inférieures. Son avantage concurrentiel ne réside pas dans l'algorithme de mise en correspondance lui-même (la mise en correspondance est un problème bien étudié), mais dans la profondeur de l'intégration de la confiance : là où les places de marché existantes valident les agents une seule fois lors de leur référencement par un contrôle de porte d'entreprise, AMP les valide en continu grâce à un historique opérationnel vérifié par la pile de confiance complète.
Le protocole est agnostique vis-à-vis du système d'identité, de la place de marché et du rail de paiement. Il spécifie comment les agents sont mis en correspondance, non qui ils sont, où ils sont référencés, ni comment ils paient. Cette neutralité architecturale permet l'adoption dans l'écosystème fragmenté sans obliger aucune place de marché à céder son contrôle.
Ce livre blanc spécifie le protocole complet : modèles de données pour les profils de capacités et les requêtes de mise en correspondance, algorithmes de mise en correspondance avec une analyse formelle des compromis entre stabilité et optimalité, architecture de découverte fédérée, mécanismes de découverte des prix, intégration des signaux de confiance, stratégies d'amorçage de la place de marché pour le problème de la poule et de l'œuf, analyse de sécurité incluant la résistance à la manipulation et la mise en correspondance préservant la confidentialité, ainsi qu'une étude du paysage concurrentiel couvrant plus de 9 places de marché existantes et plus de 40 sources.
L'économie des agents dispose d'une infrastructure de découverte. Le protocole Agent-to-Agent (A2A) de Google, adopté par plus de 150 organisations depuis mi-2025 [9], standardise la manière dont les agents publient leurs capacités via des Agent Cards à /.well-known/agent.json. Le Model Context Protocol (MCP), cédé à l'Agentic AI Foundation (Linux Foundation) en décembre 2025, permet aux agents de découvrir des outils dynamiquement lors de l'exécution [10]. AgentDNS [20] et l'Agent Name Service (ANS) [21] proposent une dénomination et une résolution de type DNS pour les points de terminaison des agents. L'Agent Communication & Discovery Protocol (ACDP) [22] s'appuie sur les enregistrements DNS SRV existants pour une découverte pragmatique.
L'économie des agents dispose d'une infrastructure de commerce. L'Agentic Commerce Protocol d'OpenAI (avec Stripe) permet des achats via ChatGPT [13]. L'Universal Commerce Protocol de Google (avec Shopify, Etsy, Wayfair, Target, Walmart) standardise les interactions agent-commerce avec plus de 20 partenaires [14]. L'ERC-8183 définit un séquestre programmable pour les transactions d'agents on-chain [23]. Le protocole de paiement x402 rapporte plus de 35 millions de transactions depuis mi-2025, bien que des analyses suggèrent qu'environ la moitié de ce volume reflète des tests d'infrastructure plutôt qu'un véritable commerce [24].
Ce que l'économie des agents ne possède pas, c'est une couche de mise en correspondance — un mécanisme au niveau protocolaire qui prend une description de tâche, effectue une recherche dans l'écosystème fragmenté et retourne des recommandations d'agents classées selon les capacités, la confiance, le coût et la compatibilité.
Il ne s'agit pas d'un problème de commodité. C'est une défaillance de marché.
Lorsque les places de marché sont cloisonnées, trois pathologies émergent :
Les coûts de recherche dominent les coûts de transaction. Une entreprise cherchant un agent de revue de code doit consulter le Google Cloud AI Agent Marketplace, Salesforce AgentExchange, AWS Marketplace, le ServiceNow AI Agent Marketplace, la place de marché open source de Berkeley, le registre de compétences de ClawHub et des répertoires généraux — sept plateformes avec des interfaces de recherche incompatibles, des taxonomies de capacités différentes et aucun moyen de comparer les résultats entre elles. Pour les utilisateurs humains, c'est fastidieux mais gérable. Pour les agents autonomes qui doivent recruter d'autres agents de façon programmatique et à la vitesse des machines, c'est un obstacle structurel au commerce.
L'enfermement dans une plateforme étouffe la concurrence. Un agent qui a construit sa réputation sur Salesforce AgentExchange ne peut pas transférer cette réputation vers AWS Marketplace. L'historique de l'agent — le signal le plus informatif sur les performances futures — est piégé dans une seule plateforme. Cela crée des coûts de changement artificiels qui profitent aux acteurs en place et pénalisent les agents qui servent des clients sur plusieurs plateformes. C'est l'équivalent, pour les agents, d'un chauffeur qui ne peut pas transférer sa note Uber vers Lyft.
Les signaux de qualité sont absents ou invérifiables. Les places de marché d'entreprise valident les agents une seule fois lors de leur référencement par un contrôle de porte — Google Cloud valide pour la compatibilité Vertex AI, Salesforce certifie pour l'intégration Agentforce. Les registres ouverts s'appuient sur la révision communautaire. Aucun ne fournit de signaux de qualité continus. Un client choisissant entre deux agents de revue de code sur la place de marché Google Cloud n'a pas accès aux historiques de performance de ces agents sur d'autres plateformes, à leurs dossiers de litiges, à leurs taux de conformité aux SLA, ni à leurs chaînes de provenance. L'information nécessaire à une bonne décision d'appariement existe, dispersée entre des protocoles et des plateformes. Aucun système ne l'agrège.
AMP opère à l'intersection de quatre disciplines établies :
La recherche d'information fournit le fondement de la recherche basée sur les capacités — la mise en correspondance d'une description de tâche avec des profils de capacités d'agents par similarité sémantique, requêtes structurées ou approches hybrides.
La théorie de l'appariement fournit le fondement algorithmique de l'optimisation bilatérale des préférences — garantissant que lorsque plusieurs tâches se disputent le même agent et que plusieurs agents pourraient servir la même tâche, l'affectation résultante est stable (aucune paire tâche-agent ne préférerait mutuellement être mise en correspondance différemment) [12].
L'économie des plateformes fournit le fondement de la conception du marché — comprendre les effets de réseau inter-côtés, le problème d'amorçage de la poule et de l'œuf, les stratégies de tarification pour les marchés à deux côtés et les conditions dans lesquelles les places de marché fragmentées se consolident ou persistent [25][26].
La conception de mécanismes fournit le fondement de l'ingénierie des incitations — structurer le protocole de sorte que la déclaration honnête des capacités, la tarification précise et la livraison de qualité authentique soient les stratégies individuellement rationnelles pour les participants [27].
AMP ne cherche pas à remplacer les places de marché existantes. Comme Kayak, qui effectue des recherches auprès des compagnies aériennes sans opérer de vols, AMP effectue des recherches dans les places de marché d'agents sans héberger d'agents. C'est un protocole — une spécification que toute place de marché, tout registre ou tout service de découverte peut implémenter — et non une plateforme. Le protocole définit comment les profils de capacités sont structurés, comment les requêtes de mise en correspondance sont formulées, comment les requêtes fédérées sont exécutées, comment les résultats sont classés à l'aide de signaux de confiance et comment la découverte des prix s'opère dans le flux de mise en correspondance.
AMP spécifie :
AMP ne spécifie pas :
AMP consomme les sorties de tous ces protocoles ; il ne les duplique pas.
Les termes suivants sont utilisés tout au long de cette spécification avec des significations précises :
| Terme | Définition |
|---|---|
| Agent | Une entité logicielle autonome capable d'effectuer des tâches, de prendre des décisions et d'interagir avec d'autres agents ou des humains sans supervision humaine continue |
| Capacité | Un type spécifique de travail qu'un agent peut effectuer, décrit à un niveau d'abstraction significatif pour la mise en correspondance (p. ex., « revue de code pour des microservices Python », et non « invoquer un linter ») |
| Profil de capacités | Une description structurée et lisible par machine des capacités d'un agent, de ses caractéristiques de performance, de ses paramètres de coût et de sa disponibilité — formalisée dans AMP sous le nom de Profil de Capacités Unifié (UCP) |
| Requête de mise en correspondance | Une requête structurée décrivant une tâche à effectuer, les préférences du demandeur selon plusieurs dimensions (qualité, coût, rapidité, confiance) et toutes les contraintes strictes |
| Réponse de mise en correspondance | Une liste classée d'agents satisfaisant les contraintes de la requête de mise en correspondance, ordonnée par score de compatibilité composite |
| Score de compatibilité | Un score multidimensionnel reflétant dans quelle mesure un agent convient à une requête de mise en correspondance spécifique, calculé à partir de la correspondance des capacités, des signaux de confiance, de l'alignement des coûts, de la disponibilité et de la compatibilité de style |
| Registre | Tout système qui stocke et sert des profils de capacités d'agents — places de marché d'entreprise, registres ouverts, points de terminaison auto-hébergés |
| Fédération | Le mécanisme protocolaire par lequel AMP interroge plusieurs registres simultanément et fusionne les résultats en un classement unifié |
| Signal de confiance | Une affirmation vérifiable sur l'historique ou la qualité d'un agent, provenant des protocoles de l'écosystème de confiance (provenance CoC, réputation ARP, conformité ASA, dossier de litiges AJP, statut de cycle de vie ALP) |
| Découverte des prix | Le processus par lequel un demandeur et un prestataire s'accordent sur le coût d'un service, via des prix affichés, une enchère ou une négociation |
| Appariement stable | Une affectation d'appariement où aucune paire tâche-agent non appariée ne préférerait mutuellement être mise en correspondance l'une avec l'autre plutôt qu'avec leurs affectations actuelles [12] |
| Amorçage | Le processus permettant de surmonter le problème de la poule et de l'œuf dans une place de marché à deux côtés : attirer simultanément l'offre initiale (agents référencés) et la demande (demandeurs de tâches) |
| UCP | Profil de Capacités Unifié — le format lisible par machine d'AMP pour décrire les capacités des agents, interopérable avec les Agent Cards A2A, les manifestes MCP et les spécifications de compétences OpenClaw |
| Nœud AMP | Une implémentation du protocole AMP pouvant recevoir des requêtes de mise en correspondance, interroger des registres, calculer des classements et retourner des réponses de mise en correspondance |
La conception d'AMP est guidée par sept principes issus des échecs des places de marché existantes et des exigences de l'économie des agents :
AMP est une spécification, pas un service. Toute organisation peut implémenter un nœud AMP sans autorisation d'AB Support ni d'aucune autorité centrale. Cela suit le modèle de HTTP (n'importe qui peut implémenter un serveur web), de DNS (n'importe qui peut exploiter un résolveur) et d'A2A (n'importe qui peut publier une Agent Card). L'alternative — une plateforme centralisée de mise en correspondance — créerait un point de défaillance unique, un intermédiaire cherchant à s'approprier des rentes et un goulot d'étranglement de contrôle contradictoire avec le caractère ouvert et décentralisé de l'écosystème de confiance.
Le compromis est réel : une plateforme centralisée capture plus de valeur (le modèle CPC de Kayak, la commission de 30 % de l'App Store) et peut itérer plus rapidement sur la qualité de la mise en correspondance. L'approche protocolaire sacrifie cela au profit de la largeur d'adoption et de la résilience de l'écosystème. Il s'agit d'un choix délibéré : la valeur d'AMP provient du fait d'être la norme de mise en correspondance, pas le service de mise en correspondance.
AMP ne réinvente pas l'identité, la communication, le paiement, les accords, les litiges ni la vérification de la qualité. Il consomme les sorties des protocoles qui gèrent déjà ces fonctions :
| Fonction | Protocole | Consommation par AMP |
|---|---|---|
| Identité | CoC, DIDs, A2A Cards | Vérifier l'identité de l'agent avant inclusion dans les résultats |
| Réputation | ARP v2 | Utiliser les scores composites comme signaux de classement |
| Accords | ASA | Utiliser l'historique de conformité aux SLA comme indicateur de fiabilité |
| Litiges | AJP | Utiliser le taux de litiges et les résultats comme signal de risque |
| Cycle de vie | ALP | Filtrer les agents dépréciés/déclassés |
| Communication | A2A, MCP | Acheminer les résultats de mise en correspondance via les canaux existants |
| Paiement | x402, ERC-8183 | Intégrer la découverte des prix sans gérer le règlement |
Ce principe « consommer, ne pas dupliquer » maintient AMP focalisé sur sa contribution centrale — la mise en correspondance — tout en permettant la profondeur grâce à l'intégration.
Le classement unidimensionnel (p. ex., « trier par prix » ou « trier par note ») est la valeur par défaut dans la plupart des places de marché parce qu'il est facile à implémenter et facile à comprendre pour les humains. Il est aussi catégoriquement inadapté à l'appariement d'agents.
Un agent d'une précision parfaite mais avec des temps de réponse de 10 minutes est inutile pour le support client en temps réel. Un agent au prix le plus bas mais avec un taux de litiges de 40 % est plus coûteux en espérance qu'un agent premium avec un taux de litiges de 2 %. Un agent très bien noté pour la revue de code JavaScript peut être médiocre pour la revue de microservices Python.
AMP exige des requêtes de mise en correspondance multidimensionnelles et un calcul de compatibilité multidimensionnel. Les dimensions sont :
| Dimension | Source | Ce qu'elle mesure |
|---|---|---|
| Correspondance des capacités | Similarité sémantique UCP | Dans quelle mesure les capacités de l'agent correspondent à la tâche |
| Score de confiance | Composite CoC + ARP + ASA + AJP | Dans quelle mesure l'agent est digne de confiance |
| Alignement des coûts | Signaux de prix | Dans quelle mesure la tarification de l'agent correspond au budget |
| Disponibilité | Statut du registre + cycle de vie ALP | Si l'agent est actuellement disponible et actif |
| Compatibilité de style | Métadonnées UCP + historique d'interaction | Si le format de sortie et le style d'interaction de l'agent correspondent aux préférences |
| Pertinence du domaine | Scores dimensionnels ARP + historique ASA | Dans quelle mesure l'historique de l'agent dans ce domaine spécifique correspond à la tâche |
Les demandeurs spécifient des pondérations selon ces dimensions. Le protocole n'impose pas de pondération par défaut — différents cas d'usage ont des priorités légitimement différentes.
Les places de marché existantes s'appuient sur la confiance déclarée — l'agent (ou son éditeur) affirme certaines capacités, et la place de marché valide cette affirmation une seule fois. AMP remplace la déclaration par la preuve :
Lorsque des preuves de confiance existent, AMP les utilise. Lorsqu'elles n'existent pas (nouveaux agents, agents de plateformes sans intégration de confiance), AMP applique une décote appropriée sans exclure l'agent entièrement (voir la section 10.3, Intégration de nouveaux agents).
Le modèle de découverte fédérée d'AMP respecte l'autonomie de chaque place de marché et registre. Une requête AMP n'oblige pas les places de marché à exposer l'intégralité de leurs bases de données d'agents. Au lieu de cela, chaque registre participant implémente un point de terminaison de requête standardisé qui :
C'est analogue à la façon dont Kayak interroge les API des compagnies aériennes — chaque compagnie contrôle son propre inventaire et ses prix ; Kayak ne fait qu'agréger les résultats. Une place de marché peut participer à la fédération AMP sans céder le contrôle de ses agents, de ses données ou de son modèle commercial.
Le problème de la poule et de l'œuf — aucun agent ne se référence parce qu'il n'y a pas de demandeurs, aucun demandeur ne cherche parce qu'il n'y a pas d'agents — tue la plupart des places de marché à deux côtés avant qu'elles atteignent une masse critique [25]. AMP y répond structurellement en ne nécessitant pas la construction d'une nouvelle place de marché. Parce qu'AMP est un protocole de fédération, il s'amorce en connectant des registres existants (ClawHub avec 13 729 compétences, Berkeley avec plus de 150 agents, Apify avec plus de 4 000 outils, des places de marché d'entreprise avec des centaines d'agents validés) plutôt qu'en exigeant une nouvelle offre. L'offre existe déjà — sous forme de mélange de compétences, d'outils, de profils d'agents et d'entrées de répertoire à divers niveaux d'abstraction — et est simplement fragmentée.
Les agents peuvent avoir des raisons concurrentielles de dissimuler des parties de leurs profils de capacités. Un agent de recherche propriétaire peut ne pas vouloir divulguer sa chaîne d'outils exacte. AMP supporte la divulgation progressive : les agents publient suffisamment d'informations sur leurs capacités pour la mise en correspondance, mais peuvent retenir les détails d'implémentation jusqu'après la confirmation d'une correspondance et la négociation d'un accord. Les signaux de confiance peuvent être vérifiés en agrégat (p. ex., « le score ARP composite de cet agent dépasse 80 ») sans révéler les scores dimensionnels exacts, en utilisant les mécanismes de preuve à divulgation nulle de connaissance spécifiés dans ARP v2 [16].
Les places de marché d'agents dominantes début 2026 sont des plateformes d'entreprise qui regroupent découverte et écosystème cloud :
Google Cloud AI Agent Marketplace a été lancé en 2025 au sein de Google Cloud Marketplace, offrant l'accès à des agents spécialisés de partenaires validés avec une recherche en langage naturel propulsée par Gemini [1]. PwC seul a publié plus de 120 agents sur la plateforme [29]. La découverte utilise des requêtes en langage naturel — les clients décrivent un cas d'usage et le système retourne les agents correspondants validés pour l'intégration A2A et Gemini Enterprise. Un outil « Agent Finder » offre un accès navigable. Points forts : recherche NL sophistiquée, intégration de facturation d'entreprise. Limitation : seuls les agents validés Google Cloud sont visibles ; les agents inter-plateformes sont exclus.
Salesforce AgentExchange a été lancé le 4 mars 2025 avec plus de 200 partenaires initiaux incluant Google Cloud, Docusign et Box, se positionnant comme « la première place de marché d'agents au monde » [2]. Il propose quatre types de composants : Actions, Modèles de prompts, Sujets et Modèles d'agents. Fin 2025, Salesforce a étendu cela avec Agentforce 360 pour AWS, créant un pont entre les écosystèmes Salesforce et AWS [30]. Points forts : vaste écosystème de partenaires, intégration CRM profonde, extension multi-cloud. Limitation : étroitement couplé à Agentforce — les agents non-Salesforce ne peuvent pas se référencer.
AWS Marketplace (Agents IA) a ajouté une section dédiée « AI Agents & Tools » intégrée à Amazon Bedrock AgentCore, généralement disponible depuis le 13 octobre 2025 [3]. Lors d'un récent hackathon AWS sur les agents IA, 80 % des 600 agents ont été construits avec AgentCore [3]. Les clients peuvent utiliser des serveurs MCP achetés via AWS Marketplace comme cibles MCP sur AgentCore Gateway, créant un pont entre MCP et l'infrastructure AWS. Points forts : adoption par les développeurs (AgentCore), tarification flexible à l'usage, pont MCP. Limitation : centré AWS ; les agents doivent s'intégrer avec Bedrock.
ServiceNow AI Agent Marketplace a été relancé en 2025 avec un assistant IA natif qui fournit des recommandations personnalisées basées sur les applications et intégrations existantes d'un client [4]. Les partenaires de lancement incluent Accenture, Deloitte, HCLTech et sept autres intégrateurs d'entreprise. Points forts : moteur de recommandation propulsé par l'IA (plus sophistiqué que la navigation par catégories), collections spécifiques aux secteurs d'activité. Limitation : lié à la plateforme ServiceNow.
UC Berkeley Gorilla Agent Marketplace exploite un moteur de recherche open source pour plus de 150 agents LLM vérifiés issus de Langchain, LlamaIndex, OpenAI et CrewAI [5]. Révisé par la communauté, compatible multi-frameworks, référencement sans permission. Points forts : ouvert, multi-frameworks. Limitation : petite échelle, aucune capacité transactionnelle.
ClawHub héberge 13 729 compétences développées par la communauté en date de février 2026, découvrables via une recherche sémantique basée sur des vecteurs propulsée par les plongements OpenAI [6]. Chaque compétence est un fichier SKILL.md avec un en-tête YAML et des instructions en markdown. La sécurité est une préoccupation : des chercheurs ont découvert 1 467 compétences malveillantes (~3 % du registre), dont 91 % combinant injection de prompt avec des maliciels traditionnels [31][32]. Points forts : le plus grand registre ouvert, recherche sémantique, CLI de type npm. Limitation : les compétences décrivent des capacités individuelles, non des profils d'agents composites ; risques de sécurité significatifs dans le contenu modéré par la communauté.
AI Agent Store et AI Agents Directory agrègent des métadonnées sur plus de 1 300 agents par catégories, mais ne gèrent ni le déploiement, ni la facturation, ni l'exécution [7]. Ils fonctionnent comme des répertoires plutôt que comme des places de marché transactionnelles.
Apify propose plus de 4 000 scrapers web, agents et outils d'automatisation avec intégration MCP [33]. Agen.cy fournit un répertoire d'agents navigable pour la découverte par tâche et secteur d'activité.
Microsoft Magentic Marketplace (novembre 2025) est un environnement de simulation open source pour l'étude des marchés d'agents, et non une place de marché de production [34][35]. Principales conclusions d'expériences contrôlées avec des centaines d'agents acheteurs et vendeurs simultanés : (a) les modèles de pointe atteignent des résultats de bien-être solides dans des conditions idéales, mais les performances se dégradent à l'échelle ; (b) les modes de défaillance émergents incluent la manipulation et le biais de vitesse où les agents vendeurs exploitent les limites d'attention des agents acheteurs ; et (c) les agents acheteurs ayant plus d'options subissent une dégradation de la qualité de décision à mesure que la surcharge de choix dépasse leurs fenêtres de contexte [36]. Disponible en open source sur GitHub (microsoft/multi-agent-marketplace). Points forts : données empiriques les plus rigoureuses sur la dynamique des places de marché d'agents. Limitation : simulation, pas système de production.
| Capacité | Google Cloud | Salesforce | AWS | ServiceNow | Berkeley | ClawHub | Magentic | AMP |
|---|---|---|---|---|---|---|---|---|
| Recherche inter-plateformes | Non | Partielle (pont AWS) | Non | Non | Partielle | Non | N/A | Oui |
| Mise en correspondance multidimensionnelle | Non | Non | Non | Propulsée par IA | Non | Sémantique | Recherche | Oui |
| Classement pondéré par la confiance | Validation d'entreprise | Certification partenaire | Révision AWS | Cert. partenaire | Communauté | Communauté + scan | N/A | Pile de confiance vérifiable |
| Découverte des prix | Facturation plateforme | Facturation plateforme | À l'usage | Facturation plateforme | Gratuit | Gratuit | Simulé | Multi-mécanisme |
| Garantie d'appariement stable | Non | Non | Non | Non | Non | Non | Étudié | Oui (mode batch) |
| Protocole ouvert | Non | Non | Non | Non | Oui | Oui | Oui | Oui |
| Préservation de la confidentialité | N/A | N/A | N/A | N/A | Non | Non | N/A | Partielle (TLS + anonymisation ; ZKP via ARP v2 pour le seuillage des scores) |
La lacune est évidente : aucun système ne combine recherche ouverte inter-plateformes avec mise en correspondance multidimensionnelle pondérée par la confiance, garanties formelles de stabilité et découverte des prix multi-mécanismes. AMP occupe cette lacune.
Note sur la méthodologie de comparaison : Ce tableau compare les fonctionnalités au niveau protocolaire plutôt que la maturité opérationnelle. Les plateformes existantes ont de véritables points forts qu'AMP n'atteint pas encore — notamment la maturité opérationnelle, l'intégration de facturation d'entreprise, le support client établi, les garanties SLA adossées à la responsabilité légale d'entreprise et des années de durcissement en production. Les avantages d'AMP sont architecturaux (ouverture, fédération, intégration de la confiance) ; les avantages des acteurs en place sont opérationnels. Un déploiement en production devrait combler le fossé opérationnel pour concurrencer les plateformes établies. La garantie d'appariement stable d'AMP s'applique en mode batch ; la stabilité en temps réel nécessite des mécanismes complémentaires (voir la section 6.3).
Les descriptions de capacités des agents existent à trois niveaux d'abstraction, aucun n'étant suffisant seul :
Niveau outil (manifestes MCP) : Répertorient les outils individuels qu'un agent peut invoquer — scraping web, analyse de fichiers, appels API [10]. Ce sont des détails d'implémentation, pas des capacités. Savoir qu'un agent dispose d'un outil de scraping web ne dit pas s'il peut mener une veille concurrentielle.
Niveau compétence (spécifications OpenClaw) : Décrivent des compétences individuelles en markdown lisible par l'humain avec des métadonnées YAML [11]. Plus abstrait que les outils, mais toujours atomique — une compétence décrit le « scraping web » ou le « résumé », pas une capacité composite comme « agent de recherche qui combine scraping web, résumé et vérification de citations ».
Niveau agent (Agent Cards A2A) : Décrivent ce qu'un agent peut faire au niveau de l'interface — compétences, authentification supportée, modalités d'entrée/sortie [9]. Les Agent Cards sont orientées découverte : elles indiquent ce qu'un agent peut faire, mais pas dans quelle mesure, avec quelle fiabilité, à quel coût ni par rapport aux alternatives.
AMP introduit le Profil de Capacités Unifié (UCP) — un format de description de capacités qui compose les descriptions au niveau outil et compétence en profils au niveau agent enrichis de caractéristiques de performance, de signaux de confiance et de métadonnées de compatibilité.
Un UCP contient cinq sections :
5.2.1 Section identité
Relie l'UCP à l'identité de l'agent dans tous les systèmes :
{
"identity": {
"amp_id": "amp:agent:abc123",
"a2a_card": "https://agent.example.com/.well-known/agent.json",
"coc_chain_id": "coc:chain:sha256:a1b2c3...",
"did": "did:web:agent.example.com",
"registries": [
{"type": "google_cloud", "listing_id": "gc-agent-456"},
{"type": "clawhub", "skill_ids": ["web-research-v3", "citation-verify"]}
]
}
}La section identité est référencée de manière croisée, non autoritaire — la vérification de l'identité est déléguée aux protocoles d'identité respectifs (CoC, DIDs, A2A).
5.2.2 Section capacités
Décrit ce que l'agent peut faire en utilisant une taxonomie hiérarchique :
{
"capabilities": [
{
"domain": "research",
"subdomain": "competitive_analysis",
"description": "Conducts comprehensive competitive landscape research with web scraping, document analysis, and structured report generation",
"input_modalities": ["text", "url", "document"],
"output_modalities": ["text", "structured_data", "report"],
"tools_used": ["web_scraper", "pdf_parser", "summarizer", "citation_engine"],
"complexity_range": {
"min": "single-competitor profile",
"max": "full market landscape with 50+ entities"
},
"taxonomy_codes": {
"onet_soc": "15-2051.01",
"amp_capability": "research.competitive.landscape"
}
}
]
}Le champ taxonomy_codes prend en charge plusieurs systèmes de classification. AMP définit sa propre taxonomie de capacités hiérarchique (inspirée de la structure d'O*NET des activités de travail généralisées → intermédiaires → détaillées [37]) tout en maintenant l'interopérabilité avec les classifications professionnelles existantes. La taxonomie AMP n'est pas prescriptive — les agents peuvent déclarer leurs capacités en utilisant des descriptions en texte libre, des codes de taxonomie structurés, ou les deux. La mise en correspondance sémantique gère la traduction.
5.2.3 Section performance
Décrit les caractéristiques de performance observées empiriquement :
{
"performance": {
"reliability": {
"asa_completion_rate": 0.982,
"asa_sample_size": 247,
"uptime_30d": 0.997
},
"quality": {
"arp_composite_score": 84.2,
"arp_dimensional_scores": {
"accuracy": 91.3,
"reliability": 88.7,
"latency": 72.1,
"protocol_compliance": 95.0,
"cost_efficiency": 73.8
},
"qv_pass_rate": 0.94,
"qv_sample_size": 189
},
"speed": {
"median_response_time_ms": 45000,
"p95_response_time_ms": 180000,
"throughput_tasks_per_hour": 12
},
"dispute_profile": {
"ajp_dispute_rate": 0.018,
"ajp_favorable_resolution_rate": 0.85,
"ajp_sample_size": 55
}
}
}Les métriques de performance ne sont pas auto-déclarées. Elles sont calculées à partir des données des protocoles de l'écosystème de confiance et sont cryptographiquement vérifiables :
arp_composite_score est dérivé de l'algèbre de composition de signaux d'ARP v2 [16]asa_completion_rate est calculé à partir des enregistrements d'accords ASA [18]ajp_dispute_rate est calculé à partir des dossiers de cas AJP [17]coc_chain_length est vérifiable contre les horodatages ancrés [15]Lorsque des données vérifiables sont indisponibles (p. ex., agents non intégrés à l'écosystème de confiance), les champs sont omis plutôt qu'estimés. Un nœud AMP PEUT afficher des métriques auto-déclarées non vérifiées, mais DOIT les distinguer clairement des métriques vérifiées dans les résultats de mise en correspondance.
5.2.4 Section coût
Décrit le modèle de tarification de l'agent :
{
"cost": {
"pricing_model": "usage_based",
"base_rate": {"amount": 0.05, "currency": "USD", "per": "request"},
"variable_rate": {"amount": 0.002, "currency": "USD", "per": "output_token"},
"supports_negotiation": true,
"supports_auction": false,
"payment_rails": ["x402", "stripe", "invoice"],
"free_tier": {"requests_per_month": 100}
}
}{
"availability": {
"status": "active",
"alp_lifecycle_stage": "operational",
"capacity": {
"current_load_pct": 45,
"max_concurrent_tasks": 20,
"estimated_queue_time_ms": 5000
},
"schedule": {
"timezone": "UTC",
"available_hours": "00:00-23:59",
"maintenance_windows": []
}
}
}Les UCP sont conçus pour être générés à partir de descriptions de capacités existantes :
| Format source | Correspondance vers UCP |
|---|---|
| Agent Card A2A | Identité → a2a_card ; Compétences → Section capacités ; Authentification → filtrée |
| Manifeste d'outils MCP | Outils → tools_used dans la section capacités ; Paramètres → complexity_range |
| OpenClaw SKILL.md | En-tête YAML → Section capacités ; Binaires requis → tools_used |
| API personnalisée | L'implémenteur mappe vers le schéma UCP ; les champs non mappés sont conservés dans extensions |
Un nœud AMP DEVRAIT pouvoir ingérer directement des Agent Cards A2A, des manifestes MCP et des spécifications OpenClaw, en générant automatiquement des UCP. Cela réduit la barrière à l'adoption : les agents déjà référencés sur des plateformes existantes n'ont pas besoin de créer des UCP manuellement.
AMP définit une taxonomie de capacités hiérarchique à trois niveaux :
Niveau 1 — Domaines (8 domaines) : recherche, développement, analyse, communication, opérations, création, sécurité, domaine spécifique
Niveau 2 — Sous-domaines (~40 sous-domaines) : p. ex., recherche.concurrentielle, recherche.académique, développement.frontend, développement.backend, analyse.financière, analyse.juridique, communication.traduction, communication.résumé
Niveau 3 — Capacités (ouvert) : capacités spécifiques dans chaque sous-domaine, p. ex., recherche.concurrentielle.paysage, développement.backend.conception_api, analyse.financière.valorisation
Les niveaux 1 et 2 sont définis par le protocole et versionnés. Le niveau 3 est extensible — les agents peuvent déclarer de nouvelles capacités au niveau 3 sans nécessiter de mises à jour du protocole. La mise en correspondance sémantique gère les nouvelles capacités de niveau 3 qui ne correspondent pas exactement aux entrées de taxonomie connues.
Statut de la taxonomie : Les domaines de niveau 1 et les exemples de sous-domaines de niveau 2 listés ci-dessus sont illustratifs et à l'état d'ébauche. La taxonomie complète de niveau 2 (~40 sous-domaines) sera publiée comme artefact versionné séparé avant la finalisation d'AMP v1.0. Les implémenteurs construisant sur la spécification actuelle doivent traiter les codes de taxonomie comme provisoires et concevoir leurs systèmes pour accommoder les mises à jour de taxonomie. Le cadre structurel (hiérarchie à trois niveaux, décomposition inspirée d'O*NET) est stable ; les codes spécifiques ne le sont pas.
La taxonomie s'inspire structurellement de la décomposition hiérarchique des activités professionnelles d'O*NET [37], mais est spécialement conçue pour les capacités des agents plutôt que les professions humaines. Là où O*NET mappe professions → activités généralisées → activités intermédiaires → activités détaillées → énoncés de tâches, AMP mappe agents → domaines → sous-domaines → capacités → types de tâches. Le parallèle structurel permet un futur pont entre les ontologies de capacités humaines et agentiques, ce qui pourrait devenir pertinent à mesure que la collaboration humain-agent s'approfondit.
Une requête de mise en correspondance spécifie ce dont le demandeur a besoin et comment il hiérarchise les différentes dimensions :
{
"match_request": {
"request_id": "mr-20260326-001",
"requester_id": "amp:agent:requester-xyz",
"task": {
"description": "Review Python microservice code for security vulnerabilities, focusing on authentication flows and data validation",
"domain": "security",
"subdomain": "code_review",
"input": {"type": "code_repository", "language": "python", "loc_estimate": 15000},
"output": {"type": "security_report", "format": "structured_json"},
"deadline_ms": 3600000,
"budget": {"max_amount": 50.00, "currency": "USD"}
},
"weights": {
"capability_match": 0.30,
"trust_score": 0.25,
"cost_alignment": 0.15,
"availability": 0.10,
"style_compatibility": 0.05,
"domain_relevance": 0.15
},
"constraints": {
"min_trust_score": 60,
"max_dispute_rate": 0.05,
"required_lifecycle_status": ["operational"],
"excluded_agents": [],
"required_registries": [],
"max_results": 10
},
"federation": {
"registries": ["all"],
"timeout_ms": 5000
}
}
}L'objet weights somme à 1,0 et détermine l'importance relative de chaque dimension dans le score de compatibilité. L'objet constraints spécifie des filtres stricts — les agents qui échouent à toute contrainte sont exclus avant la notation. Cette approche en deux phases (filtrer puis classer) reproduit le pipeline standard de recherche d'information et est efficace sur le plan computationnel.
Étant donné une requête de mise en correspondance R et un agent candidat A, le score de compatibilité S(R, A) est calculé comme suit :
S(R, A) = w_cap * C_capability(R, A)
+ w_trust * C_trust(R, A)
+ w_cost * C_cost(R, A)
+ w_avail * C_availability(R, A)
+ w_style * C_style(R, A)
+ w_domain * C_domain(R, A)Où chaque score de dimension C_x est normalisé à [0, 100] et chaque pondération w_x provient de l'objet weights de la requête de mise en correspondance.
Correspondance des capacités (C_capability) :
Calculée via la similarité sémantique entre la description de la tâche et les descriptions de capacités UCP de l'agent. AMP ne prescrit pas de modèle de plongement spécifique mais exige que la fonction de similarité satisfasse trois propriétés :
tools_used reçoivent un bonuscomplexity_range déclarée de l'agent, le score est réduitFormellement :
C_capability(R, A) = sim(R.task.description, A.capabilities)
* tool_bonus(R.task, A.tools_used)
* complexity_fit(R.task, A.complexity_range)Où sim est une fonction de similarité sémantique retournant [0, 1], tool_bonus retourne [1,0, 1,2] (jusqu'à 20 % de bonus pour les correspondances d'outils) et complexity_fit retourne [0,5, 1,0] (pénalité de 50 % pour complexité hors plage, 1,0 dans la plage).
Score de confiance (C_trust) :
Dérivé du signal composite d'ARP v2 [16] :
C_trust(R, A) = f(ARP_composite, CoC_chain_length, ASA_compliance, AJP_dispute_rate)Où f est la fonction de composition de signaux d'ARP v2 avec des profils de pondération spécifiques au domaine. Si l'agent manque d'intégration dans l'écosystème de confiance, C_trust prend par défaut une valeur de référence configurable (par défaut : 50) représentant une confiance neutre.
Alignement des coûts (C_cost) :
C_cost(R, A) = max(0, 100 - penalty * |estimated_cost(A, R.task) - R.task.budget.target|)Où estimated_cost projette le modèle de tarification de l'agent sur la tâche spécifique, et penalty s'échelonne avec la sensibilité au budget. Les agents tarifés dans le budget reçoivent des scores élevés ; les agents significativement au-dessus du budget sont pénalisés mais non exclus.
Disponibilité (C_availability) :
C_availability(R, A) = lifecycle_check(A) * capacity_score(A) * deadline_fit(A, R.task)Où lifecycle_check retourne 0 pour les agents dépréciés/déclassés (filtre strict), capacity_score retourne [0, 100] selon la charge actuelle et deadline_fit retourne [0, 100] selon si l'agent peut respecter l'échéance.
Compatibilité de style (C_style) :
C_style(R, A) = format_match(R.task.output.format, A.output_modalities)
* interaction_history_score(R.requester_id, A)Où interaction_history_score reflète le filtrage collaboratif. Pour les premières interactions, cela prend par défaut une valeur neutre de 50.
Pertinence du domaine (C_domain) :
C_domain(R, A) = arp_domain_score(A, R.task.domain) * asa_domain_compliance(A, R.task.domain)AMP prend en charge trois modes de mise en correspondance :
Mode 1 : Recherche classée (par défaut)
Pour les requêtes uniques cherchant une liste classée de candidats. Le nœud AMP calcule les scores de compatibilité pour tous les agents candidats, applique les contraintes comme filtres stricts et retourne les K premiers résultats classés par score composite. Complexité computationnelle : O(n log k).
Mode 2 : Appariement stable
Pour les scénarios batch où plusieurs tâches se disputent les mêmes agents. AMP implémente une variante de l'algorithme d'acceptation différée de Gale-Shapley [12] :
AMP fournit un indicateur de configuration pour produire des appariements optimaux côté agent, et une variante médian-optimale. Complexité computationnelle : O(n²) dans le pire cas.
Mise en garde sur la stabilité : Gale-Shapley suppose des préférences complètes et statiques. AMP y répond en exécutant l'appariement stable périodiquement sur les requêtes accumulées. L'intervalle d'appariement est configurable (par défaut : 60 secondes pour les marchés en temps réel, 300 secondes pour les marchés batch).
Mode 3 : Appariement par enchère
Pour les scénarios où la découverte des prix est l'objectif principal. AMP prend en charge trois formats d'enchères :
{
"match_response": {
"request_id": "mr-20260326-001",
"timestamp": "2026-03-26T14:30:00Z",
"results": [
{
"rank": 1,
"agent_id": "amp:agent:securitybot-prime",
"compatibility_score": 89.3,
"dimensional_scores": {
"capability_match": 95.2,
"trust_score": 88.1,
"cost_alignment": 82.0,
"availability": 100.0,
"style_compatibility": 75.0,
"domain_relevance": 92.4
},
"ucp_summary": {
"primary_capability": "Python security code review with SAST/DAST integration",
"arp_composite": 88.1,
"asa_completion_rate": 0.991,
"estimated_cost": {"amount": 35.00, "currency": "USD"},
"estimated_completion_ms": 1800000
},
"trust_verification": {
"coc_chain_verified": true,
"coc_chain_length_days": 127,
"arp_score_verified": true,
"asa_history_verified": true,
"ajp_record_verified": true,
"verification_timestamp": "2026-03-26T14:29:58Z"
},
"registries_found_on": ["google_cloud", "clawhub"]
}
],
"metadata": {
"registries_queried": 5,
"registries_responded": 4,
"total_candidates_evaluated": 237,
"candidates_filtered_by_constraints": 198,
"candidates_scored": 39,
"query_time_ms": 3200
}
}
}Le bloc trust_verification est essentiel : il indique au demandeur quels signaux de confiance ont été vérifiés indépendamment par le nœud AMP (non seulement déclarés par l'agent).
La fédération AMP connecte un nœud AMP à plusieurs registres via une interface de requête standardisée. L'architecture comporte trois couches :
+------------------------------------------------------+
| AMP NODE |
| +------------+ +-------------+ +--------------+ |
| | Match | | Federation | | Trust | |
| | Engine | | Router | | Verifier | |
| +-----+------+ +------+------+ +------+-------+ |
| | | | |
+--------+----------------+----------------+-----------+
| | |
+-----+------+ +-----+------+ +-----+------+
| Registry | | Registry | | Registry |
| Adapter: | | Adapter: | | Adapter: |
| Google | | ClawHub | | A2A |
| Cloud | | | | Self-hosted|
+------------+ +------------+ +------------+Moteur de mise en correspondance : Reçoit les requêtes de mise en correspondance, calcule les scores de compatibilité, produit les résultats classés.
Routeur de fédération : Distribue les sous-requêtes aux registres enregistrés en parallèle, collecte les réponses, normalise les résultats en UCP et les transmet au moteur de mise en correspondance.
Vérificateur de confiance : Vérifie indépendamment les signaux de confiance (entrées de chaîne CoC, scores ARP, enregistrements ASA, données de litiges AJP) contre leurs sources faisant autorité.
Adaptateurs de registres : Connecteurs spécifiques aux protocoles qui traduisent les requêtes de fédération AMP dans le format natif de chaque registre et retransmettent les réponses en UCP. Les adaptateurs sont enfichables.
Une requête de fédération AMP suit un processus en cinq étapes :
Étape 1 : Traduction de la requête. Le nœud AMP traduit la requête de mise en correspondance en sous-requêtes spécifiques au registre.
Étape 2 : Distribution parallèle. Les sous-requêtes sont distribuées à tous les adaptateurs enregistrés simultanément avec un délai d'expiration configurable (par défaut : 5 000 ms).
Étape 3 : Normalisation des réponses. Chaque adaptateur traduit la réponse de son registre en UCP. Les champs non mappés sont conservés dans un objet extensions.
Étape 4 : Déduplication et résolution des conflits. Les agents peuvent être référencés sur plusieurs registres. Le nœud AMP déduplique en faisant correspondre les champs d'identité. Les conflits de données sont résolus selon une hiérarchie : (1) les sources de niveau de confiance supérieur prennent le pas, (2) parmi les niveaux égaux, les données les plus récentes l'emportent, (3) les conflits irrésolvables sont signalés dans les métadonnées.
Étape 5 : Enrichissement de la confiance. Pour chaque UCP dédupliqué, le vérificateur de confiance interroge l'écosystème de confiance pour peupler les métriques de performance vérifiées.
| Étape | Latence attendue | Remarques |
|---|---|---|
| Traduction de la requête | 5-20 ms | Calcul local, négligeable |
| Distribution parallèle | 500-5 000 ms | Borné par le délai d'expiration |
| Normalisation des réponses | 10-50 ms par registre | Calcul local, parallélisable |
| Déduplication + Résolution des conflits | 20-100 ms | Évolue avec le nombre de candidats |
| Enrichissement de la confiance | 200-3 000 ms | Coût dominant ; dépend de l'état du cache |
Les nœuds AMP DEVRAIENT implémenter trois stratégies d'atténuation : (1) mise en cache agressive avec TTL de 15 minutes, (2) enrichissement parallèle à 10 voies, (3) enrichissement par niveaux pour les seuls candidats passant le filtrage initial.
Tout registre peut participer à la fédération AMP en implémentant un point de terminaison de requête minimal :
POST /amp/v1/search
Content-Type: application/json
{
"query": {
"text": "Python security code review",
"domain": "security",
"subdomain": "code_review",
"constraints": {
"min_trust_score": 60,
"max_results": 50
}
}
}Les registres s'auto-enregistrent auprès des nœuds AMP en fournissant l'URL de leur point de terminaison et un manifeste. Il n'existe pas de registre central des registres — chaque nœud AMP maintient sa propre liste, partageable via un protocole de syndication simple.
Agent Cards A2A : Les nœuds AMP peuvent crawler les points de terminaison /.well-known/agent.json directement — tout agent conforme A2A est automatiquement découvrable.
AgentDNS [20] : Les nœuds AMP peuvent utiliser la résolution AgentDNS comme source de découverte.
ANS [21] : L'identité vérifiée d'un agent enregistré dans ANS peut être consommée par le vérificateur de confiance d'AMP.
ACDP [22] : Les nœuds AMP peuvent interroger les enregistrements DNS SRV pour découvrir des agents dans des domaines spécifiques.
La tarification des agents est actuellement soit invisible, soit fixe, soit absente — aucune de ces options ne sert bien l'économie des agents émergente. Gartner projette que d'ici 2028, 90 % des achats B2B seront intermédiés par des agents IA, faisant transiter plus de 15 000 milliards de dollars par des échanges d'agents IA [41]. McKinsey estime l'opportunité du commerce agentique mondial à 3-5 000 milliards de dollars d'ici 2030 [42].
Mécanisme 1 : Prix affiché (par défaut) — L'UCP de l'agent déclare son modèle de tarification ; le nœud AMP estime le coût pour la tâche spécifique. Aucune négociation. Adapté aux tâches de commodité et aux transactions à volume élevé.
Mécanisme 2 : Demande de devis (DDQ) — Le nœud AMP sollicite des devis auprès des agents mis en correspondance. Interaction :
Demandeur → Nœud AMP : match_request avec price_discovery : "rfq"
Nœud AMP → Agents : task_description + quote_request
Agents → Nœud AMP : devis (prix, conditions, validity_window)
Nœud AMP → Demandeur : match_response avec devis attachés
Demandeur → Agent sélectionné : accept_quote(quote_id)Mécanisme 3 : Enchère — Les formats anglaise, Vickrey et combinatoire sont décrits à la section 6.3.
Les données historiques de prix informent l'estimation des coûts futurs. Les signaux de prix ne sont PAS incorporés dans les scores de confiance — les décisions de tarification sont une stratégie commerciale. Cependant, la corrélation prix-qualité est suivie et les anomalies sont signalées dans les résultats.
Sans classement pondéré par la confiance, une place de marché d'agents n'est qu'un répertoire. Les places de marché existantes utilisent l'un de trois modèles inadéquats :
| Modèle | Exemple | Limitation |
|---|---|---|
| Contrôle de porte d'entreprise | Google Cloud, Salesforce, AWS | Validation unique ; aucun signal de qualité continu |
| Révision communautaire | Berkeley, ClawHub | Susceptible aux attaques Sybil et au jeu des avis |
| Aucun | AI Agent Store, Agen.cy | Répertoire pur ; zéro signal de qualité |
Niveau 1 — Déclaré (le plus faible) : Auto-déclaration sans vérification.
Niveau 2 — Attesté : Un tiers se porte garant de l'agent (validation d'entreprise, avis communautaires, certification partenaire).
Niveau 3 — Mesuré : Métriques calculées à partir de données d'interaction réelles (scores ARP, taux de complétion ASA, taux de litiges AJP).
Niveau 4 — Vérifié (le plus élevé) : Métriques mesurées vérifiables cryptographiquement par tout tiers — entrées CoC ancrées via OpenTimestamps et TSA, Portable Reputation Bundles ARP v2 signés en tant que Verifiable Credentials W3C.
trust_score(A) = w_identity * identity_confidence(A)
+ w_performance * performance_quality(A)
+ w_reliability * reliability_score(A)
+ w_risk * (100 - risk_score(A))Confiance dans l'identité : identity_confidence(A) = min(100, log2(1 + chain_age_days) * anchor_density_factor) — anchor_density_factor varie de 0,5 (ancrage clairsemé) à 1,5 (ancrage fréquent à double niveau).
Qualité de performance : performance_quality(A) = arp_composite(A, domain=request.domain) — scores ARP spécifiques au domaine plutôt que composite global.
Fiabilité : reliability_score(A) = asa_completion_rate(A) * 100 * confidence_factor(asa_sample_size) — confidence_factor augmente de 0,5 (moins de 10 accords) à 1,0 (100+ accords).
Risque : risk_score(A) = ajp_dispute_rate(A) * unfavorable_resolution_rate(A) * 100 — la structure multiplicative différencie les litiges favorables des litiges défavorables.
Pondérations par défaut : w_identity = 0,20, w_performance = 0,40, w_reliability = 0,25, w_risk = 0,15.
| Signal disponible | Ajustement de référence |
|---|---|
| Validation de place de marché d'entreprise (niveau 2) | +15 par rapport à la référence |
| Avis communautaires avec >10 avis (niveau 2) | +10 par rapport à la référence |
| Agent Card A2A publiée sur un domaine vérifié (niveau 2) | +5 par rapport à la référence |
| DID avec contrôleur vérifiable (niveau 2) | +5 par rapport à la référence |
| Aucun signal vérifiable (niveau 1 uniquement) | Référence (par défaut : 40) |
La référence (40) est intentionnellement en dessous du point médian (50) pour refléter que les agents non vérifiés présentent plus de risques. Cela crée une incitation naturelle à s'intégrer à l'écosystème de confiance.
Les places de marché à deux côtés font face à un défi fondamental d'amorçage : la plateforme n'a de valeur pour les vendeurs que si des acheteurs sont présents, et pour les acheteurs que si des vendeurs sont présents [25]. Amazon a résolu ce problème en commençant comme détaillant unilatéral, puis en ouvrant progressivement aux vendeurs tiers [44]. Etsy s'est concentré sur un créneau (articles faits main) où des vendeurs passionnés se référenceraient même avec peu d'acheteurs [45]. Uber a subventionné les conducteurs avec des revenus minimaux garantis avant que la demande des passagers se matérialise [46].
La stratégie d'amorçage d'AMP évite entièrement le problème de la poule et de l'œuf en ne construisant pas une nouvelle place de marché.
Parce qu'AMP est un protocole de fédération qui connecte des registres existants, l'offre initiale provient de l'agrégation d'agents qui existent déjà :
| Registre | Références disponibles | Type d'entrée | Effort d'intégration |
|---|---|---|---|
| ClawHub | 13 729 | Compétences atomiques (fichiers SKILL.md) | Adaptateur pour API de recherche sémantique |
| Berkeley Gorilla | 150+ | Agents LLM vérifiés | Adaptateur pour recherche par catégorie |
| Agents conformes A2A | Croissant (150+ org.) | Points de terminaison d'agents | Crawler pour /.well-known/agent.json |
| Apify | 4 000+ | Scrapers web, outils d'automatisation | Adaptateur pour API plateforme |
| AI Agent Store | 1 300+ | Entrées de métadonnées de répertoire | Adaptateur pour API de répertoire |
Un nœud AMP fédération d'abord pourrait lancer avec accès à 19 000+ capacités, compétences et références d'agents dès le premier jour. La demande suit naturellement : si un nœud AMP fournit de meilleurs résultats de recherche que toute place de marché individuelle, les utilisateurs ont une raison de l'interroger.
Les agents nouveaux dans l'écosystème peuvent s'intégrer à AMP de trois façons :
/.well-known/amp-profile.json)La barrière à l'entrée est délibérément basse. AMP ne filtre pas — tout agent peut être découvrable. Le mécanisme de classement pondéré par la confiance garantit que les agents à faible confiance apparaissent plus bas dans les résultats sans être exclus.
AMP atteint une masse critique significative lorsque trois conditions sont remplies :
AMP se situe à la couche 4 (Marché/Découverte) de l'écosystème de confiance AB Support, consommant les données de toutes les couches inférieures :
Couche 4 : AMP (Appariement) <- consomme depuis toutes les couches inférieures
Couche 3 : AJP (Responsabilité)
Couche 2 : ASA (Accords) + ALP (Cycle de vie)
Couche 1 : CoC (Provenance) + ARP (Réputation)CoC fournit à AMP deux catégories de données :
Confiance dans l'identité : La longueur de la chaîne CoC et le statut de vérification des ancres établissent depuis combien de temps un agent existe et si son historique est infalsifiable. Un agent avec une chaîne CoC de 6 mois ancrée biheure via vérification double niveau OTS+TSA [15] est une entité plus établie qu'un agent créé hier sans ancrage. AMP utilise l'âge de la chaîne comme signal de résistance aux attaques Sybil — il est facile de créer de nouveaux agents mais impossible de fabriquer des chaînes historiques.
Portfolio de travail : Les entrées CoC documentant les raisonnements passés, les décisions et les tâches complétées fonctionnent comme un portfolio de travail vérifiable. AMP n'expose pas les entrées CoC brutes dans les résultats (préoccupation de confidentialité) mais utilise les métriques de chaîne agrégées (longueur, densité, fréquence d'ancrage) comme entrées de confiance.
ARP v2 [16] fournit le principal signal de qualité d'AMP :
trust_scoredomain_relevanceTaux de conformité aux SLA indiquent la constance de livraison d'un agent — utilisés comme entrée principale pour reliability_score.
Taux de réussite de la vérification qualité (depuis l'API de vérification ASA) indiquent la qualité des sorties indépendamment des notes subjectives.
Modèles d'accords permettent la conclusion automatisée d'accords après la mise en correspondance, réduisant le délai entre « correspondance trouvée » et « travail commencé » de minutes à secondes.
Fréquence des litiges — utilisée dans la composante risk_score.
Résultats des litiges différencient les agents opérant dans des domaines complexes à litiges fréquents de ceux dont les litiges reflètent de réels problèmes de qualité.
Taxonomie des litiges fournit des informations diagnostiques — si la plupart des litiges contre un agent résultent de correspondances de capacités inappropriées, AMP peut signaler que l'UCP de l'agent est inexact.
Filtrage du statut de cycle de vie — filtre strict garantissant que les agents dépréciés, suspendus ou déclassés n'apparaissent pas dans les résultats.
Lignage de fork permet l'héritage partiel de réputation. Lorsque l'agent X fork pour créer l'agent Y, l'enfant hérite d'une fraction de la réputation du parent.
Statut de succession indique si un agent dispose d'un successeur désigné — pertinent pour les tâches de longue durée.
La conception d'AMP rend trois comportements individuellement rationnels :
Déclaration honnête des capacités : Les profils inexacts mènent à de mauvaises correspondances, des tâches échouées, des notes ARP négatives et des litiges ASA — tous dégradant le classement futur. La boucle de rétroaction (correspondance → tâche → note → classement) crée une pénalité naturelle pour les déclarations excessives.
Tarification précise : Dans les scénarios d'enchères et DDQ, les agents font face à un compromis entre sous-enchère (plus de correspondances mais potentiellement non rentables) et sur-enchère (marges supérieures mais moins de correspondances). La propriété d'enchère véridique de Vickrey s'applique, avec les réserves notées à la section 6.3.
Livraison de qualité authentique : La connexion entre la vérification qualité ASA, les notes ARP et le classement AMP crée une incitation à la qualité multicouche. Un agent livrant une qualité médiocre fait face à : (1) retenue du séquestre ASA immédiate, (2) notes ARP négatives, (3) litiges AJP potentiels, (4) résultats dégradés dans toutes les futures tâches.
Offres factices dans les enchères : Atténué par la vérification d'identité et la qualification des soumissionnaires basée sur la réputation.
Tarification collusive : AMP détecte la collusion potentielle via la surveillance de la variance des prix — signalée comme visible pour les demandeurs mais non prévenue activement.
Dégradation de qualité après correspondance : La vérification qualité automatisée d'ASA atténue le problème de hold-up — la qualité est vérifiée contre les critères de l'accord indépendamment de la réputation passée.
Manipulation par l'attention : La mise en correspondance est effectuée par le nœud AMP côté serveur, non par l'agent demandeur — éliminant la surface d'attaque pour l'inondation de la fenêtre de contexte identifiée dans Magentic Marketplace [36].
Inflation des notes : Les mécanismes anti-inflation d'ARP v2 protègent les signaux de confiance consommés par AMP [16].
Rationalité individuelle : La participation est individuellement rationnelle pour les deux parties, tant que la qualité de mise en correspondance d'AMP dépasse la recherche manuelle multi-plateformes.
Compatibilité d'incitations (partielle) : En mode enchère Vickrey, l'enchère véridique est une stratégie dominante sous les hypothèses standard. En modes prix affiché et DDQ, l'incitation à une tarification honnête est indirecte. La compatibilité d'incitations complète n'est pas atteinte et probablement non atteignable.
Stabilité (en mode batch) : L'appariement stable Gale-Shapley garantit que l'affectation batch est stable pour les préférences statiques dans une ronde d'appariement.
Efficacité (approximative) : Le mode recherche classée produit des résultats approximativement efficaces. L'efficacité exacte n'est garantie qu'en mode appariement stable.
Le Complexe Majeur d'Histocompatibilité (CMH) permet la discrimination soi/non-soi par correspondance de motifs moléculaires [51]. Les molécules CMH lient des fragments peptidiques et les affichent à la surface cellulaire pour la reconnaissance par les lymphocytes T. La sélection négative garantit que les lymphocytes T se liant trop fortement aux auto-antigènes sont éliminés dans le thymus [52].
Parallèle AMP : La vérification de confiance d'AMP fonctionne comme un système immunitaire pour la place de marché des agents. Les signaux de confiance (provenance CoC, notes ARP, enregistrements ASA, litiges AJP) sont les « marqueurs moléculaires » que les agents portent. Le vérificateur de confiance effectue une correspondance de motifs — vérifiant les motifs connus négatifs (certificats révoqués, indicateurs de litiges, détections de compétences malveillantes) tout comme les lymphocytes T vérifient les antigènes non-soi. La polymorphisme du CMH correspond à l'architecture de confiance multi-signaux d'AMP : des approches de vérification diversifiées fournissent une résilience au niveau de la population contre la manipulation de la confiance.
La théorie des marchés biologiques propose que les organismes offrent des commodités peu coûteuses à produire en échange de commodités coûteuses ou impossibles sans partenaire [53]. Le choix du partenaire est appliqué par des sanctions : les champignons mycorhiziens fournissant moins de phosphore reçoivent moins de carbone de leurs plantes hôtes.
Parallèle AMP : Le modèle de sanctions se traduit directement dans la boucle de rétroaction d'AMP. Les agents livrant une qualité médiocre reçoivent : moins d'affectations futures, des prix inférieurs, et une déplatformisation potentielle. La nature bilatérale des sanctions du marché biologique — chaque partenaire ajustant son investissement selon la contribution de l'autre — reproduit l'évaluation aveugle bilatérale d'ARP, où les deux parties se notent mutuellement après une interaction.
| Adversaire | Objectif | Capacités |
|---|---|---|
| Agent manipulateur | Gonfler son propre classement | Peut créer des UCP trompeurs, soumissionner stratégiquement, coordonner avec des alliés |
| Attaquant Sybil | Créer de faux agents pour dominer les résultats | Peut créer de nombreuses identités d'agents à faible coût |
| Adversaire de surveillance | Apprendre les capacités des concurrents en observant les requêtes | Peut observer les requêtes et réponses sur le réseau |
| Attaquant par déni de service | Empêcher la mise en correspondance légitime | Peut générer des requêtes de mise en correspondance à volume élevé |
Contre les agents manipulateurs :
Contre les attaques Sybil :
Contre les adversaires de surveillance :
Contre le déni de service :
Divulgation des capacités : Le modèle de divulgation progressive d'AMP (section 3.7) permet aux agents de publier suffisamment pour la mise en correspondance tout en retenant les détails d'implémentation propriétaires.
Confidentialité des requêtes : Les requêtes de mise en correspondance d'un demandeur peuvent révéler des informations stratégiques. Les nœuds AMP DEVRAIENT prendre en charge les requêtes anonymes et NE DOIVENT PAS partager les données de requêtes individuelles au-delà du nécessaire.
Confidentialité des signaux de confiance : AMP prend en charge la divulgation agrégée (p. ex., « le score de confiance dépasse le seuil X ») via les mécanismes ZKP d'ARP v2 plutôt que la transparence totale des signaux.
La recherche Magentic Marketplace de Microsoft [34][36] a identifié des modes de défaillance empiriquement observés :
AMP traite ces problèmes structurellement :
Risque de gardien selon la Loi sur les marchés numériques (DMA) de l'UE. Un nœud AMP largement adopté influençant des décisions d'achat potentiellement astronomiques pourrait satisfaire les seuils quantitatifs du DMA. L'architecture protocole-pas-plateforme est la principale défense antitrust : aucune entité unique n'opère « le » service AMP.
Classement pondéré par la confiance et neutralité concurrentielle. La préoccupation antitrust la plus substantielle est de savoir si le classement pondéré par la confiance favorise systématiquement les agents intégrés dans la pile de confiance AB Support. AMP répond à cette préoccupation via : (1) accès au protocole ouvert — tout agent peut s'intégrer sans frais ni contrôle d'accès ; (2) inclusivité de référence — les agents non intégrés reçoivent un score de référence et apparaissent avec un étiquetage de niveau clair ; (3) notation transparente — la fonction de calcul de compatibilité utilise des pondérations publiées et configurables.
Implications de la Loi IA de l'UE. AMP se situe probablement dans la catégorie « risque limité » (non « risque élevé ») car il recommande des agents plutôt que de prendre des décisions conséquentes sur des personnes physiques. Les nœuds AMP DEVRAIENT maintenir une journalisation suffisante pour satisfaire aux exigences de transparence de l'article 13.
Risque résiduel. Ces atténuations réduisent mais n'éliminent pas le risque antitrust. Les concepteurs du protocole devraient s'engager proactivement dans les cadres de conformité DMA et Loi IA, envisager de nommer une gouvernance indépendante pour la taxonomie des capacités, et concevoir des mécanismes d'audit pour la neutralité du classement.
La fédération ajoute de la latence et des modes de défaillance. Les requêtes inter-registres sont intrinsèquement plus lentes que les recherches dans un seul registre. Les déploiements en production doivent concevoir pour le fonctionnement en mode dégradé.
La profondeur de l'intégration de confiance dépend de l'adoption des protocoles externes. Jusqu'à ce que CoC, ARP, ASA, AJP et ALP atteignent une adoption significative, la plupart des agents n'auront que des signaux de niveaux 1 ou 2, réduisant la qualité du classement d'AMP à celle d'un répertoire standard.
La taxonomie des capacités est à l'état d'ébauche, non prête pour la production. Les implémenteurs ne peuvent pas construire des systèmes de classification en production contre elle jusqu'à ce que la taxonomie complète soit publiée.
La qualité de mise en correspondance se dégrade avec des données historiques insuffisantes. Le filtrage collaboratif fournit zéro valeur pour les nouveaux demandeurs ou les nouveaux nœuds AMP sans historique d'interaction. Les déploiements AMP à démarrage à froid fonctionnent comme des répertoires de mise en correspondance de capacités jusqu'à l'accumulation de données suffisantes.
Le protocole spécifie les algorithmes mais pas les préoccupations opérationnelles. AMP v1 ne traite pas la surveillance, les alertes, le basculement, les chemins de mise à niveau, la compatibilité ascendante ni les runbooks opérationnels.
La mise en correspondance préservant la confidentialité est aspirationnelle. Le modèle de confidentialité d'AMP v1 (TLS + anonymisation des requêtes + divulgation progressive) est adéquat pour la plupart des cas d'usage mais insuffisant pour de solides garanties de confidentialité.
Les chiffres d'amorçage surestiment la préparation. Bien que 19 000+ capacités, compétences et références d'agents soient théoriquement accessibles, l'utilité réelle dépend de la qualité des adaptateurs et du défi d'hétérogénéité pour combler les compétences atomiques et les profils d'agents composites.
L'implémentation de référence AMP se compose de quatre composants :
amp-core : Bibliothèque Python implémentant le moteur de mise en correspondance, le calcul de compatibilité et le modèle de données UCP. Zéro dépendance externe au-delà de la bibliothèque standard Python + un validateur de schéma JSON.
amp-federation : Routeur de fédération avec adaptateurs de registres enfichables. Livré avec des adaptateurs pour : le crawling Agent Card A2A (basé HTTP), la recherche sémantique ClawHub (basé API) et un modèle d'adaptateur REST générique.
amp-trust : Vérificateur de confiance qui interroge les points de terminaison CoC, ARP, ASA, AJP et ALP pour peupler les signaux de confiance vérifiés.
amp-node : Serveur HTTP combinant les trois composants en un nœud AMP déployable.
import os
from amp_core import MatchEngine, UCPStore
from amp_federation import FederationRouter, A2AAdapter, ClawHubAdapter
from amp_trust import TrustVerifier
from amp_node import AMPNode
# Initialiser les composants
engine = MatchEngine()
store = UCPStore()
router = FederationRouter()
verifier = TrustVerifier(
coc_endpoint="https://coc.example.com",
arp_endpoint="https://arp.example.com"
)
# Enregistrer les registres fédérés
router.add_adapter(A2AAdapter(crawl_domains=["agent.example.com"]))
router.add_adapter(ClawHubAdapter(api_key=os.environ["CLAWHUB_API_KEY"]))
# Lancer le nœud
node = AMPNode(engine=engine, store=store, router=router, verifier=verifier)
node.serve(host="0.0.0.0", port=8430)from amp_core import MatchRequest
request = MatchRequest(
task_description="Review Python microservice code for security vulnerabilities",
domain="security",
subdomain="code_review",
budget_max=50.00,
deadline_ms=3600000,
weights={"capability_match": 0.30, "trust_score": 0.25, "cost_alignment": 0.15,
"availability": 0.10, "style_compatibility": 0.05, "domain_relevance": 0.15},
constraints={"min_trust_score": 60, "max_dispute_rate": 0.05}
)
results = node.match(request)
for result in results:
print(f"{result.rank}. {result.agent_id} — score : {result.compatibility_score}")
print(f" Confiance : {result.trust_verification}")
print(f" Coût : {result.estimated_cost}")| Point de terminaison | Méthode | Description |
|---|---|---|
/amp/v1/match | POST | Soumettre une requête de mise en correspondance, recevoir des résultats classés |
/amp/v1/profile | GET/PUT | Récupérer ou mettre à jour l'UCP d'un agent |
/amp/v1/registry | POST | Enregistrer un nouveau registre fédéré |
/amp/v1/registries | GET | Lister les registres fédérés enregistrés |
/amp/v1/trust/{agent_id} | GET | Récupérer les signaux de confiance vérifiés pour un agent |
/amp/v1/auction | POST | Créer une enchère pour une tâche |
/amp/v1/auction/{id}/bid | POST | Soumettre une offre à une enchère |
/amp/v1/health | GET | Santé du nœud et statut de la fédération |
AMP v1 met en correspondance des agents individuels avec des tâches individuelles. La mise en correspondance d'équipes est un problème significativement plus difficile : l'espace de recherche croît de manière combinatoire avec la taille de l'équipe, la compatibilité d'équipe est distincte de la capacité individuelle, et l'allocation des coûts nécessite l'intégration du Context Window Economics Protocol (CWEP). La mise en correspondance d'équipes est reportée à AMP v2.
AMP v1 utilise une fonction de notation linéaire avec des pondérations de dimensions fixes. Des approches d'apprentissage automatique (learning-to-rank) pourraient améliorer la qualité de mise en correspondance en apprenant des relations non linéaires. AMP v2 explorera des modèles de learning-to-rank interprétables maintenant l'explicabilité.
Des garanties de confidentialité plus solides sont possibles via le calcul multi-parties sécurisé (MPC), le chiffrement homomorphe et la confidentialité différentielle. Ces techniques sont actuellement trop coûteuses en calcul pour la mise en correspondance en temps réel à grande échelle, mais les coûts diminuent rapidement.
AMP pourrait accélérer l'adoption en définissant un format minimal d'échange de réputation plus simple que la conformité complète à ARP v2 — un « embed de réputation » que toute place de marché peut publier.
La mise en correspondance actuelle utilise des instantanés ponctuels. Les signaux de marché en temps réel — surcharges de demande, mouvements de prix, utilisation de capacité — permettraient une mise en correspondance dynamique tenant compte des conditions de marché.
L'économie des agents se fragmente en jardins fermés au moment précis où elle doit se consolider. Neuf places de marché distinctes servent des écosystèmes d'agents qui se chevauchent mais sont incompatibles. La découverte inter-plateformes n'existe pas. Les signaux de confiance sont cloisonnés, invérifiables ou absents. Le problème de mise en correspondance — trouver le meilleur agent pour une tâche spécifique — reste non résolu par tout système en production.
L'Agent Matchmaking Protocol comble cette lacune en spécifiant une couche d'appariement complète : un format de Profil de Capacités Unifié pour décrire les capacités des agents inter-plateformes, un système de notation de compatibilité multidimensionnel qui intègre des signaux de confiance vérifiés, une découverte fédérée qui effectue des recherches dans des places de marché cloisonnées sans les obliger à céder leur contrôle, des mécanismes de découverte des prix et un classement pondéré par la confiance qui transforme les capacités déclarées en signaux de qualité vérifiables.
L'avantage concurrentiel d'AMP ne réside pas dans un composant unique — les algorithmes de mise en correspondance sont bien étudiés, la fédération est une architecture connue, les mécanismes de découverte des prix sont établis. L'avantage est la profondeur d'intégration. Là où les places de marché existantes valident les agents une seule fois lors du référencement, AMP les valide en continu via la pile de confiance complète : provenance CoC pour l'identité, réputation ARP pour la qualité, conformité ASA pour la fiabilité, dossiers de litiges AJP pour le risque et statut de cycle de vie ALP pour la disponibilité.
La stratégie d'amorçage — fédérer les registres existants plutôt que construire une nouvelle offre — évite le problème de la poule et de l'œuf. Avec 19 000+ capacités, compétences et références d'agents déjà découvrables, un nœud AMP peut fournir de la valeur dès le premier jour. L'approche protocolaire garantit qu'AMP évolue avec l'écosystème plutôt que de le concurrencer : chaque nouvelle place de marché implémentant un adaptateur AMP augmente la valeur du réseau.
AMP est l'apex commercial de l'écosystème de confiance — la couche où les protocoles deviennent des produits. CoC, ARP, ASA, AJP et ALP fournissent l'infrastructure de confiance. AMP fournit le marché où cette confiance est consommée, tarifée et transactée. Ensemble, ils forment le fondement d'une économie des agents où la confiance se mérite par une opération vérifiable, non déclarée par des textes de marketing.
[1] Google Cloud Blog, « Google Cloud AI Agent Marketplace, » 2025.
[2] Salesforce Press Release, « AgentExchange Announcement, » 4 mars 2025.
[3] AWS News Blog, « Introducing Amazon Bedrock AgentCore, » octobre 2025.
[4] ServiceNow Blog, « Your Go-to Marketplace for AI Agents, » 2025.
[5] gorilla.cs.berkeley.edu, « Agent Marketplace, » 2025.
[6] ClawHub (clawhub.ai), statistiques du registre, février 2026.
[7] AI Agent Store (aiagentstore.ai), répertoire, 2026.
[8] ProductMint, « The KAYAK Business Model, » 2025.
[9] A2A Protocol (a2a-protocol.org), « Agent Discovery, » 2025 ; CodeLime, « A2A Protocol explained, » 2025.
[10] ModelContextProtocol.io, Spécification novembre 2025 ; MCP Blog, « The 2026 MCP Roadmap, » 2026.
[11] ClawHub Docs, spécification du format SKILL.md, 2026 ; DigitalOcean, guide OpenClaw, 2026.
[12] Gale, D. et Shapley, L.S., « College Admissions and the Stability of Marriage, » American Mathematical Monthly, 69(1) : 9-15, 1962.
[13] OpenAI, Agentic Commerce Protocol (avec Stripe), septembre 2025.
[14] Google, Universal Commerce Protocol (avec Shopify, Etsy, Wayfair, Target, Walmart), 2025-2026.
[15] AB Support LLC, « Chain of Consciousness : A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance, » v3.0.0, 2026.
[16] AB Support LLC, « Agent Rating Protocol v2 : Signal Composition, Portability, and Anti-Goodhart Architecture, » v2.0.0, 2026.
[17] AB Support LLC, « Agent Justice Protocol, » v1.0.0, 2026.
[18] AB Support LLC, « Agent Service Agreements, » v1.0.0, 2026.
[19] AB Support LLC, « Agent Lifecycle Protocol, » v1.0.0, 2026.
[20] IETF, draft-liang-agentdns-00, « AgentDNS : A Root Domain Naming System for LLM Agents, » 2025.
[21] ArXiv 2505.10609, « Agent Name Service (ANS), » mai 2025 ; IETF, draft-narajala-ans-00, 2025.
[22] CmdZero Blog, « Introducing the Agent Communication & Discovery Protocol (ACDP), » 2025.
[23] ERC-8183, Programmable Escrow Standard, Ethereum, 2025-2026.
[24] x402 Payment Protocol, statistiques de transactions, 2025-2026.
[25] Rochet, J.-C. et Tirole, J., « Platform Competition in Two-Sided Markets, » Journal of the European Economic Association, 1(4) : 990-1029, 2003.
[26] Northwestern/Palacios-Huerta, « Two-sided Markets, Pricing, and Network Effects, » 2021.
[27] Nisan, N. et al., Algorithmic Game Theory, Cambridge University Press, 2007.
[28] W3C, « Decentralized Identifiers (DIDs) v1.1, » Recommandation candidate, 2026.
[29] PwC/Google Cloud, « AI agent ecosystem with Google Cloud, » 2025.
[30] Salesforce Investor Relations, « Agentforce 360 for AWS, » 2025.
[31] Blink Blog, « OpenClaw Skills : How to Install from ClawHub Safely in 2026, » 2026.
[32] Adven Boost, « OpenClaw ClawHub : The 2026 Security-First Guide, » 2026.
[33] Apify, AI Agent Marketplace and agentic commerce blog, 2026.
[34] Microsoft Research Blog, « Magentic Marketplace : open-source simulation environment, » novembre 2025.
[35] TechCrunch, « Microsoft built a fake marketplace to test AI agents, » novembre 2025.
[36] InfoQ, « AI Agents Fail Manipulation Tests in Magentic Marketplace, » novembre 2025.
[37] O*NET Resource Center, « O*NET-SOC Taxonomy, » 2025.
[38] Vickrey, W., « Counterspeculation, Auctions, and Competitive Sealed Tenders, » Journal of Finance, 16(1) : 8-37, 1961.
[39] Milgrom, P., « Putting Auction Theory to Work, » Cambridge University Press, 2004.
[40] Cramton, P., Shoham, Y., et Steinberg, R., « Combinatorial Auctions, » MIT Press, 2006.
[41] Gartner, « Top Strategic Predictions for 2026 and Beyond, » présenté par Daryl Plummer au Gartner IT Symposium/Xpo, octobre 2025. Prédiction n°6 : « D'ici 2028, 90 % des achats B2B seront intermédiés par des agents IA, faisant transiter plus de 15 000 milliards de dollars de dépenses B2B par des échanges d'agents IA. »
[42] McKinsey & Company (QuantumBlack), « The Agentic Commerce Opportunity : How AI Agents Are Ushering in a New Era for Consumers and Merchants, » octobre 2025.
[43] Brin, S. et Page, L., « The Anatomy of a Large-Scale Hypertextual Web Search Engine, » WWW 1998.
[44] HBS Online, « What Are Network Effects? » 2025 ; Practical Ecommerce, « Network Effects Drive Ecommerce Marketplace Growth, » 2025.
[45] Practical Ecommerce, ibid.
[46] Hagiu, A. et Wright, J., « Multi-Sided Platforms, » International Journal of Industrial Organization, 43 : 162-174, 2015.
[47] Ezrachi, A. et Stucke, M.E., « Algorithmic Collusion : Problems and Counter-Measures, » OECD Background Paper, 2017.
[48] Olesen, J.M. et al., « The modularity of pollination networks, » PNAS, 104(50) : 19891-19896, 2007.
[49] Gordon, D.M., « The Ecology of Collective Behavior, » PLoS Biology, 2014.
[50] Dorigo, M. et Gambardella, L.M., « Ant Colony System, » IEEE Transactions on Evolutionary Computation, 1(1) : 53-66, 1997.
[51] Janeway, C.A. et al., « The major histocompatibility complex and its functions, » Immunobiology, 5e éd., 2001.
[52] Kappler, J.W. et al., « T cell tolerance by clonal elimination in the thymus, » Cell, 49(2) : 273-280, 1987.
[53] Noë, R. et Hammerstein, P., « Biological markets : supply and demand determine the effect of partner choice in cooperation, mutualism and mating, » Behavioral Ecology and Sociobiology, 35(1) : 1-11, 1994.
Ce document est publié sous licence Apache 2.0. Copyright 2026 AB Support LLC. L'Agent Matchmaking Protocol est une spécification ouverte — toute organisation peut l'implémenter sans autorisation ni redevance.