Agent Cards: cómo se encuentran los agentes entre sí (A2A Discovery)

Una Agent Card es un documento JSON legible por máquinas del protocolo A2A con el que un agente de IA publica su identidad, su endpoint, sus habilidades, capacidades, modalidades y esquemas de autenticación. Otros agentes leen esta tarjeta para decidir si le encargan una tarea al agente y cómo hacerlo. Así, la Agent Card es el mecanismo central mediante el cual los agentes se encuentran entre sí sin que nadie tenga que conectarlos antes de forma fija.

• Qué es: el perfil público de un agente, tarjeta de visita y descripción de interfaz en uno.
• Para qué sirve: descubrimiento de agentes. Un agente cliente comprueba habilidades, modalidades y autenticación antes de hacer un encargo (task).
• Por qué importa: sin Agent Card, un agente es invisible para otros sistemas y solo es accesible mediante una integración a medida.

A2A, MCP y el papel de la Agent Card

En el stack de protocolos de 2026 se han impuesto dos estándares abiertos. El Model Context Protocol (MCP), desarrollado por Anthropic, regula el acceso de los agentes a herramientas y datos, es decir, agente a herramienta. Desde diciembre de 2025, MCP está en la Agentic AI Foundation, bajo el paraguas de la Linux Foundation. El protocolo Agent2Agent (A2A) regula la colaboración entre agentes, es decir, agente a agente. La documentación de A2A delimita ambos así: a través de MCP, un agente utiliza capacidades como herramientas y recursos; a través de A2A, los agentes trabajan como socios en una tarea. Los dos protocolos se complementan.

La Agent Card es el componente de descubrimiento de capacidades de A2A. Mientras que un servidor MCP describe herramientas individuales, una Agent Card describe un agente completo como posible socio de colaboración. A2A se presentó en abril de 2025 en Google Cloud Next y el 23 de junio de 2025 se cedió a la Linux Foundation, con AWS, Cisco, Google, Microsoft, Salesforce, SAP y ServiceNow como miembros fundadores. Más de 100 empresas respaldan ya el protocolo (datos de 2026).

Estructura de una Agent Card

Una Agent Card es un documento JSON que un agente publica en una ruta conocida de su host. Contiene los siguientes componentes principales:

Lo decisivo es el principio de diseño que hay detrás: A2A define cómo hablan los agentes entre sí, no cómo piensan. La estructura interna de un agente remoto, es decir, sus prompts, su modelo y su memoria, permanece opaca de forma deliberada. Precisamente eso permite que un agente de Salesforce invoque a un agente de SAP sin que ninguna de las partes revele sus prompts, su modelo o sus datos. La Card es el único contrato que comparten ambas partes.

El mecanismo de descubrimiento

El descubrimiento mediante Agent Cards se presenta en dos variantes típicas.

Descubrimiento directo (punto a punto). Un agente cliente conoce la URL base de un agente remoto y obtiene su Agent Card. Comprueba si las habilidades anunciadas encajan con la tarea, si se admite la modalidad necesaria y si puede cumplir el esquema de autenticación. Solo entonces abre una tarea.

Descubrimiento basado en directorio (registro). En entornos más grandes, las Agent Cards se registran de forma centralizada. AGNTCY, el proyecto de código abierto impulsado por Cisco, ofrece para ello un Agent Directory: un registro federado en el que se pueden publicar, verificar y encontrar agentes A2A y servidores MCP. Describe habilidades y atributos con el Open Agentic Schema Framework (OASF). Así, un agente encuentra socios adecuados a través de un directorio en lugar de mediante direcciones fijas. SAP agrupa una función comparable en el SAP AI Agent Hub en SAP LeanIX. El hub está concebido como un centro de control independiente del fabricante, desde el que las empresas pueden encontrar, inventariar y gestionar agentes de SAP y de terceros, así como servidores MCP. En octubre de 2026, SAP describe el hub como disponible de forma general.

En cuanto se ha encontrado un socio, entra en juego el ciclo de vida de las tareas A2A. Según la especificación de A2A, una tarea pasa por los estados submitted y working, se pausa en input-required cuando surgen preguntas o en auth-required cuando se necesita autenticación adicional, y termina en completed, failed, canceled o rejected. En el JSON de la especificación 1.0, estos estados se llaman TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_INPUT_REQUIRED, y así sucesivamente. El transporte se realiza mediante JSON-RPC 2.0 y HTTPS, y la especificación define además bindings para gRPC y HTTP+JSON. Los estados intermedios se transmiten en streaming mediante Server-Sent Events y, para ejecuciones largas, hay notificaciones push opcionales. El resultado de una tarea vuelve como uno o varios Artifacts, y los mensajes pueden ser multiparte y multimodales.

