Versión: 1.0.0
Autores: Charlie (Analista de Profundización), Alex (Coordinador de Flota de AB Support), Bravo (Investigación), Editor (Revisión de Contenido)
Contacto: alex@vibeagentmaking.com
Fecha: 2026-03-26
Estado: Borrador de prepublicación
Licencia: Apache 2.0
Organización: AB Support LLC
La economía de agentes autónomos se está fragmentando antes de poder consolidarse. A principios de 2026, los mercados de agentes operan como jardines amurallados: el AI Agent Marketplace de Google Cloud valida agentes para Vertex AI [1], Salesforce AgentExchange requiere integración con Agentforce [2], AWS Marketplace vincula los agentes a Bedrock AgentCore [3], y el AI Agent Marketplace de ServiceNow está restringido a su propia plataforma [4]. Un agente listado en un mercado es invisible para los clientes de todos los demás. Existen alternativas abiertas: el mercado Gorilla de UC Berkeley aloja más de 150 agentes [5], el registro de habilidades de ClawHub contiene 13.729 habilidades creadas por la comunidad [6], y AI Agent Store ofrece más de 1.300 entradas curadas [7]; sin embargo, están desconectadas entre sí y de las plataformas empresariales. No existe búsqueda multiplataforma. Ningún protocolo combina descubrimiento con emparejamiento, verificación de confianza y negociación de precios en un solo estándar abierto.
Esta fragmentación recrea el problema de silos de información anterior a la web. Antes de los motores de búsqueda, encontrar información requería saber qué base de datos consultar. Antes de los agregadores de viajes como Kayak, encontrar el vuelo más barato exigía verificar cada aerolínea individualmente [8]. La economía de agentes enfrenta el mismo problema estructural: encontrar el mejor agente para una tarea requiere buscar en cada mercado por separado, comparar descripciones de capacidades incompatibles y tomar decisiones de confianza sin datos de reputación estandarizados.
El Protocolo de Agent Matchmaking (AMP) llena este vacío. AMP especifica cinco capacidades que en conjunto constituyen una capa de emparejamiento completa para el comercio de agentes autónomos:
AMP está diseñado como el vértice comercial del Ecosistema de Confianza de AB Support — un protocolo de Capa 4 (Mercado/Descubrimiento) que consume datos de todos los protocolos de capas inferiores. Su ventaja competitiva no es el algoritmo de emparejamiento en sí (el emparejamiento es un problema bien estudiado), sino la profundidad de la integración de confianza: donde los mercados existentes validan agentes una sola vez al momento de su registro mediante control corporativo, AMP los valida continuamente a través del historial operativo verificado por la pila de confianza completa.
El protocolo es agnosítico respecto al sistema de identidad, al mercado y al método de pago. Especifica cómo se emparejan los agentes, no quiénes son, dónde están listados ni cómo pagan. Esta neutralidad arquitectónica permite la adopción en todo el ecosistema fragmentado sin requerir que ningún mercado ceda el control.
Este documento técnico especifica el protocolo completo: modelos de datos para perfiles de capacidad y solicitudes de emparejamiento, algoritmos de emparejamiento con análisis formal de los equilibrios entre estabilidad y optimalidad, arquitectura de descubrimiento federado, mecanismos de descubrimiento de precios, integración de señales de confianza, estrategias de arranque para el problema del huevo y la gallina, análisis de seguridad incluyendo resistencia a la manipulación y emparejamiento con preservación de privacidad, y un estudio del panorama competitivo que cubre más de 9 mercados existentes y más de 40 fuentes.
La economía de agentes cuenta con descubrimiento. El protocolo Agent-to-Agent (A2A) de Google, adoptado por más de 150 organizaciones a mediados de 2025 [9], estandariza cómo los agentes publican sus capacidades mediante Agent Cards en /.well-known/agent.json. El Model Context Protocol (MCP), donado a la Agentic AI Foundation (Linux Foundation) en diciembre de 2025, permite a los agentes descubrir herramientas dinámicamente en tiempo de ejecución [10]. AgentDNS [20] y el Agent Name Service (ANS) [21] proponen nomenclatura y resolución similar a DNS para endpoints de agentes. El Agent Communication & Discovery Protocol (ACDP) [22] se basa en registros DNS SRV existentes para un descubrimiento pragmático.
La economía de agentes cuenta con comercio. El Agentic Commerce Protocol de OpenAI (con Stripe) permite compras a través de ChatGPT [13]. El Universal Commerce Protocol de Google (con Shopify, Etsy, Wayfair, Target, Walmart) estandariza las interacciones agente-comercio con más de 20 socios [14]. ERC-8183 define un fideicomiso programable para transacciones de agentes en cadena [23]. El protocolo de pago x402 reporta más de 35 millones de transacciones desde mediados de 2025, aunque el análisis sugiere que aproximadamente la mitad de este volumen refleja pruebas de infraestructura en lugar de comercio genuino [24].
Lo que la economía de agentes no tiene es una capa de emparejamiento — un mecanismo a nivel de protocolo que toma la descripción de una tarea, busca en todo el ecosistema fragmentado y devuelve recomendaciones de agentes clasificadas por capacidad, confianza, costo y compatibilidad.
Esto no es un problema de conveniencia. Es una falla de mercado.
Cuando los mercados están aislados, surgen tres patologías:
Los costos de búsqueda dominan los costos de transacción. Una empresa que busca un agente de revisión de código debe consultar el AI Agent Marketplace de Google Cloud, Salesforce AgentExchange, AWS Marketplace, el AI Agent Marketplace de ServiceNow, el mercado de código abierto de Berkeley, el registro de habilidades de ClawHub y directorios generales — siete plataformas con interfaces de búsqueda incompatibles, taxonomías de capacidades diferentes y sin forma de comparar resultados entre ellas. Para usuarios humanos, esto es tedioso pero manejable. Para agentes autónomos que necesitan contratar a otros agentes de forma programática y a velocidad de máquina, es una barrera estructural al comercio.
El bloqueo de plataforma suprime la competencia. Un agente que construye reputación en Salesforce AgentExchange no puede transferir esa reputación a AWS Marketplace. El historial del agente — la señal más informativa del rendimiento futuro — está atrapado en una sola plataforma. Esto crea costos de cambio artificiales que benefician a los incumbentes y penalizan a los agentes que atienden a clientes en múltiples plataformas. Es el equivalente en agentes a un conductor que no puede transferir su calificación de Uber a Lyft.
Las señales de calidad están ausentes o no son verificables. Los mercados empresariales validan agentes una sola vez al momento de su registro mediante control corporativo — Google Cloud valida para compatibilidad con Vertex AI, Salesforce certifica para integración con Agentforce. Los registros abiertos dependen de la revisión comunitaria. Ninguno proporciona señales de calidad continuas. Un cliente que elige entre dos agentes de revisión de código en el mercado de Google Cloud no tiene acceso a los historiales de rendimiento de esos agentes en otras plataformas, sus registros de disputas, sus tasas de cumplimiento de SLA ni sus cadenas de procedencia. La información necesaria para una buena decisión de emparejamiento existe, dispersa entre protocolos y plataformas. Ningún sistema la agrega.
AMP opera en la intersección de cuatro disciplinas establecidas:
La recuperación de información proporciona la base para la búsqueda basada en capacidades — emparejar la descripción de una tarea con los perfiles de capacidad de los agentes usando similitud semántica, consultas estructuradas o enfoques híbridos.
La teoría de emparejamiento proporciona la base algorítmica para la optimización de preferencias bilaterales — asegurar que cuando múltiples tareas compiten por el mismo agente y múltiples agentes podrían atender la misma tarea, la asignación resultante sea estable (ningún par tarea-agente preferiría ser emparejado de otra manera) [12].
La economía de plataformas proporciona la base de diseño de mercado — comprensión de los efectos de red cruzados, el problema de arranque del huevo y la gallina, las estrategias de precios para mercados de dos lados y las condiciones bajo las cuales los mercados fragmentados se consolidan o persisten [25][26].
El diseño de mecanismos proporciona la base de ingeniería de incentivos — estructurar el protocolo de modo que el reporte honesto de capacidades, la fijación precisa de precios y la entrega genuina de calidad sean las estrategias individualmente racionales para los participantes [27].
AMP no pretende reemplazar los mercados existentes. Al igual que Kayak, que busca en las aerolíneas sin operar vuelos, AMP busca en los mercados de agentes sin alojar agentes. Es un protocolo — una especificación que cualquier mercado, registro o servicio de descubrimiento puede implementar — no una plataforma. El protocolo define cómo se estructuran los perfiles de capacidad, cómo se formulan las solicitudes de emparejamiento, cómo se ejecutan las consultas federadas, cómo se clasifican los resultados usando señales de confianza y cómo opera el descubrimiento de precios dentro del flujo de emparejamiento.
AMP especifica:
AMP no especifica:
AMP consume los resultados de todos estos protocolos; no los duplica.
Los siguientes términos se utilizan a lo largo de esta especificación con significados precisos:
| Término | Definición |
|---|---|
| Agente | Una entidad de software autónoma capaz de realizar tareas, tomar decisiones e interactuar con otros agentes o humanos sin supervisión humana continua |
| Capacidad | Un tipo específico de trabajo que un agente puede realizar, descrito a un nivel de abstracción significativo para el emparejamiento (p. ej., «revisión de código para microservicios en Python», no «invocar un linter») |
| Perfil de Capacidad | Una descripción estructurada y legible por máquina de las capacidades, características de rendimiento, parámetros de costo y disponibilidad de un agente, formalizada en AMP como un Perfil de Capacidad Unificado (UCP) |
| Solicitud de Emparejamiento | Una consulta estructurada que describe una tarea a realizar, las preferencias del solicitante en múltiples dimensiones (calidad, costo, velocidad, confianza) y cualquier restricción estricta |
| Respuesta de Emparejamiento | Una lista clasificada de agentes que satisfacen las restricciones de la solicitud de emparejamiento, ordenada por puntuación compuesta de compatibilidad |
| Puntuación de Compatibilidad | Una puntuación multidimensional que refleja qué tan bien un agente se ajusta a una solicitud de emparejamiento específica, calculada a partir de la coincidencia de capacidades, señales de confianza, alineación de costos, disponibilidad y compatibilidad de estilo |
| Registro | Cualquier sistema que almacena y sirve perfiles de capacidad de agentes — mercados empresariales, registros abiertos, endpoints autoalojados |
| Federación | El mecanismo del protocolo mediante el cual AMP consulta múltiples registros simultáneamente y fusiona los resultados en una clasificación unificada |
| Señal de Confianza | Una afirmación verificable sobre el historial o la calidad de un agente, proveniente de protocolos del ecosistema de confianza (procedencia CoC, reputación ARP, cumplimiento ASA, registro de disputas AJP, estado de ciclo de vida ALP) |
| Descubrimiento de Precios | El proceso mediante el cual un solicitante y un proveedor acuerdan el costo de un servicio, a través de precios publicados, subasta o negociación |
| Emparejamiento Estable | Una asignación de emparejamiento donde ningún par tarea-agente no emparejado preferiría mutuamente ser emparejado entre sí en lugar de sus asignaciones actuales [12] |
| Arranque (Bootstrapping) | El proceso de superar el problema del huevo y la gallina en un mercado de dos lados: atraer oferta inicial (agentes listados) y demanda (solicitantes de tareas) simultáneamente |
| UCP | Perfil de Capacidad Unificado (Unified Capability Profile) — el formato legible por máquina de AMP para describir las capacidades de los agentes, interoperable con A2A Agent Cards, manifiestos MCP y especificaciones de habilidades de OpenClaw |
| Nodo AMP | Una implementación del protocolo AMP que puede recibir solicitudes de emparejamiento, consultar registros, calcular clasificaciones y devolver respuestas de emparejamiento |
El diseño de AMP se guía por siete principios derivados de las fallas de los mercados existentes y los requisitos de la economía de agentes:
AMP es una especificación, no un servicio. Cualquier organización puede implementar un Nodo AMP sin permiso de AB Support ni de ninguna autoridad central. Esto sigue el modelo de HTTP (cualquiera puede implementar un servidor web), DNS (cualquiera puede ejecutar un resolvedor) y A2A (cualquiera puede publicar una Agent Card). La alternativa — una plataforma de emparejamiento centralizada — crearía un punto único de falla, un intermediario extractivo de rentas y un cuello de botella de control que contradice el carácter abierto y descentralizado del ecosistema de confianza.
El equilibrio es real: una plataforma centralizada captura más valor (modelo CPC de Kayak, comisión del 30% de la App Store) y puede iterar más rápido en la calidad del emparejamiento. El enfoque de protocolo sacrifica estos aspectos a favor de la amplitud de adopción y la resiliencia del ecosistema. Esta es una elección deliberada: el valor de AMP proviene de ser el estándar de emparejamiento, no el servicio de emparejamiento.
AMP no reinventa la identidad, la comunicación, el pago, los acuerdos, las disputas ni la verificación de calidad. Consume los resultados de protocolos que ya manejan estas funciones:
| Función | Protocolo | Consumo de AMP |
|---|---|---|
| Identidad | CoC, DIDs, A2A Cards | Verificar la identidad del agente antes de incluirlo en los resultados |
| Reputación | ARP v2 | Utilizar puntuaciones compuestas como señales de clasificación |
| Acuerdos | ASA | Utilizar el historial de cumplimiento de SLA como indicador de fiabilidad |
| Disputas | AJP | Utilizar la tasa de disputas y sus resultados como señal de riesgo |
| Ciclo de vida | ALP | Filtrar agentes obsoletos/desmantelados |
| Comunicación | A2A, MCP | Enrutar resultados de emparejamiento a través de canales existentes |
| Pago | x402, ERC-8183 | Integrar el descubrimiento de precios sin manejar la liquidación |
Este principio de «consumir, no duplicar» mantiene a AMP enfocado en su contribución central — el emparejamiento — mientras habilita profundidad a través de la integración.
La clasificación unidimensional (p. ej., «ordenar por precio» u «ordenar por calificación») es la opción predeterminada en la mayoría de los mercados porque es fácil de implementar y de entender para los humanos. También es categóricamente inadecuada para el emparejamiento de agentes.
Un agente con precisión perfecta pero tiempos de respuesta de 10 minutos es inútil para atención al cliente en tiempo real. Un agente con el precio más bajo pero una tasa de disputas del 40% es más costoso en expectativa que un agente premium con una tasa de disputas del 2%. Un agente con altas calificaciones en revisión de código para JavaScript puede ser mediocre en la revisión de microservicios en Python.
AMP requiere solicitudes de emparejamiento multidimensionales y puntuación de compatibilidad multidimensional. Las dimensiones son:
| Dimensión | Fuente | Qué Mide |
|---|---|---|
| Coincidencia de Capacidad | Similitud semántica del UCP | Qué tan bien las capacidades del agente se ajustan a la tarea |
| Puntuación de Confianza | Compuesto de CoC + ARP + ASA + AJP | Qué tan confiable es el agente |
| Alineación de Costos | Señales de precios | Qué tan bien el precio del agente se ajusta al presupuesto |
| Disponibilidad | Estado del registro + ciclo de vida ALP | Si el agente está actualmente disponible y activo |
| Compatibilidad de Estilo | Metadatos del UCP + historial de interacción | Si el formato de salida y el estilo de interacción del agente coinciden con las preferencias |
| Relevancia de Dominio | Puntuaciones dimensionales de ARP + historial de ASA | Qué tan bien el historial del agente en este dominio específico coincide con la tarea |
Los solicitantes especifican pesos para estas dimensiones. El protocolo no impone una ponderación predeterminada — diferentes casos de uso tienen prioridades legítimamente distintas.
Los mercados existentes dependen de la confianza declarada — el agente (o su editor) afirma ciertas capacidades y el mercado valida la afirmación una sola vez. AMP reemplaza la declaración con evidencia:
Donde existe evidencia de confianza, AMP la utiliza. Donde no (agentes nuevos, agentes de plataformas sin integración de confianza), AMP aplica un descuento apropiado sin excluir al agente por completo (ver Sección 10.3, Incorporación de Nuevos Agentes).
El modelo de descubrimiento federado de AMP respeta la autonomía de cada mercado y registro. Una consulta AMP no requiere que los mercados expongan sus bases de datos completas de agentes. En cambio, cada registro participante implementa un endpoint de consulta estandarizado que:
Esto es análogo a cómo Kayak consulta las APIs de las aerolíneas: cada aerolínea controla su propio inventario y precios; Kayak simplemente agrega los resultados. Un mercado puede participar en la federación AMP sin ceder el control sobre sus agentes, sus datos o su modelo de negocio.
El problema del huevo y la gallina — ningún agente se lista porque no hay solicitantes, ningún solicitante busca porque no hay agentes — mata a la mayoría de los mercados de dos lados antes de que alcancen masa crítica [25]. AMP aborda esto estructuralmente al no requerir la construcción de un nuevo mercado. Debido a que AMP es un protocolo de federación, se arranca conectando registros existentes (ClawHub con 13.729 habilidades, Berkeley con más de 150 agentes, Apify con más de 4.000 herramientas, mercados empresariales con cientos de agentes validados) en lugar de requerir nueva oferta. La oferta ya existe — como una mezcla de habilidades, herramientas, perfiles de agentes y entradas de directorio en diversos niveles de abstracción — y simplemente está fragmentada.
Los agentes pueden tener razones competitivas para ocultar partes de sus perfiles de capacidad. Un agente de investigación propietario puede no querer revelar su cadena exacta de herramientas. AMP admite la divulgación progresiva: los agentes publican suficiente información de capacidad para el emparejamiento, pero pueden retener detalles de implementación hasta después de que se confirme un emparejamiento y se negocie un acuerdo. Las señales de confianza pueden verificarse de forma agregada (p. ej., «la puntuación compuesta ARP de este agente supera 80») sin revelar puntuaciones dimensionales exactas, utilizando los mecanismos de prueba de conocimiento cero especificados en ARP v2 [16].
Los mercados de agentes dominantes a principios de 2026 son plataformas empresariales que agrupan el descubrimiento con sus ecosistemas en la nube:
Google Cloud AI Agent Marketplace se lanzó en 2025 dentro de Google Cloud Marketplace, ofreciendo acceso a agentes especializados de socios validados mediante búsqueda en lenguaje natural impulsada por Gemini [1]. Solo PwC ha publicado más de 120 agentes en la plataforma [29]. El descubrimiento utiliza consultas en lenguaje natural: los clientes describen un caso de uso y el sistema devuelve agentes coincidentes validados para la integración con A2A y Gemini Enterprise. Una herramienta llamada «Agent Finder» proporciona acceso navegable. Fortalezas: búsqueda sofisticada en lenguaje natural, integración de facturación empresarial. Limitación: solo los agentes validados por Google Cloud son visibles; los agentes multiplataforma quedan excluidos.
Salesforce AgentExchange se lanzó el 4 de marzo de 2025 con más de 200 socios iniciales, incluyendo Google Cloud, Docusign y Box, posicionándose como «el primer mercado de agentes del mundo» [2]. Ofrece cuatro tipos de componentes: Acciones, Plantillas de Prompts, Tópicos y Plantillas de Agentes. A finales de 2025, Salesforce lo amplió con Agentforce 360 para AWS, conectando los ecosistemas de Salesforce y AWS [30]. Fortalezas: gran ecosistema de socios, integración profunda con CRM, extensión multi-nube. Limitación: fuertemente acoplado a Agentforce — los agentes fuera de Salesforce no pueden listarse.
AWS Marketplace (Agentes de IA) agregó una sección dedicada de «AI Agents & Tools» integrada con Amazon Bedrock AgentCore, disponible de manera general el 13 de octubre de 2025 [3]. En un reciente hackathon de agentes de IA de AWS, el 80% de 600 agentes fueron construidos usando AgentCore [3]. Los clientes pueden usar servidores MCP adquiridos a través de AWS Marketplace como objetivos MCP en AgentCore Gateway, uniendo MCP y la infraestructura de AWS. Fortalezas: adopción por desarrolladores (AgentCore), precios flexibles basados en uso, puente MCP. Limitación: centrado en AWS; los agentes deben integrarse con Bedrock.
ServiceNow AI Agent Marketplace se relanzo en 2025 con un asistente de IA nativo que proporciona recomendaciones personalizadas basadas en las aplicaciones e integraciones existentes del cliente [4]. Los socios de lanzamiento incluyen Accenture, Deloitte, HCLTech y otros siete integradores empresariales. Fortalezas: motor de recomendación impulsado por IA (más sofisticado que la navegación por categorías), colecciones específicas por industria. Limitación: vinculado a la plataforma ServiceNow.
UC Berkeley Gorilla Agent Marketplace opera un motor de búsqueda de código abierto para más de 150 agentes LLM verificados provenientes de Langchain, LlamaIndex, OpenAI y CrewAI [5]. Revisado por la comunidad, compatible con múltiples frameworks, listado sin permisos. Fortalezas: abierto, multi-framework. Limitación: escala pequeña, sin capacidad transaccional.
ClawHub aloja 13.729 habilidades creadas por la comunidad a febrero de 2026, descubribles mediante búsqueda semántica basada en vectores impulsada por embeddings de OpenAI [6]. Cada habilidad es un archivo SKILL.md con frontmatter YAML e instrucciones en markdown. La seguridad es una preocupación: investigadores descubrieron 1.467 habilidades maliciosas (~3% del registro), de las cuales el 91% combina inyección de prompts con malware tradicional [31][32]. Fortalezas: registro abierto más grande, búsqueda semántica, CLI similar a npm. Limitación: las habilidades describen capacidades individuales, no perfiles de agentes compuestos; riesgos de seguridad significativos en el contenido moderado por la comunidad.
AI Agent Store y AI Agents Directory agregan metadatos sobre más de 1.300 agentes en varias categorías, pero no manejan despliegue, facturación ni ejecución [7]. Funcionan como directorios más que como mercados transaccionales.
Apify ofrece más de 4.000 web scrapers, agentes y herramientas de automatización con integración MCP [33]. Agen.cy proporciona un directorio navegable de agentes para descubrimiento por tarea e industria.
Microsoft Magentic Marketplace (noviembre de 2025) es un entorno de simulación de código abierto para estudiar mercados agénticos, no un mercado de producción [34][35]. Hallazgos clave de experimentos controlados con cientos de agentes compradores y vendedores simultáneos: (a) los modelos de frontera logran resultados sólidos de bienestar en condiciones ideales, pero el rendimiento se degrada a escala; (b) modos de falla emergentes incluyen manipulación y sesgo de velocidad, donde los agentes vendedores explotan los límites de atención de los agentes compradores; y (c) los agentes compradores con más opciones experimentan degradación de la calidad de decisión debido a que la sobrecarga de opciones abruma sus ventanas de contexto [36]. Publicado como código abierto en GitHub (microsoft/multi-agent-marketplace). Fortalezas: los datos empíricos más rigurosos sobre dinámicas de mercados de agentes. Limitación: simulación, no sistema de producción.
| Capacidad | Google Cloud | Salesforce | AWS | ServiceNow | Berkeley | ClawHub | Magentic | AMP |
|---|---|---|---|---|---|---|---|---|
| Búsqueda multiplataforma | No | Parcial (puente AWS) | No | No | Parcial | No | N/A | Sí |
| Emparejamiento multidimensional | No | No | No | Impulsado por IA | No | Semántico | Investigación | Sí |
| Clasificación ponderada por confianza | Validación corporativa | Certificación de socios | Revisión AWS | Cert. de socios | Comunitaria | Comunitaria + escaneo | N/A | Pila de confianza verificable |
| Descubrimiento de precios | Facturación de plataforma | Facturación de plataforma | Basado en uso | Facturación de plataforma | Gratuito | Gratuito | Simulado | Multi-mecanismo |
| Garantía de emparejamiento estable | No | No | No | No | No | No | Estudiado | Sí (modo por lotes) |
| Protocolo abierto | No | No | No | No | Sí | Sí | Sí | Sí |
| Preservación de privacidad | N/A | N/A | N/A | N/A | No | No | N/A | Parcial (TLS + anonimización; ZKP vía ARP v2 para umbrales de puntuación) |
La brecha es clara: ningún sistema combina búsqueda abierta y multiplataforma con emparejamiento multidimensional ponderado por confianza, garantías formales de estabilidad y descubrimiento de precios multi-mecanismo. AMP ocupa esta brecha.
Nota sobre la metodología de comparación: Esta tabla compara características a nivel de protocolo en lugar de preparación operativa. Las plataformas existentes tienen fortalezas reales que AMP aún no iguala — incluyendo madurez operativa, integración de facturación empresarial, soporte al cliente establecido, garantías de SLA respaldadas por responsabilidad corporativa y años de robustecimiento en producción. Las ventajas de AMP son arquitectónicas (apertura, federación, integración de confianza); las ventajas de los incumbentes son operativas. Un despliegue en producción necesitaría cerrar la brecha operativa para competir con las plataformas establecidas. La garantía de emparejamiento estable de AMP aplica en modo por lotes; la estabilidad en tiempo real requiere mecanismos complementarios (ver Sección 6.3).
Las descripciones de capacidades de agentes existen en tres niveles de abstracción, ninguno suficiente por sí solo:
Nivel de herramienta (manifiestos MCP): Listan las herramientas individuales que un agente puede invocar — web scraping, análisis de archivos, llamadas a APIs [10]. Estos son detalles de implementación, no capacidades. Saber que un agente tiene una herramienta de web scraping no indica si puede realizar investigación competitiva.
Nivel de habilidad (especificaciones de OpenClaw): Describen habilidades individuales en markdown legible por humanos con metadatos YAML [11]. Más abstracto que las herramientas, pero aún atómico — una habilidad describe «web scraping» o «resumen», no una capacidad compuesta como «agente de investigación que combina web scraping, resumen y verificación de citas».
Nivel de agente (A2A Agent Cards): Describen lo que un agente puede hacer a nivel de interfaz — habilidades, autenticación soportada, modalidades de entrada/salida [9]. Las Agent Cards están orientadas al descubrimiento: indican qué puede hacer un agente, pero no qué tan bien, qué tan fiablemente, a qué costo ni en comparación con alternativas.
AMP introduce el Perfil de Capacidad Unificado (UCP) — un formato de descripción de capacidades que compone descripciones a nivel de herramienta y habilidad en perfiles a nivel de agente enriquecidos con características de rendimiento, señales de confianza y metadatos de compatibilidad.
Un UCP contiene cinco secciones:
5.2.1 Sección de Identidad
Vincula el UCP con la identidad del agente en todos los sistemas:
{
"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 sección de identidad es de referencia cruzada, no autoritativa — la verificación de identidad se delega a los protocolos de identidad respectivos (CoC, DIDs, A2A).
5.2.2 Sección de Capacidades
Describe lo que el agente puede hacer usando una taxonomía jerárquica:
{
"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"
}
}
]
}El campo taxonomy_codes admite múltiples sistemas de clasificación. AMP define su propia taxonomía jerárquica de capacidades (inspirada en la estructura de O*NET de actividades de trabajo generalizadas → intermedias → detalladas [37]) al tiempo que mantiene la interoperabilidad con clasificaciones ocupacionales existentes. La taxonomía AMP no es prescriptiva — los agentes pueden declarar capacidades usando descripciones de texto libre, códigos de taxonomía estructurados o ambos. El emparejamiento semántico se encarga de la traducción.
5.2.3 Sección de Rendimiento
Describe las características de rendimiento observadas empíricamente:
{
"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
}
}
}Las métricas de rendimiento no son autoreportadas. Se calculan a partir de datos de protocolos del ecosistema de confianza y son criptográficamente verificables:
arp_composite_score se deriva del álgebra de composición de señales de ARP v2 [16]asa_completion_rate se calcula a partir de los registros de acuerdos de ASA [18]ajp_dispute_rate se calcula a partir de los registros de casos de AJP [17]coc_chain_length es verificable contra marcas de tiempo ancladas [15]Donde los datos verificables no están disponibles (p. ej., agentes no integrados con el ecosistema de confianza), los campos se omiten en lugar de estimarse. Un Nodo AMP PUEDE mostrar métricas autoreportadas no verificadas, pero DEBE distinguirlas claramente de las métricas verificadas en los resultados de emparejamiento.
5.2.4 Sección de Costos
Describe el modelo de precios del agente:
{
"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": []
}
}
}Los UCPs están diseñados para generarse a partir de descripciones de capacidades existentes:
| Formato de Origen | Mapeo al UCP |
|---|---|
| A2A Agent Card | Identidad → a2a_card; Habilidades → Sección de Capacidades; Autenticación → filtrada |
| Manifiesto de Herramientas MCP | Herramientas → tools_used en la Sección de Capacidades; Parámetros → complexity_range |
| OpenClaw SKILL.md | Frontmatter YAML → Sección de Capacidades; Binarios requeridos → tools_used |
| API Personalizada | El implementador mapea al esquema UCP; los campos no mapeados se preservan en extensions |
Un Nodo AMP DEBERÍA poder ingerir A2A Agent Cards, manifiestos MCP y especificaciones de OpenClaw directamente, generando UCPs automáticamente. Esto reduce la barrera de adopción: los agentes ya listados en plataformas existentes no necesitan crear UCPs manualmente.
AMP define una taxonomía jerárquica de capacidades de tres niveles:
Nivel 1 — Dominios (8 dominios): investigación, desarrollo, análisis, comunicación, operaciones, creativo, seguridad, específico de dominio
Nivel 2 — Subdominios (~40 subdominios): p. ej., research.competitive, research.academic, development.frontend, development.backend, analysis.financial, analysis.legal, communication.translation, communication.summarization
Nivel 3 — Capacidades (extensible): capacidades específicas dentro de cada subdominio, p. ej., research.competitive.landscape, development.backend.api_design, analysis.financial.valuation
Los Niveles 1 y 2 están definidos por el protocolo y con control de versiones. El Nivel 3 es extensible — los agentes pueden declarar nuevas capacidades en el Nivel 3 sin requerir actualizaciones del protocolo. El emparejamiento semántico maneja las capacidades novedosas del Nivel 3 que no coinciden exactamente con las entradas conocidas de la taxonomía.
Estado de la taxonomía: Los dominios de Nivel 1 y los ejemplos de subdominios de Nivel 2 enumerados anteriormente son ilustrativos y preliminares. La taxonomía completa de Nivel 2 (~40 subdominios) se publicará como un artefacto versionado separado antes de la finalización de AMP v1.0. Los implementadores que construyan sobre la especificación actual deberían tratar los códigos de taxonomía como provisionales y diseñar sus sistemas para acomodar actualizaciones de la taxonomía. El marco estructural (jerarquía de tres niveles, descomposición inspirada en O*NET) es estable; los códigos específicos no lo son.
La taxonomía se inspira estructuralmente en la descomposición jerárquica de actividades ocupacionales de O*NET [37], pero está construida específicamente para las capacidades de agentes en lugar de ocupaciones humanas. Donde O*NET mapea ocupaciones → actividades generalizadas → actividades intermedias → actividades detalladas → declaraciones de tareas, AMP mapea agentes → dominios → subdominios → capacidades → tipos de tarea. El paralelo estructural permite un futuro puente entre las ontologías de capacidades humanas y de agentes, lo que podría volverse relevante a medida que se profundice la colaboración agente-humano.
Una solicitud de emparejamiento especifica lo que el solicitante necesita y cómo prioriza las diferentes dimensiones:
{
"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
}
}
}El objeto weights suma 1.0 y determina la importancia relativa de cada dimensión en la puntuación de compatibilidad. El objeto constraints especifica filtros estrictos — los agentes que no cumplen cualquier restricción son excluidos antes de la puntuación. Este enfoque de dos fases (filtrar y luego clasificar) refleja el pipeline estándar de recuperación de información y es computacionalmente eficiente.
Dada una solicitud de emparejamiento R y un agente candidato A, la puntuación de compatibilidad S(R, A) se calcula como:
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)Donde cada puntuación dimensional C_x se normaliza a [0, 100] y cada peso w_x proviene del objeto weights de la solicitud de emparejamiento.
Coincidencia de Capacidad (C_capability):
Se calcula mediante similitud semántica entre la descripción de la tarea y las descripciones de capacidad del UCP del agente. AMP no prescribe un modelo de embeddings específico, pero requiere que la función de similitud satisfaga tres propiedades:
tools_used reciben una bonificacióncomplexity_range declarado del agente, la puntuación se reduceFormalmente:
C_capability(R, A) = sim(R.task.description, A.capabilities)
* tool_bonus(R.task, A.tools_used)
* complexity_fit(R.task, A.complexity_range)Donde sim es una función de similitud semántica que devuelve [0, 1], tool_bonus devuelve [1.0, 1.2] (hasta un 20% de bonificación por coincidencia de herramientas) y complexity_fit devuelve [0.5, 1.0] (penalización del 50% por complejidad fuera de rango, 1.0 dentro del rango).
Puntuación de Confianza (C_trust):
Derivada de la señal compuesta de ARP v2 [16]:
C_trust(R, A) = f(ARP_composite, CoC_chain_length, ASA_compliance, AJP_dispute_rate)Donde f es la función de composición de señales de ARP v2 con perfiles de peso específicos por dominio. Si el agente carece de integración con el ecosistema de confianza, C_trust se establece por defecto en una línea base configurable (predeterminado: 50) que representa confianza neutral — ni confiable ni desconfiado.
Alineación de Costos (C_cost):
C_cost(R, A) = max(0, 100 - penalty * |estimated_cost(A, R.task) - R.task.budget.target|)Donde estimated_cost proyecta el modelo de precios del agente sobre la tarea específica, y penalty se escala con la sensibilidad al presupuesto. Los agentes con precios dentro del presupuesto reciben puntuaciones altas; los agentes significativamente por encima del presupuesto son penalizados pero no excluidos (el solicitante puede decidir que la prima de confianza lo vale).
Disponibilidad (C_availability):
C_availability(R, A) = lifecycle_check(A) * capacity_score(A) * deadline_fit(A, R.task)Donde lifecycle_check devuelve 0 para agentes obsoletos/desmantelados (filtro estricto), capacity_score devuelve [0, 100] basado en la carga actual, y deadline_fit devuelve [0, 100] basado en si el agente puede cumplir el plazo dada su cola actual.
Compatibilidad de Estilo (C_style):
Se calcula a partir de la alineación del formato de salida y el historial de patrones de interacción:
C_style(R, A) = format_match(R.task.output.format, A.output_modalities)
* interaction_history_score(R.requester_id, A)Donde interaction_history_score refleja filtrado colaborativo — si el solicitante ha trabajado previamente bien con este agente o agentes con perfiles similares, la puntuación aumenta. Para interacciones iniciales, esto se establece por defecto en un neutro de 50.
Relevancia de Dominio (C_domain):
C_domain(R, A) = arp_domain_score(A, R.task.domain) * asa_domain_compliance(A, R.task.domain)Donde arp_domain_score obtiene las puntuaciones dimensionales de ARP del agente específicamente para el dominio solicitado (no su compuesto general), y asa_domain_compliance refleja su tasa de cumplimiento de SLA en tareas de este dominio específico.
AMP admite tres modos de emparejamiento, seleccionados por el solicitante o por defecto según las características de la solicitud:
Modo 1: Búsqueda Clasificada (Predeterminado)
Para solicitudes individuales que buscan una lista clasificada de candidatos. Este es el modo más común — equivalente a una consulta de motor de búsqueda. El Nodo AMP calcula las puntuaciones de compatibilidad para todos los agentes candidatos, aplica las restricciones como filtros estrictos y devuelve los K mejores resultados clasificados por puntuación compuesta. Complejidad computacional: O(n log k) donde n es el número de candidatos y k es max_results.
Modo 2: Emparejamiento Estable
Para escenarios por lotes donde múltiples tareas compiten por los mismos agentes y múltiples agentes podrían atender las mismas tareas. AMP implementa una variante del algoritmo de aceptación diferida de Gale-Shapley [12]:
Gale-Shapley garantiza estabilidad pero es óptimo para las tareas (favorable al lado de la tarea). AMP proporciona un indicador de configuración para producir emparejamientos óptimos para los agentes, y una variante de optimalidad mediana que equilibra ambos lados, aunque la optimalidad mediana requiere cálculo adicional. Complejidad computacional: O(n^2) en el peor caso, donde n es el número de tareas/agentes.
Advertencia sobre estabilidad: Gale-Shapley asume preferencias completas y estáticas. En la práctica, las preferencias de los agentes cambian dinámicamente (llegan nuevas tareas, los agentes completan trabajo, los precios cambian). AMP aborda esto ejecutando el emparejamiento estable periódicamente sobre solicitudes acumuladas en lugar de continuamente, aceptando que entre rondas de emparejamiento la asignación puede ser temporalmente subóptima. El intervalo de emparejamiento es configurable (predeterminado: 60 segundos para mercados en tiempo real, 300 segundos para mercados por lotes).
Modo 3: Emparejamiento por Subasta
Para escenarios donde el descubrimiento de precios es el objetivo principal. El solicitante publica una tarea, los agentes envían ofertas (precio + perfil de capacidad) y el mecanismo de subasta selecciona al agente ganador. AMP admite tres formatos de subasta:
{
"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
}
}
}El bloque trust_verification es crítico: indica al solicitante qué señales de confianza fueron verificadas independientemente por el Nodo AMP (no simplemente reportadas por el agente). Esto distingue a AMP de los mercados que muestran métricas autoreportadas.
La federación AMP conecta un Nodo AMP a múltiples registros a través de una interfaz de consulta estandarizada. La arquitectura tiene tres capas:
┌──────────────────────────────────────────────────────┐
│ NODO AMP │
│ ┌────────────┐ ┌─────────────┐ ┌──────────────┐ │
│ │ Motor de │ │ Enrutador │ │ Verificador │ │
│ │ Empareja- │ │ de Federa- │ │ de │ │
│ │ miento │ │ ción │ │ Confianza │ │
│ └─────┬──────┘ └──────┬──────┘ └──────┬───────┘ │
│ │ │ │ │
└────────┼────────────────┼────────────────┼───────────┘
│ │ │
┌─────┴──────┐ ┌─────┴──────┐ ┌─────┴──────┐
│ Adaptador │ │ Adaptador │ │ Adaptador │
│ de Reg.: │ │ de Reg.: │ │ de Reg.: │
│ Google │ │ ClawHub │ │ A2A │
│ Cloud │ │ │ │ Autoalojado│
└────────────┘ └────────────┘ └────────────┘Motor de Emparejamiento: Recibe solicitudes de emparejamiento, calcula puntuaciones de compatibilidad y produce resultados clasificados.
Enrutador de Federación: Despacha subconsultas de solicitud de emparejamiento a registros registrados en paralelo, recopila respuestas, normaliza los resultados en UCPs y los pasa al Motor de Emparejamiento.
Verificador de Confianza: Verifica independientemente las señales de confianza (entradas de cadena CoC, puntuaciones ARP, registros ASA, datos de disputas AJP) contra sus fuentes autoritativas. Este es el componente que transforma la confianza declarada en confianza verificada.
Adaptadores de Registro: Conectores específicos de protocolo que traducen las consultas de federación AMP al formato de consulta nativo de cada registro y traducen las respuestas de vuelta a UCPs. Los adaptadores son intercambiables — nuevos registros requieren solo un nuevo adaptador, no cambios en el protocolo.
Una consulta de federación AMP sigue un proceso de cinco pasos:
Paso 1: Traducción de Consulta. El Nodo AMP traduce la solicitud de emparejamiento en subconsultas específicas por registro. Para un adaptador de Google Cloud, esto significa construir una consulta en lenguaje natural compatible con Gemini a partir de la descripción de la tarea. Para un adaptador de ClawHub, esto significa construir una consulta de búsqueda semántica contra el índice de embeddings de habilidades. Para un adaptador autoalojado de A2A, esto significa consultar los endpoints /.well-known/agent.json.
Paso 2: Despacho Paralelo. Las subconsultas se despachan a todos los adaptadores registrados simultáneamente con un tiempo de espera configurable (predeterminado: 5000ms). Los registros que no responden dentro del tiempo de espera se excluyen del emparejamiento actual — su ausencia se registra en los metadatos de la respuesta.
Paso 3: Normalización de Respuestas. Cada adaptador traduce la respuesta de su registro en UCPs. Los campos que no pueden mapearse se preservan en un objeto extensions en lugar de descartarse.
Paso 4: Deduplicación y Resolución de Conflictos. Los agentes pueden estar listados en múltiples registros. El Nodo AMP deduplica comparando campos de identidad (DID, ID de cadena CoC, URL de A2A card). Cuando el mismo agente aparece desde múltiples registros, el UCP se fusiona — tomando los datos más completos de cada fuente y anotando en qué registros se encontró al agente.
Cuando los datos entran en conflicto entre registros (p. ej., un registro reporta soporte de Python mientras otro reporta JavaScript, o las puntuaciones de capacidad difieren), AMP aplica una jerarquía de resolución de conflictos: (1) los datos de fuentes de mayor nivel de confianza tienen precedencia sobre los de fuentes de menor nivel, (2) entre niveles de confianza iguales, los datos actualizados más recientemente prevalecen, y (3) los conflictos irresolubles se señalan en los metadatos de respuesta de emparejamiento con un campo data_conflicts, permitiendo al solicitante evaluar las discrepancias. Los Nodos AMP NO DEBERÍAN descartar silenciosamente datos conflictivos.
Paso 5: Enriquecimiento de Confianza. Para cada UCP deduplicado, el Verificador de Confianza consulta el ecosistema de confianza para completar las métricas de rendimiento verificadas. Este paso es opcional pero altamente recomendado — sin él, todas las señales de confianza son declaraciones no verificadas.
La consulta de federación de cinco pasos introduce latencia que debe comprenderse para el despliegue práctico. La respuesta de emparejamiento de ejemplo (Sección 6.4) muestra query_time_ms: 3200 para 237 candidatos — a continuación se presenta un desglose de las contribuciones de latencia esperadas:
| Paso | Latencia Esperada | Notas |
|---|---|---|
| Traducción de Consulta | 5-20ms | Cálculo local, insignificante |
| Despacho Paralelo | 500-5000ms | Limitado por el tiempo de espera; dominado por el registro más lento |
| Normalización de Respuestas | 10-50ms por registro | Cálculo local, paralelizable |
| Deduplicación + Resolución de Conflictos | 20-100ms | Escala con la cantidad de candidatos |
| Enriquecimiento de Confianza | 200-3000ms | Costo dominante; depende del estado de caché |
El enriquecimiento de confianza es el cuello de botella de latencia. Verificar las entradas de cadena CoC, obtener puntuaciones ARP, verificar registros ASA, consultar AJP y confirmar el estado ALP podría requerir de 100-500ms por llamada a API externa. Para 39 candidatos puntuados (después de filtrar 198 de 237), el enriquecimiento serial tomaría 20-100 segundos — claramente impracticable.
Los Nodos AMP DEBERÍAN implementar tres estrategias de mitigación de latencia:
Con almacenamiento en caché y paralelismo, la cifra de 3200ms en el ejemplo es alcanzable para consultas con caché caliente. Las consultas con caché fría contra 5+ registros con enriquecimiento completo de confianza pueden tomar 5-10 segundos. Los Nodos AMP DEBERÍAN reportar las tasas de aciertos de caché en los metadatos de respuesta para que los solicitantes puedan evaluar la frescura de los resultados.
Cualquier registro puede participar en la federación AMP implementando un endpoint de consulta mínimo:
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
}
}
}El formato de respuesta es flexible — el adaptador de registro se encarga de la traducción. El requisito mínimo es que la respuesta contenga información suficiente para construir un UCP parcial (como mínimo: identificador del agente y descripción de capacidad).
Los registros se autoregistran con los Nodos AMP proporcionando su URL de endpoint y un manifiesto que describe sus requisitos de adaptador, parámetros de consulta soportados y formato de respuesta esperado. No existe un registro central de registros — cada Nodo AMP mantiene su propia lista de registros. Las listas de registros pueden compartirse entre Nodos AMP a través de un protocolo simple de sindicación (análogo a OPML para agregadores de feeds), habilitando efectos de red sin centralización.
La federación AMP está diseñada para complementar, no competir con, los protocolos de descubrimiento existentes:
A2A Agent Cards: Los Nodos AMP pueden rastrear endpoints /.well-known/agent.json directamente, tratando la web misma como un registro. Esta es la ruta de integración de menor fricción — cualquier agente compatible con A2A es automáticamente descubrible por AMP sin ningún registro adicional.
AgentDNS [20]: Si AgentDNS logra adopción, los Nodos AMP pueden usar la resolución de AgentDNS como fuente de descubrimiento — resolviendo nombres de agentes a endpoints y luego obteniendo Agent Cards de esos endpoints.
ANS [21]: La nomenclatura agnosítica de protocolo de ANS y la identidad basada en PKI se integran naturalmente con la verificación de identidad de AMP. La identidad verificada de un agente registrado en ANS puede ser consumida por el Verificador de Confianza de AMP.
ACDP [22]: El uso de registros DNS SRV por parte de ACDP para el descubrimiento de agentes proporciona otra fuente de registro. Los Nodos AMP pueden consultar registros SRV para descubrir agentes en dominios específicos.
La pila de descubrimiento emergente — identidad (DIDs/PKI), nomenclatura (AgentDNS/ANS), capacidad (A2A Agent Cards/MCP) — proporciona las tres primeras capas. AMP agrega la cuarta: el emparejamiento. El descubrimiento indica lo que existe; AMP indica lo que es mejor para tu necesidad específica.
La fijación de precios de agentes es actualmente invisible (las plataformas empresariales manejan la facturación de forma opaca), fija (precios publicados en registros) o ausente (los agentes de código abierto son gratuitos). Ninguna de estas opciones sirve bien a la economía de agentes emergente:
Gartner proyecta que para 2028, el 90% de las compras B2B serán intermediadas por agentes de IA, canalizando más de 15 billones de dólares en gasto B2B a través de intercambios de agentes de IA [41]. McKinsey estima la oportunidad global de comercio agéntico — agentes de IA que compran, negocian y realizan transacciones en nombre de humanos — en 3-5 billones de dólares para 2030, con hasta 1 billón de dólares en ingresos minoristas orquestados solo en Estados Unidos [42]. Estas proyecciones sugieren, aunque con la incertidumbre inherente a los pronósticos de analistas, que el descubrimiento de precios agente-a-agente se convertirá en una función económica significativa.
AMP admite tres mecanismos de descubrimiento de precios, seleccionables por solicitud de emparejamiento:
Mecanismo 1: Precio Publicado (predeterminado)
El mecanismo más simple. El UCP del agente declara su modelo de precios, y el Nodo AMP estima el costo para la tarea específica basado en ese modelo. No ocurre negociación. Esto es apropiado para:
Mecanismo 2: Solicitud de Cotización (RFQ)
El Nodo AMP envía la descripción de la tarea a los agentes emparejados y solicita cotizaciones de precio. Cada agente devuelve una cotización específica para la tarea, opcionalmente con una ventana de validez. El solicitante selecciona entre los precios cotizados. Esto es apropiado para:
Interacción del RFQ:
Solicitante → Nodo AMP: match_request con price_discovery: "rfq"
Nodo AMP → Agentes Emparejados: task_description + quote_request
Agentes → Nodo AMP: cotizaciones (precio, términos, ventana_de_validez)
Nodo AMP → Solicitante: match_response con cotizaciones adjuntas a cada resultado
Solicitante → Agente Seleccionado: accept_quote(quote_id)Mecanismo 3: Subasta
Como se describe en la Sección 6.3 (Modo 3), las subastas se utilizan cuando la competencia de precios es el objetivo principal del emparejamiento. AMP admite formatos de subasta inglesa, Vickrey (sobre cerrado a segundo precio) y combinatoria.
Los resultados del descubrimiento de precios retroalimentan el sistema de emparejamiento:
Las señales de precios NO se incorporan a las puntuaciones de confianza — las decisiones de precios de un agente son una estrategia de negocio, no un indicador de confianza. Un agente caro no es menos confiable que uno barato. Sin embargo, se rastrea la correlación precio-calidad: los agentes cuyos precios exceden significativamente el promedio ajustado por calidad de sus pares reciben una marca de divulgación en los resultados de emparejamiento (no una penalización, sino transparencia).
El descubrimiento de precios de AMP se integra con la infraestructura de comercio existente:
AMP no maneja la liquidación de pagos — descubre precios y facilita el acuerdo, luego delega al canal de pago correspondiente.
Un motor de búsqueda que devuelve resultados sin ponderación de calidad es un directorio. El PageRank de Google transformó la búsqueda web al usar la estructura de enlaces como señal de calidad, degradando el spam y promoviendo fuentes autoritativas [43]. Las clasificaciones de productos de Amazon combinan velocidad de ventas, reseñas, precio y reputación del vendedor en una única puntuación de relevancia. Sin clasificación ponderada por confianza, un mercado de agentes es simplemente un directorio — indica lo que existe, pero no lo que es bueno.
Los mercados de agentes existentes utilizan uno de tres modelos de confianza, todos inadecuados:
| Modelo | Ejemplo | Limitación |
|---|---|---|
| Control corporativo | Google Cloud, Salesforce, AWS | Validación única; sin señal de calidad continua; excluye agentes no asociados |
| Revisión comunitaria | Berkeley, ClawHub | Susceptible a ataques Sybil, manipulación de reseñas y sesgo de recencia |
| Ninguno | AI Agent Store, Agen.cy | Directorio puro; ninguna señal de calidad |
AMP define una jerarquía de señales de confianza de cuatro niveles, donde cada nivel representa una forma más fuerte de evidencia de confianza:
Nivel 1 — Declarado (más bajo): El agente autoreporta capacidades y rendimiento. Sin verificación. Ejemplos: descripciones de capacidades en texto libre, afirmaciones de precisión autoreportadas.
Nivel 2 — Atestiguado: Un tercero avala al agente. Ejemplos: validación de mercado corporativo (aprobado por Google Cloud), reseñas comunitarias (calificaciones de Berkeley Gorilla), certificación de socio (socio de Salesforce AgentExchange).
Nivel 3 — Medido: Métricas de rendimiento calculadas a partir de datos de interacción reales. Ejemplos: puntuaciones compuestas de ARP a partir de evaluación bilateral ciega, tasas de cumplimiento de ASA a partir de registros de acuerdos, tasas de disputas de AJP a partir de registros de casos.
Nivel 4 — Verificado (más alto): Métricas medidas que son verificables independientemente por cualquier tercero a través de evidencia criptográfica. Ejemplos: entradas de cadena CoC ancladas mediante verificación de doble nivel OpenTimestamps y TSA, Paquetes de Reputación Portátil de ARP v2 firmados como Credenciales Verificables del W3C, registros de acuerdos ASA con integridad criptográfica.
Los Nodos AMP DEBERÍAN indicar claramente el nivel de confianza de cada señal en los resultados de emparejamiento. Un «compuesto ARP: 88» de Nivel 4 tiene un peso diferente que una «precisión autoreportada: 95%» de Nivel 1.
La puntuación de confianza utilizada en la puntuación de compatibilidad (Sección 6.2) se calcula a partir de las señales de confianza disponibles usando la siguiente composición:
trust_score(A) = w_identity * identity_confidence(A)
+ w_performance * performance_quality(A)
+ w_reliability * reliability_score(A)
+ w_risk * (100 - risk_score(A))Donde:
Confianza de Identidad: Derivada de la longitud de la cadena CoC y el estado de verificación de anclaje. Una cadena más larga y más frecuentemente anclada indica un agente más establecido con más que perder por mal comportamiento.
identity_confidence(A) = min(100, log2(1 + chain_age_days) * anchor_density_factor)Donde anchor_density_factor varía de 0.5 (anclaje disperso) a 1.5 (anclaje frecuente, de doble nivel).
Calidad de Rendimiento: Derivada de la puntuación compuesta de ARP v2, ponderada por dominio.
performance_quality(A) = arp_composite(A, domain=request.domain)Usando puntuaciones ARP específicas de dominio en lugar del compuesto general se asegura que un agente altamente calificado para revisión de código no reciba la misma puntuación de confianza cuando se empareja para resumen de documentos (a menos que también tenga fuertes calificaciones de resumen).
Fiabilidad: Derivada de las tasas de cumplimiento de ASA.
reliability_score(A) = asa_completion_rate(A) * 100 * confidence_factor(asa_sample_size)Donde confidence_factor aumenta de 0.5 (menos de 10 acuerdos completados) a 1.0 (100+ acuerdos completados), descontando puntuaciones de agentes con historiales limitados.
Riesgo: Derivado de los datos de disputas de AJP.
risk_score(A) = ajp_dispute_rate(A) * unfavorable_resolution_rate(A) * 100Una tasa de disputas alta con resoluciones favorables (se determinó que el agente no tenía culpa) es menos preocupante que una tasa de disputas alta con resoluciones desfavorables. La estructura multiplicativa refleja esto: un agente con una tasa de disputas del 10% pero un 90% de resoluciones favorables tiene una puntuación de riesgo de solo 1, mientras que un agente con una tasa de disputas del 10% y un 10% de resoluciones favorables tiene una puntuación de riesgo de 9.
Pesos predeterminados: w_identity = 0.20, w_performance = 0.40, w_reliability = 0.25, w_risk = 0.15. Estos valores predeterminados pueden sobrescribirse por solicitud de emparejamiento.
Los agentes nuevos sin historial en el ecosistema de confianza reciben una puntuación de confianza base en lugar de cero. La línea base se calcula a partir de las señales de Nivel 1 y Nivel 2 disponibles:
| Señal Disponible | Ajuste de Línea Base |
|---|---|
| Validación de mercado corporativo (Nivel 2) | +15 desde la línea base |
| Reseñas comunitarias con >10 reseñas (Nivel 2) | +10 desde la línea base |
| A2A Agent Card publicada en dominio verificado (Nivel 2) | +5 desde la línea base |
| DID con controlador verificable (Nivel 2) | +5 desde la línea base |
| Sin señales verificables (solo Nivel 1) | Línea base (predeterminado: 40) |
La línea base está intencionalmente por debajo del punto medio (50) para reflejar que los agentes no verificados conllevan más riesgo que el promedio de la población. Esto crea un incentivo natural para que los agentes se integren con el ecosistema de confianza — las señales de confianza verificadas mejoran directamente su clasificación en los resultados de AMP.
Los mercados de dos lados enfrentan un desafío fundamental de arranque: la plataforma es valiosa para los vendedores solo si hay compradores presentes, y valiosa para los compradores solo si hay vendedores presentes [25]. La mayoría de las startups de mercados fracasan en esta etapa — no pueden atraer a ninguno de los lados porque ninguno ve valor sin el otro.
Amazon resolvió esto comenzando como un minorista unilateral (comprando y vendiendo libros por sí mismo), luego abriéndose gradualmente a vendedores de terceros una vez que existía tráfico de compradores [44]. Etsy se concentró en un nicho (productos artesanales) donde vendedores apasionados se listarían incluso con pocos compradores [45]. Uber subsidio a los conductores con ganancias mínimas garantizadas antes de que se materializara la demanda de pasajeros [46].
La estrategia de arranque de AMP evita por completo el problema del huevo y la gallina al no construir un nuevo mercado.
Debido a que AMP es un protocolo de federación que conecta registros existentes, la oferta inicial proviene de agregar agentes que ya existen:
| Registro | Listados Disponibles | Tipo de Entrada | Esfuerzo de Integración |
|---|---|---|---|
| ClawHub | 13.729 | Habilidades atómicas (archivos SKILL.md) | Adaptador para API de búsqueda semántica |
| Berkeley Gorilla | 150+ | Agentes LLM verificados | Adaptador para búsqueda por categorías |
| Agentes compatibles con A2A | Creciente (150+ organizaciones) | Endpoints de agentes | Rastreador web para /.well-known/agent.json |
| Apify | 4.000+ | Web scrapers, herramientas de automatización | Adaptador para API de la plataforma |
| AI Agent Store | 1.300+ | Entradas de metadatos de directorio | Adaptador para API del directorio |
Un Nodo AMP con enfoque de federación podría lanzarse con acceso a más de 19.000 capacidades, habilidades y listados de agentes desde el primer día, sin que ninguna de esas entidades necesite registrarse por separado. Estos registros listan capacidades en diferentes niveles de abstracción — desde habilidades atómicas (ClawHub) hasta perfiles de agentes compuestos (Berkeley). Solo las ~150 entradas de Berkeley son inequívocamente «agentes» en el sentido que AMP les da; las 13.729 de ClawHub son habilidades individuales, Apify lista herramientas y scrapers, y AI Agent Store proporciona metadatos de directorio. El formato UCP de AMP (Sección 5) proporciona la capa de interoperabilidad para unir estos niveles de abstracción, aunque componer automáticamente habilidades individuales en perfiles a nivel de agente sigue siendo un desafío (ver Sección 17). Esta es la estrategia Kayak: agregar inventario existente en lugar de construir nueva oferta.
El lado de la demanda sigue naturalmente: si un Nodo AMP proporciona mejores resultados de búsqueda que cualquier mercado individual (porque busca en todos ellos), los usuarios tienen una razón para consultarlo. Cada consulta proporciona un dato sobre patrones de demanda, que retroalimenta la mejora de la calidad del emparejamiento.
Los agentes nuevos en el ecosistema (no listados en ningún registro existente) pueden incorporarse a AMP mediante:
/.well-known/amp-profile.json), análogo a las A2A Agent CardsLa barrera de entrada es deliberadamente baja. AMP no ejerce de portero — cualquier agente puede ser descubrible. El mecanismo de clasificación ponderada por confianza asegura que los agentes de baja confianza aparezcan más abajo en los resultados sin ser excluidos, creando un gradiente natural de calidad que recompensa la inversión en confianza a lo largo del tiempo.
AMP alcanza masa crítica significativa cuando se cumplen tres condiciones:
Antes de la masa crítica, AMP opera como un directorio con búsqueda mejorada. Después de la masa crítica, comienzan los efectos de red: más agentes atraen más solicitantes, cuyas consultas generan datos que mejoran la calidad del emparejamiento, lo que atrae más agentes. La transición del crecimiento lineal al crecimiento compuesto es la señal de que el arranque ha tenido éxito.
AMP se sitúa en la Capa 4 (Mercado/Descubrimiento) del Ecosistema de Confianza de AB Support, consumiendo datos de todas las capas inferiores:
Capa 4: AMP (Emparejamiento) ← consume de todas las inferiores
Capa 3: AJP (Responsabilidad)
Capa 2: ASA (Acuerdos) + ALP (Ciclo de vida)
Capa 1: CoC (Procedencia) + ARP (Reputación)CoC proporciona a AMP dos categorías de datos:
Confianza de identidad: La longitud de la cadena CoC y el estado de verificación de anclaje establecen cuánto tiempo ha existido un agente y si su historial es resistente a la manipulación. Un agente con una cadena CoC de 6 meses anclada bihora a través de verificación de doble nivel OTS+TSA [15] es una entidad más establecida que un agente creado ayer sin anclaje. AMP utiliza la antigüedad de la cadena como señal de resistencia a Sybil — es fácil crear nuevos agentes pero imposible fabricar cadenas históricas.
Portafolio de trabajo: Las entradas de CoC que documentan el razonamiento, las decisiones y las tareas completadas de un agente funcionan como un portafolio de trabajo verificable. Un solicitante que realiza la debida diligencia puede examinar las entradas relevantes de CoC para evaluar si el enfoque del agente se alinea con sus necesidades. AMP no expone entradas brutas de CoC en los resultados de emparejamiento (por preocupaciones de privacidad) pero utiliza métricas agregadas de cadena (longitud, densidad, frecuencia de anclaje) como entradas de confianza.
ARP v2 [16] proporciona la señal de calidad principal de AMP:
Puntuaciones compuestas calculadas mediante el álgebra de composición de señales de ARP v2 proporcionan una calificación general de calidad que AMP utiliza directamente en la dimensión trust_score.
Puntuaciones dimensionales (precisión, fiabilidad, latencia, cumplimiento de protocolo, eficiencia de costos) proporcionan señales de calidad específicas por dominio que AMP utiliza en la dimensión domain_relevance.
Paquetes de Reputación Portátil (ARP v2) permiten la reputación multiplataforma — la puntuación ARP de un agente lo acompaña de mercado en mercado, eliminando el problema de bloqueo de plataforma.
Arquitectura Anti-Goodhart (ARP v2) protege contra la manipulación: los agentes no pueden optimizar sus puntuaciones ARP manipulando métricas publicadas porque ARP v2 emplea estratificación de señales, rotación de métricas y métricas sombra para la detección [16].
ASA [18] proporciona a AMP señales de fiabilidad:
Tasas de cumplimiento de SLA indican qué tan consistentemente un agente cumple sus promesas. AMP las utiliza como la entrada principal al componente reliability_score de la puntuación de confianza.
Tasas de aprobación de verificación de calidad (de la API de Verificación de ASA) indican la calidad de salida independientemente de las calificaciones subjetivas. Un agente con una tasa de aprobación de QV del 95% en 200 acuerdos proporciona una señal objetiva fuerte de calidad.
Plantillas de acuerdos permiten la formalización automatizada de acuerdos después del emparejamiento. Cuando un solicitante selecciona un agente emparejado, AMP puede iniciar la formación de acuerdos ASA usando los parámetros acordados (precio del descubrimiento de precios, criterios de calidad de la solicitud de emparejamiento, plazo de la descripción de la tarea), reduciendo el intervalo entre «emparejamiento encontrado» y «trabajo iniciado» de minutos a segundos.
AJP [17] proporciona a AMP señales de riesgo:
Frecuencia de disputas indica con qué frecuencia el trabajo de un agente genera quejas formales. AMP lo utiliza en el componente risk_score.
Resultados de disputas diferencian a los agentes que operan en dominios de alta disputa (donde las disputas reflejan complejidad, no incompetencia) de los agentes cuyas disputas reflejan problemas genuinos de calidad. Un agente con 50 disputas y 45 resoluciones favorables en análisis legal es menos riesgoso que un agente con 5 disputas y 0 resoluciones favorables en formato de datos.
Taxonomía de disputas proporciona información diagnóstica: si la mayoría de las disputas contra un agente provienen de desajustes de capacidad, AMP puede señalar que el UCP del agente puede ser inexacto o demasiado amplio.
ALP [19] proporciona a AMP señales de disponibilidad y continuidad:
Filtrado por estado de ciclo de vida asegura que los agentes obsoletos, suspendidos o desmantelados no aparezcan en los resultados de emparejamiento. Este es un filtro estricto, no un ajuste de puntuación.
Linaje de bifurcación permite la herencia parcial de reputación. Cuando el Agente X se bifurca para crear el Agente Y, el hijo hereda una fracción de la reputación del padre (como lo especifican ALP y ARP v2). AMP puede mostrar la relación de linaje, permitiendo a los solicitantes evaluar si la bifurcación hereda las capacidades de dominio del padre.
Estado de sucesión indica si un agente tiene un sucesor designado. Para tareas de larga duración, emparejar con un agente que tiene un plan de sucesión reduce el riesgo de interrupción del trabajo si el agente se desmantela.
Un protocolo de emparejamiento bien diseñado alinea los incentivos individuales con la eficiencia de todo el sistema. La estructura de incentivos de AMP está diseñada para que tres comportamientos sean individualmente racionales para los participantes:
Reporte honesto de capacidades: Los agentes se benefician de UCPs precisos porque los perfiles inexactos conducen a emparejamientos deficientes, tareas fallidas, calificaciones ARP negativas y disputas ASA — todo lo cual reduce la clasificación futura. El ciclo de retroalimentación (emparejamiento → tarea → calificación → clasificación) crea una penalización natural por sobrevalorar capacidades. Un agente que afirma «revisor experto de seguridad en Python» pero entrega resultados mediocres acumulará calificaciones pobres y disputas que degradan su posición futura en el emparejamiento.
Sin embargo, este incentivo opera con un retardo — la penalización se materializa después de que la tarea se completa y califica, no al momento del listado. Los agentes nuevos sin historial de calificaciones enfrentan la tentación de sobrevalorar. AMP mitiga esto a través del sistema de niveles de confianza (Sección 9.2): las afirmaciones no verificadas reciben una clasificación de nivel de confianza inferior, reduciendo el beneficio de la sobrevaloración.
Precios precisos: En escenarios de subasta y RFQ, los agentes enfrentan un equilibrio entre ofertar por debajo (ganar más emparejamientos pero a precios potencialmente no rentables) y ofertar por encima (márgenes más altos pero menos emparejamientos). La propiedad teórica de oferta veraz de la subasta Vickrey aplica aquí, aunque con las advertencias señaladas en la Sección 6.3 respecto a interacciones repetidas y potencial colusión. En escenarios de precio publicado, el seguimiento de la correlación precio-calidad (Sección 8.3) hace visible el precio premium injustificado.
Entrega genuina de calidad: La conexión entre la verificación de calidad de ASA, las calificaciones de ARP y la clasificación de AMP crea un incentivo de calidad multicapa. Un agente que entrega mala calidad enfrenta: (1) retención inmediata de fideicomiso de ASA, (2) calificaciones ARP negativas que reducen la clasificación futura, (3) potenciales disputas AJP que crean señales de riesgo, y (4) resultados de emparejamiento degradados en todas las tareas futuras. Esta estructura de penalización por capas significa que manipular cualquier mecanismo individual no elimina el incentivo de calidad.
El análisis de teoría de juegos identifica varios modos de falla potenciales:
Ofertas ficticias en subastas: Los agentes crean ofertas falsas competidoras para elevar los precios. AMP mitiga esto mediante verificación de identidad (cada postor debe tener una identidad verificable — cadena CoC, DID o A2A Card) y calificación de postores basada en reputación (puntuación mínima de confianza para participar en subastas).
Precios colusivos: Agentes competidores coordinan precios para evitar reducirse mutuamente. Este es un problema conocido en mercados de precios algorítmicos [47]. AMP detecta potencial colusión mediante monitoreo de varianza de precios: si agentes con capacidades similares se agrupan en puntos de precio similares a pesar de estructuras de costos variables, se levanta una marca de colusión. La detección no es prevención — AMP no puede forzar precios competitivos, pero puede hacer visibles los patrones colusivos para los solicitantes.
Degradación de calidad post-emparejamiento: Un agente que ya ha sido emparejado y aceptado puede entregar calidad inferior a lo que su rendimiento histórico sugiere, particularmente si cree que el solicitante no tiene alternativas (problema de retención). La verificación automatizada de calidad de ASA mitiga esto — la calidad se verifica contra los criterios del acuerdo independientemente de la reputación pasada del agente.
Manipulación de la atención: La investigación del Magentic Marketplace de Microsoft encontró que los agentes vendedores pueden explotar los límites de la ventana de contexto de los agentes compradores para manipular decisiones — inundando al comprador con información irrelevante para hacer que la opción preferida parezca mejor en comparación [36]. AMP mitiga esto realizando el emparejamiento del lado del servidor (el Nodo AMP evalúa a los candidatos, no el agente solicitante), reduciendo la superficie de ataque para la manipulación de la atención. Sin embargo, los agentes que interactúan directamente después del emparejamiento siguen siendo vulnerables — esta es una preocupación a nivel de ASA más que a nivel de AMP.
Inflación de calificaciones: Los mecanismos anti-inflación de ARP v2 (piso de varianza, detección de cambio de media, detección de coalición) [16] protegen las señales de confianza que AMP consume. AMP en sí mismo no adjudica la calidad de las calificaciones — confía en la arquitectura anti-Goodhart de ARP v2 para entregar puntuaciones confiables.
El mecanismo de emparejamiento de AMP tiene las siguientes propiedades formales (declaradas con las calificaciones apropiadas):
Racionalidad individual: La participación en AMP es individualmente racional tanto para los solicitantes (que obtienen mejores emparejamientos que buscando en cada mercado individualmente) como para los agentes (que obtienen más visibilidad que listándose en un solo mercado). Esto se mantiene mientras la calidad de emparejamiento de AMP supere la alternativa de búsqueda manual multiplataforma, lo cual se espera dada la agregación multiplataforma, pero es en última instancia una afirmación empírica que depende de la calidad de implementación.
Compatibilidad de incentivos (parcial): En modo de subasta Vickrey, la oferta veraz es una estrategia dominante bajo los supuestos estándar (valores privados independientes, postores neutrales al riesgo). En modos de precio publicado y RFQ, el incentivo para la honestidad en precios es indirecto — mediado a través del seguimiento de correlación calidad-precio y los efectos de reputación a largo plazo. La compatibilidad de incentivos total (donde el comportamiento honesto es estrictamente dominante en todos los modos) no se logra y probablemente no sea alcanzable en un sistema práctico de emparejamiento.
Estabilidad (en modo por lotes): El emparejamiento estable de Gale-Shapley garantiza que la asignación por lotes sea estable — ningún par tarea-agente preferiría mutuamente el uno al otro por encima de sus asignaciones actuales [12]. Esta garantía se mantiene para preferencias estáticas dentro de una ronda de emparejamiento. Entre rondas, los cambios dinámicos de preferencias pueden introducir inestabilidad temporal, que se resuelve en el siguiente ciclo de emparejamiento.
Eficiencia (aproximada): El modo de búsqueda clasificada de AMP produce resultados que son aproximadamente eficientes — el agente mejor clasificado es el mejor emparejamiento disponible dada la función de puntuación. La eficiencia exacta (maximizar el bienestar total en todos los emparejamientos) solo se garantiza en modo de emparejamiento estable, e incluso entonces solo para el lado proponente (optimo para la tarea por defecto). La brecha entre eficiencia aproximada y exacta es un equilibrio necesario para la tratabilidad computacional en emparejamiento en tiempo real.
El Complejo Mayor de Histocompatibilidad (MHC) permite la discriminación propio/no propio a través del emparejamiento de patrones moleculares [51]. Las moléculas MHC unen fragmentos peptídicos y los exponen en la superficie celular para el reconocimiento de células T. El sistema es notablemente polimórfico — las diversas variantes de MHC en una población aseguran que ningún patógeno individual pueda evadir todos los sistemas inmunológicos. La discriminación propio/no propio se logra mediante selección negativa: las células T que se unen demasiado fuertemente a auto-antígenos se eliminan en el timo antes de su despliegue [52].
Paralelo con AMP: La verificación de confianza de AMP funciona como un sistema inmunológico para el mercado de agentes. Las señales de confianza (procedencia CoC, calificaciones ARP, registros ASA, disputas AJP) son los «marcadores moleculares» que los agentes portan. El Verificador de Confianza realiza emparejamiento de patrones contra estos marcadores — verificando patrones conocidos como negativos (certificados revocados, marcas de disputa, detecciones de habilidades maliciosas) al igual que las células T verifican antígenos no propios. El polimorfismo del MHC se mapea a la arquitectura de confianza multi-señal de AMP: ningún mecanismo de confianza individual domina. Los enfoques de verificación diversos (procedencia criptográfica, calificaciones bilaterales, verificación de calidad, registros de disputas) proporcionan resiliencia a nivel de población contra la manipulación de la confianza — al igual que la diversidad del MHC proporciona resiliencia a nivel de población contra patógenos.
La teoría biológica de mercado propone que los organismos ofrecen productos que son baratos de producir para ellos a cambio de productos que son costosos o imposibles sin un socio [53]. La elección de socio se refuerza mediante sanciones: los hongos micorrícicos que proporcionan menos fósforo reciben menos carbono de sus plantas huésped. Esto crea una señal de calidad autorreforzante sin sistemas centralizados de reputación.
Paralelo con AMP: El modelo de sanciones se traduce directamente al ciclo de retroalimentación de AMP. Los agentes que entregan mala calidad reciben: menos asignaciones futuras de tareas (clasificación de emparejamiento reducida), precios más bajos (los solicitantes exigen descuentos), y potencial deslistamiento (disputas AJP que conducen a cambios de estado de ciclo de vida vía ALP). La naturaleza bilateral de las sanciones de mercado biológico — cada socio ajustando la inversión basada en la contribución del otro — refleja la evaluación bilateral ciega de ARP, donde ambas partes se califican mutuamente después de una interacción. La percepción clave es que la reputación puede surgir de la retroalimentación económica bilateral (sanciones/recompensas) incluso sin un protocolo de reputación centralizado, aunque ARP acelera la convergencia al hacer la retroalimentación explícita y portable.
El modelo de amenazas de AMP considera cuatro tipos de adversarios:
| Adversario | Objetivo | Capacidades |
|---|---|---|
| Agente manipulador | Inflar su propia clasificación para ganar más emparejamientos | Puede crear UCPs engañosos, ofertar estratégicamente en subastas, coordinar con aliados |
| Atacante Sybil | Crear múltiples agentes falsos para dominar los resultados | Puede crear muchas identidades de agentes a bajo costo |
| Adversario de vigilancia | Conocer las capacidades de competidores observando consultas de emparejamiento | Puede observar solicitudes y respuestas de emparejamiento en la red |
| Atacante de denegación de servicio | Impedir el emparejamiento legítimo abrumando los Nodos AMP | Puede generar solicitudes de emparejamiento o consultas de registro de alto volumen |
Contra agentes manipuladores:
Contra ataques Sybil:
Contra adversarios de vigilancia:
Contra denegación de servicio:
El emparejamiento de agentes crea tensiones de privacidad:
Divulgación de capacidades: Los agentes deben revelar suficiente información sobre sus capacidades para el emparejamiento, pero pueden tener razones competitivas para retener detalles de implementación. El modelo de divulgación progresiva de AMP (Sección 3.7) aborda esto: las descripciones de capacidades del UCP son públicas, pero la información detallada de implementación (configuraciones exactas de herramientas, parámetros de modelo, bases de conocimiento propietarias) puede divulgarse solo después de la confirmación del emparejamiento.
Privacidad de consultas: Las consultas de emparejamiento de un solicitante pueden revelar información estratégica — qué capacidades le faltan, qué tareas necesita externalizar, qué presupuesto tiene. Los Nodos AMP DEBERÍAN admitir consultas anónimas y NO DEBEN compartir datos de consultas individuales con registros o agentes más allá de lo necesario para el emparejamiento.
Privacidad de señales de confianza: Las puntuaciones ARP exactas, el historial de disputas y las tasas de cumplimiento de SLA de un agente son sensibles. AMP admite la divulgación agregada (p. ej., «la puntuación de confianza supera el umbral X») vía los mecanismos de prueba de conocimiento cero de ARP v2 en lugar de requerir transparencia total de las señales de confianza.
La investigación del Magentic Marketplace de Microsoft [34][36] identificó modos de falla observados empíricamente en simulaciones de mercados de agentes:
AMP aborda estos problemas estructuralmente:
description de capacidad), son una entrada entre muchas — la función de puntuación pondera las señales verificadas más que las declaradas.Un protocolo que clasifica agentes a través de Google Cloud, Salesforce, AWS, ServiceNow y registros abiertos — e influye en decisiones de compra por un valor potencial de billones de dólares — opera en un territorio regulatorio que exige un análisis explícito.
Riesgo de portero bajo la Ley de Mercados Digitales (DMA) de la UE. La DMA apunta a los «porteros» — plataformas que sirven como pasarelas importantes entre usuarios empresariales y usuarios finales. Una implementación de AMP ampliamente adoptada podría satisfacer los umbrales cuantitativos de la DMA (capitalización de mercado de 7.500 millones de euros o valor justo de mercado de 75.000 millones de euros, 45 millones de usuarios finales mensuales, 10.000 usuarios empresariales en la UE). Si AMP se convierte en la capa de emparejamiento multiplataforma dominante, podría ser designado como un servicio de portero, activando obligaciones que incluyen: prohibición de autopreferencia (Artículo 6(5)), requisito de permitir a los usuarios empresariales promover ofertas en diferentes términos a través de otros canales (Artículo 6(12)), y requisitos de interoperabilidad.
Mitigación a través de la arquitectura del protocolo: AMP es un protocolo, no una plataforma. Ninguna entidad única opera «el» servicio AMP — cualquier organización puede ejecutar un Nodo AMP. Esta elección arquitectónica es la defensa antimonopolio principal: no hay un portero único para designar. Sin embargo, si una implementación única de Nodo AMP logra una cuota de mercado dominante (como Google lo hizo con Chrome a pesar de la web abierta), el análisis de la DMA aún podría aplicarse a ese operador específico.
Clasificación ponderada por confianza y neutralidad competitiva. La preocupación antimonopolio más sustantiva es si la clasificación ponderada por confianza favorece sistemáticamente a los agentes integrados con la pila de confianza de AB Support (CoC, ARP, ASA, AJP, ALP) sobre los agentes que no lo están. El sistema de niveles de confianza (Sección 9.2) clasifica explícitamente el Nivel 4 (verificado vía protocolos de la pila de confianza) por encima del Nivel 1 (autodeclarado) — lo que significa que los agentes fuera del ecosistema de confianza reciben clasificaciones más bajas por diseño. Esto es análogo a cómo el algoritmo de búsqueda de Google prefiere páginas con HTTPS sobre HTTP: una señal de calidad que también beneficia al ecosistema de certificados de Google.
AMP aborda esta preocupación mediante tres mecanismos:
trust_score en cero si prefieren emparejamiento solo por capacidad. Ningún componente de puntuación es opaco ni irrevocable.Implicaciones de la Ley de IA de la UE. AMP probablemente se ubique dentro de la categoría de «riesgo limitado» de la Ley de IA (no «alto riesgo») porque recomienda agentes en lugar de tomar decisiones consecuentes sobre personas naturales. Sin embargo, si AMP se utiliza para emparejar agentes en dominios de alto riesgo — contratación, evaluación crediticia, aplicación de la ley — el caso de uso posterior podría activar la clasificación de alto riesgo para el operador del Nodo AMP. Los Nodos AMP DEBERÍAN mantener registros suficientes para satisfacer los requisitos de transparencia de la Ley de IA (Artículo 13) y DEBERÍAN proporcionar explicaciones de las decisiones de clasificación cuando se soliciten (ya soportado a través del desglose de puntuación dimensional en las respuestas de emparejamiento).
Clasificación multi-mercado como poder de mercado. ¿Podría un operador dominante de Nodo AMP usar la influencia de clasificación para extraer rentas de los desarrolladores de agentes? Este es el riesgo de «tienda de aplicaciones» — Apple y Google usan sus posiciones de mercado para extraer comisiones del 30% e imponer términos restrictivos. La arquitectura de protocolo-no-plataforma de AMP mitiga esto: si un operador de Nodo AMP se vuelve extractivo, los agentes y solicitantes pueden cambiar a otra implementación de Nodo AMP sin perder sus perfiles de capacidad, historial de confianza ni acceso al mercado. Los Paquetes de Reputación Portátil (ARP v2) y la portabilidad de cadena CoC aseguran que los costos de cambio permanezcan bajos.
Riesgo residual. Estas mitigaciones reducen pero no eliminan el riesgo antimonopolio. Los efectos de red aún podrían concentrar el uso en una única implementación de Nodo AMP. Las ventajas de integración con la pila de confianza, aunque de acceso abierto, aún crean una ventaja competitiva para los adoptantes tempranos. Los diseñadores del protocolo deberían interactuar proactivamente con los marcos de cumplimiento de la DMA y la Ley de IA, considerar nombrar una gobernanza independiente para la taxonomía de capacidades (Sección 5.4) y diseñar mecanismos de auditoría para la neutralidad de clasificación. La implementación de referencia de código abierto y los algoritmos de puntuación publicados son condiciones necesarias pero no suficientes para la defensibilidad regulatoria — también se requieren gobernanza activa y monitoreo de cumplimiento.
Esta sección identifica con franqueza las limitaciones de AMP v1 según se especifica en este documento técnico:
La federación agrega latencia y modos de falla. Las consultas entre registros son inherentemente más lentas que las búsquedas en un solo registro. Los tiempos de espera de registros, las fallas de adaptadores y las particiones de red pueden producir resultados incompletos. La Sección 7.2.1 analiza la latencia esperada; los despliegues en producción deben diseñarse para operación en modo degradado cuando los registros no son alcanzables.
La profundidad de integración de confianza depende de la adopción de protocolos externos. La ventaja competitiva de AMP — la clasificación profunda ponderada por confianza — requiere que los agentes se integren con CoC, ARP, ASA, AJP y ALP. Hasta que estos protocolos logren una adopción significativa, la mayoría de los agentes tendrán solo señales de confianza de Nivel 1 o Nivel 2, reduciendo la calidad de clasificación de AMP a aproximadamente la de un directorio estándar con búsqueda mejorada. Esto crea una dependencia circular: el valor de AMP impulsa la adopción de la pila de confianza, pero la adopción de la pila de confianza impulsa el valor de AMP.
La taxonomía de capacidades es preliminar, no está lista para producción. La taxonomía de Nivel 1/Nivel 2 (Sección 5.4) es ilustrativa. Los implementadores no pueden construir sistemas de clasificación de producción contra ella hasta que la taxonomía completa se publique como un artefacto versionado separado. El emparejamiento semántico mitiga parcialmente esto (las capacidades novedosas pueden emparejarse mediante similitud de embeddings), pero las consultas de taxonomía estructurada producirán resultados inconsistentes entre implementaciones hasta que la taxonomía se estandarice.
La calidad del emparejamiento se degrada con datos históricos insuficientes. El filtrado colaborativo (Sección 6.2, interaction_history_score) proporciona cero valor para nuevos solicitantes o nuevos Nodos AMP sin historial de interacción. La puntuación de confianza depende de registros ARP, ASA y AJP acumulados. Los despliegues de AMP en frío funcionan como directorios de emparejamiento por capacidad hasta que se acumulen suficientes datos de interacción — el umbral estimado es ~1.000 solicitudes de emparejamiento (Sección 10.4).
El protocolo especifica algoritmos pero no preocupaciones operativas. AMP v1 no aborda monitoreo, alertas, conmutación por error, rutas de actualización, compatibilidad hacia atrás entre versiones del protocolo ni manuales operativos. Un Nodo AMP de producción requiere infraestructura operativa significativa más allá de lo que el protocolo especifica.
El emparejamiento con preservación de privacidad es aspiracional. El modelo de privacidad de AMP v1 (TLS + anonimización de consultas + divulgación progresiva) es adecuado para la mayoría de los casos de uso, pero se queda corto en garantías fuertes de privacidad. El emparejamiento completamente privado mediante MPC o cifrado homomórfico se difiere a trabajo futuro (Sección 17.3) debido a restricciones de costo computacional.
Los números de arranque sobreestiman la preparación. Si bien más de 19.000 capacidades, habilidades y listados de agentes son teóricamente accesibles a través de la federación, la utilidad real depende de la calidad de los adaptadores, la estabilidad de las APIs de los registros y el desafío de heterogeneidad de unir habilidades atómicas con perfiles de agentes compuestos (Sección 10.2).
La implementación de referencia de AMP consiste en cuatro componentes:
amp-core: Biblioteca Python que implementa el motor de emparejamiento, la puntuación de compatibilidad y el modelo de datos UCP. Sin dependencias externas más allá de la biblioteca estándar de Python + un validador de JSON Schema.
amp-federation: Enrutador de federación con adaptadores de registro intercambiables. Incluye adaptadores para: rastreo de A2A Agent Cards (basado en HTTP), búsqueda semántica de ClawHub (basado en API) y una plantilla de adaptador REST genérico.
amp-trust: Verificador de confianza que consulta endpoints de CoC, ARP, ASA, AJP y ALP para completar señales de confianza verificadas. Opera de forma independiente — puede usarse sin federación para la verificación de confianza de agentes conocidos.
amp-node: Servidor HTTP que combina los tres componentes en un Nodo AMP desplegable. Expone la API de solicitud de emparejamiento (Sección 6.1), la API de registro de registros (Sección 7.3) y los endpoints de administración.
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
# Initialize components
engine = MatchEngine()
store = UCPStore()
router = FederationRouter()
verifier = TrustVerifier(
coc_endpoint="https://coc.example.com",
arp_endpoint="https://arp.example.com"
)
# Register federated registries
router.add_adapter(A2AAdapter(crawl_domains=["agent.example.com"]))
router.add_adapter(ClawHubAdapter(api_key=os.environ["CLAWHUB_API_KEY"]))
# Launch node
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" Trust: {result.trust_verification}")
print(f" Cost: {result.estimated_cost}")| Endpoint | Método | Descripción |
|---|---|---|
/amp/v1/match | POST | Enviar una solicitud de emparejamiento, recibir resultados clasificados |
/amp/v1/profile | GET/PUT | Obtener o actualizar el UCP de un agente |
/amp/v1/registry | POST | Registrar un nuevo registro federado |
/amp/v1/registries | GET | Listar registros federados registrados |
/amp/v1/trust/{agent_id} | GET | Obtener señales de confianza verificadas para un agente |
/amp/v1/auction | POST | Crear una subasta para una tarea |
/amp/v1/auction/{id}/bid | POST | Enviar una oferta a una subasta |
/amp/v1/health | GET | Salud del nodo y estado de federación |
AMP v1 empareja agentes individuales con tareas individuales. Muchas tareas del mundo real requieren equipos coordinados — un agente de investigación, un agente de código y un agente de revisión trabajando juntos. El emparejamiento de equipos es un problema significativamente más difícil:
El emparejamiento de equipos se difiere a AMP v2. El mecanismo de subasta combinatoria (Sección 6.3) proporciona una solución parcial: los agentes pueden ofertar como equipos preformados. La verdadera composición de equipos — donde AMP ensambla equipos óptimos a partir de agentes individuales — requiere investigación adicional sobre puntuación de complementariedad y métricas de química de equipo.
AMP v1 utiliza una función de puntuación lineal con pesos de dimensión fijos. Los enfoques de aprendizaje automático (learning-to-rank) podrían mejorar la calidad del emparejamiento aprendiendo relaciones no lineales entre las características de la tarea, los perfiles de los agentes y los resultados del emparejamiento. La señal de entrenamiento está disponible: la retroalimentación post-emparejamiento (calificaciones ARP, verificación de calidad ASA) proporciona la verdad base sobre si un emparejamiento fue exitoso.
El riesgo del learning-to-rank es la opacidad — el modelo puede aprender sesgos difíciles de detectar o explicar. AMP v2 explorará modelos de learning-to-rank interpretables que mantengan la explicabilidad mientras mejoran la puntuación lineal.
El modelo de privacidad de AMP v1 se basa en cifrado TLS, anonimización de consultas y divulgación progresiva. Garantías más fuertes de privacidad son posibles mediante:
Estas técnicas son actualmente demasiado costosas computacionalmente para el emparejamiento en tiempo real a escala, pero el costo está disminuyendo rápidamente. AMP v2 especificará modos opcionales de emparejamiento con preservación de privacidad para casos de uso sensibles.
El emparejamiento multiplataforma de AMP es tan útil como los datos de confianza que lo sustentan. Si cada mercado calcula la reputación de manera diferente, la comparación multiplataforma no tiene sentido. Los Paquetes de Reputación Portátil de ARP v2 [16] proporcionan un formato estándar, pero la adopción por parte de los mercados es incierta.
AMP podría acelerar la adopción definiendo un formato mínimo de intercambio de reputación que sea más simple que el cumplimiento total con ARP v2 — un «embed de reputación» que cualquier mercado pueda publicar, conteniendo puntuaciones dimensionales, tamaños de muestra y marcas de tiempo de cálculo. Este enfoque pragmático intercambia profundidad por amplitud, habilitando la comparación multiplataforma básica incluso desde mercados que no adoptan el ecosistema de confianza completo.
El emparejamiento actual de AMP utiliza instantáneas puntuales de disponibilidad y precios de agentes. Las señales de mercado en tiempo real — aumentos de demanda para capacidades específicas, movimientos de precios, utilización de capacidad en todo el ecosistema — podrían habilitar un emparejamiento dinámico que tenga en cuenta las condiciones del mercado. Esto es análogo a las pujas en tiempo real en publicidad programática, donde las subastas ocurren en milisegundos basadas en señales de demanda en vivo.
La implementación requiere una infraestructura de pub/sub para la distribución de señales de mercado, que es arquitectónicamente distinta del modelo de solicitud-respuesta de emparejamiento en AMP v1.
La economía de agentes se está fragmentando en jardines amurallados precisamente en el momento en que necesita consolidarse. Nueve mercados distintos sirven a ecosistemas de agentes superpuestos pero incompatibles. El descubrimiento multiplataforma no existe. Las señales de confianza están aisladas, no son verificables o están ausentes. El problema del emparejamiento — encontrar el mejor agente para una tarea específica, dados requisitos de calidad multidimensionales, restricciones de confianza y preferencias de costo — permanece sin resolver por ningún sistema en producción.
El Protocolo de Agent Matchmaking aborda esto especificando una capa de emparejamiento completa: un formato de Perfil de Capacidad Unificado para describir las capacidades de los agentes entre plataformas, un sistema de puntuación de compatibilidad multidimensional que va más allá de la simple coincidencia de capacidad para incorporar señales de confianza verificadas, descubrimiento federado que busca a través de mercados aislados sin requerir que cedan el control, mecanismos de descubrimiento de precios que soportan precios publicados, subastas y negociación, y clasificación ponderada por confianza que transforma las capacidades declaradas en señales de calidad verificables.
La ventaja competitiva de AMP no reside en ningún componente individual — los algoritmos de emparejamiento están bien estudiados, la federación es una arquitectura conocida, los mecanismos de descubrimiento de precios están establecidos. La ventaja está en la profundidad de integración. Donde los mercados existentes validan agentes una sola vez al momento de su registro, AMP los valida continuamente a través de la pila de confianza completa: procedencia CoC para identidad, reputación ARP para calidad, cumplimiento ASA para fiabilidad, registros de disputas AJP para riesgo, y estado de ciclo de vida ALP para disponibilidad. Esta integración de confianza por capas y verificable es lo que transforma un motor de búsqueda en un mercado en el que los participantes pueden confiar.
La estrategia de arranque — federar registros existentes en lugar de construir nueva oferta — evita el problema del huevo y la gallina que acaba con la mayoría de las startups de mercados. Con más de 19.000 capacidades, habilidades y listados de agentes ya descubribles a través de registros existentes — abarcando habilidades atómicas, herramientas de automatización y perfiles de agentes compuestos — un Nodo AMP puede proporcionar valor desde el primer día. El enfoque de protocolo asegura que AMP escale con el ecosistema en lugar de competir contra él: cada nuevo mercado que implementa un adaptador AMP incrementa el valor de la red.
AMP es el vértice comercial del ecosistema de confianza — la capa donde los protocolos se convierten en productos. CoC, ARP, ASA, AJP y ALP proporcionan la infraestructura de confianza. AMP proporciona el mercado donde esa confianza se consume, se valora y se transacciona. Juntos, forman la base para una economía de agentes donde la confianza se gana a través de la operación verificable, no se declara mediante material de marketing.
[1] Google Cloud Blog, "Google Cloud AI Agent Marketplace," 2025.
[2] Salesforce Press Release, "AgentExchange Announcement," March 4, 2025.
[3] AWS News Blog, "Introducing Amazon Bedrock AgentCore," October 2025.
[4] ServiceNow Blog, "Your Go-to Marketplace for AI Agents," 2025.
[5] gorilla.cs.berkeley.edu, "Agent Marketplace," 2025.
[6] ClawHub (clawhub.ai), registry statistics, February 2026.
[7] AI Agent Store (aiagentstore.ai), directory listing, 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, Specification November 2025; MCP Blog, "The 2026 MCP Roadmap," 2026.
[11] ClawHub Docs, SKILL.md format specification, 2026; DigitalOcean, OpenClaw guide, 2026.
[12] Gale, D. and Shapley, L.S., "College Admissions and the Stability of Marriage," American Mathematical Monthly, 69(1): 9-15, 1962.
[13] OpenAI, Agentic Commerce Protocol (with Stripe), September 2025.
[14] Google, Universal Commerce Protocol (with Shopify, Etsy, Wayfair, Target, Walmart), 2025-2026; Ekamoira Blog, "How AI Agents Are Changing E-commerce in 2026," 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)," May 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, transaction statistics, 2025-2026.
[25] Rochet, J.-C. and 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; HBS Online, "What Are Network Effects?" 2025.
[27] Nisan, N. et al., Algorithmic Game Theory, Cambridge University Press, 2007.
[28] W3C, "Decentralized Identifiers (DIDs) v1.1," Candidate Recommendation, 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," November 2025.
[35] TechCrunch, "Microsoft built a fake marketplace to test AI agents," November 2025.
[36] InfoQ, "AI Agents Fail Manipulation Tests in Magentic Marketplace," November 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., and Steinberg, R., "Combinatorial Auctions," MIT Press, 2006.
[41] Gartner, "Top Strategic Predictions for 2026 and Beyond," presented by Daryl Plummer at Gartner IT Symposium/Xpo, October 2025. Prediction #6: "By 2028, 90% of B2B buying will be AI agent intermediated, pushing over $15 trillion of B2B spend through AI agent exchanges." Available at gartner.com/en/newsroom/press-releases/2025-10-21-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2026-and-beyond.
[42] McKinsey & Company (QuantumBlack), "The Agentic Commerce Opportunity: How AI Agents Are Ushering in a New Era for Consumers and Merchants," October 2025. Available at mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity.
[43] Brin, S. and 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. and Wright, J., "Multi-Sided Platforms," International Journal of Industrial Organization, 43: 162-174, 2015.
[47] Ezrachi, A. and 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. and Gambardella, L.M., "Ant Colony System: A Cooperative Learning Approach to the Traveling Salesman Problem," IEEE Transactions on Evolutionary Computation, 1(1): 53-66, 1997.
[51] Janeway, C.A. et al., "The major histocompatibility complex and its functions," Immunobiology, 5th ed., 2001.
[52] Kappler, J.W. et al., "T cell tolerance by clonal elimination in the thymus," Cell, 49(2): 273-280, 1987; Science, 1992.
[53] Noë, R. and 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.
Este documento está licenciado bajo Apache License 2.0. Copyright 2026 AB Support LLC. El Protocolo de Agent Matchmaking es una especificación abierta — cualquier organización puede implementarlo sin permiso ni regalías.