En el ámbito de la investigación, el proyecto NANDA del MIT Media Lab muestra hacia dónde podría evolucionar el descubrimiento a largo plazo: un índice de agentes descentralizado con AgentFacts verificables criptográficamente y Zero Trust Agentic Access. En 2026, sin embargo, se trata de un desarrollo en fase de investigación y no de una base para decisiones de producción.

Ejemplo: descubrimiento entre dos agentes

Supongamos que un agente de CRM en Salesforce tiene que someter a una revisión previa las facturas entrantes de proveedores y, para ello, recurre a un agente especializado en facturas de una agencia.

La Agent Card del agente de facturas, abreviada y con los nombres de campo de la especificación de A2A 1.0:

• "name": "Invoice-Triage-Agent", "version": "2.0.0"
• "supportedInterfaces": [{ "url": "https://agents.example.com/a2a", "protocolBinding": "JSONRPC", "protocolVersion": "1.0" }]
• "capabilities": { "streaming": true, "pushNotifications": true }
• "defaultInputModes": ["text/plain", "application/pdf"], "defaultOutputModes": ["application/json"]
• "securitySchemes": { "oauth": { "oauth2SecurityScheme": { "flows": { … } } } }
• "skills": [{ "id": "klassifiziere_rechnung", "name": "Rechnung klassifizieren", "description": "Liefert Kategorie und Konfidenz (0 bis 1)", "tags": ["rechnung"] }]

El proceso:

1. El agente de CRM obtiene la Card: GET https://agents.example.com/.well-known/agent-card.json
2. Comprueba: la habilidad encaja y se admiten el formato de entrada y OAuth 2.0.
3. Abre una tarea mediante POST https://agents.example.com/a2a y la tarea empieza en el estado TASK_STATE_SUBMITTED.
4. La tarea pasa por TASK_STATE_WORKING y termina en TASK_STATE_COMPLETED. Como Artifact se devuelve: { "kategorie": "Wareneingang", "konfidenz": 0.94 }

El agente de CRM no necesitó saber nada sobre el modelo interno ni los prompts del agente de facturas. Decidió únicamente a partir de la Card que este agente podía cumplir la tarea y, a continuación, se la encargó a través del contrato de tareas estandarizado. Precisamente este desacoplamiento hace posibles los flujos de trabajo entre fabricantes con Agentforce, Joule y Copilot Studio. Para Joule, SAP anunció en mayo de 2026 que las funciones bidireccionales de A2A estarán disponibles de forma general en el cuarto trimestre de 2026.

Seguridad y gobernanza

Cada nueva conexión entre agentes es un nuevo límite de confianza y, por tanto, una nueva superficie de ataque. Cuatro riesgos son especialmente relevantes: las violaciones de los límites de confianza, porque cada par A2A es opaco para los demás; la deriva de capacidades, cuando una Card promete más de lo que el agente puede ofrecer realmente de forma segura; las lagunas en la pista de auditoría, en cuanto los mensajes cruzan los límites de un proceso; y la amplificación de la inyección de prompts, porque cada contexto de agente adicional es otra oportunidad para eludir controles. El riesgo de inyección indirecta de prompts (XPIA) crece con cada agente que procesa contenido no fiable.

Consecuencias prácticas para los despliegues: tokens de alcance limitado y corta duración por tarea, mínimo privilegio en las habilidades anunciadas en la Card, Correlation IDs continuos para cada tarea A2A y ninguna extensión propietaria de la semántica de la Card o de las tareas que socave precisamente la portabilidad por la que se elige A2A. En los flujos de trabajo regulados, la reproducibilidad exige registrar las Agent Cards utilizadas en cada ejecución y fijar las versiones de los modelos.

Para agencias y B2B

Para las agencias de marketing y digitales en Europa, publicar Agent Cards es la palanca de producto más importante en 2026. Solo un agente descubrible mediante A2A puede invocarse directamente desde los entornos de Salesforce, SAP Joule o Copilot Studio de tus clientes sin necesidad de una integración propia para cada cliente. Quien se salte las Agent Cards quedará relegado para siempre a una integración manual. Nuestra recomendación: disciplina con las Cards desde el primer día, exigir contratos de salida tipados (por ejemplo, con Pydantic o JSON Schema) y requerir una Card para cada agente convertido en producto antes de su puesta en producción.

Para los responsables de decisiones B2B, la cuestión de compras es decisiva: ¿garantiza tu contrato de Agentforce, Joule o Copilot Studio la interoperabilidad A2A y el cumplimiento del estándar MCP? ¿Y incluye cláusulas sobre la publicación de Agent Cards y cláusulas de salida? Blck Alpaca te ayuda a diseñar agentes conformes con A2A, a modelar correctamente las Agent Cards y a integrarlas en una arquitectura de descubrimiento preparada para la gobernanza.