A2A
Por qué importa
En profundidad
El problema que aborda A2A es fácil de formular: a medida que las organizaciones despliegan más agentes, estos necesitan pasarse trabajo y actualmente cada par requiere una integración a medida. A2A define un patrón común para esa transferencia. Un agente actúa como cliente y formula una tarea; otro actúa como agente remoto y la ejecuta. Ambos intercambian contexto, instrucciones y resultados sobre infraestructura web ordinaria — HTTP con JSON-RPC 2.0 como formato de transferencia y Server-Sent Events para actualizaciones en vivo —, de modo que adoptarlo no requiere una nueva capa de transporte ni un runtime compartido. De manera crucial, los agentes permanecen opacos entre sí: se coordinan mediante capacidades declaradas y el estado de la tarea, no compartiendo memoria, pesos o razonamiento interno.
Tarjetas de agente y descubrimiento de capacidades
El descubrimiento en A2A funciona mediante la tarjeta de agente: un pequeño documento JSON, normalmente publicado en una ruta conocida como /.well-known/agent.json en el dominio del agente, que describe quién opera el agente, qué habilidades ofrece, qué formatos de entrada y salida acepta y qué autenticación exige. Un agente cliente obtiene la tarjeta antes de enviar trabajo real, para poder decidir — programáticamente o mediante un planificador LLM — si ese agente remoto es siquiera candidato para el trabajo. En la práctica, las tarjetas aparecen de dos formas: directamente, cuando un flujo de trabajo ya conoce la URL de un agente asociado, o mediante registros curados que una empresa mantiene para cada Agente aprobado. El modelo de tarjetas es lo que convierte A2A de una convención de mensajería en una verdadera capa de descubrimiento, y refleja cómo un Agente Autónomo razona sobre cualquier otro recurso: lee una descripción, la compara con el objetivo y luego actúa.
Tareas, mensajes y artefactos
La unidad de trabajo en A2A es la tarea y tiene un ciclo de vida explícito: submitted, working, input-required, completed, failed o canceled. Dentro de una tarea, los dos agentes intercambian mensajes, y cada mensaje se compone de partes en vez de texto en bruto — una parte de texto para lenguaje natural, una parte de archivo para contenido binario o una parte de datos para cargas JSON estructuradas como formularios y cotizaciones de precios. Este modelo de partes importa porque los flujos de trabajo empresariales reales se ejecutan sobre datos estructurados, y A2A permite que los agentes negocien mediante Salida estructurada en vez de obligar a que todo pase por prosa de chat. Cuando una tarea termina, sus resultados se entregan como artefactos: salidas con nombre, construidas también a partir de partes, que el agente cliente puede consumir o pasar al siguiente paso de un Flujo de trabajo agéntico mayor.
Los estados del ciclo de vida demuestran su utilidad en trabajos de larga duración. Una tarea que lleva minutos u horas puede transmitir eventos de progreso al cliente mediante Server-Sent Events, o entregar actualizaciones con notificaciones push a un webhook cuando el cliente no puede mantener abierta una conexión, haciendo viable el Streaming incluso para consumidores desconectados. input-required es el estado sutil: permite que el agente remoto haga una pausa y formule una pregunta aclaratoria durante la tarea, que es la forma en que se produce una negociación de varios turnos entre agentes sin romper la abstracción de tarea.
A2A no sustituye a MCP
La idea equivocada más común sobre A2A es que compite con MCP. No es así — los dos protocolos operan en capas distintas. MCP estandariza cómo un único agente se conecta a herramientas y fuentes de datos: llamar una función, leer un recurso, ejecutar una consulta. A2A estandariza cómo se coordinan dos agentes independientes, con uno que delega una tarea a un par que puede pertenecer a un equipo, proveedor o dominio de confianza completamente distinto. La fórmula abreviada que escucharás es que MCP es la interfaz vertical (agente a herramienta), mientras A2A es la horizontal (agente a agente).
Una configuración de producción realista utiliza ambos en la misma cadena de llamadas. Un agente orquestador podría usar MCP para el Uso de herramientas — acceder a un CRM, un índice de búsqueda o un repositorio de código — y luego A2A para subcontratar un agente especialista, como uno de revisión de contratos operado por el departamento jurídico, que a su vez depende internamente de MCP y la Llamada de Funciones. Ninguno de los dos protocolos dicta lo que sucede dentro del otro agente, y esa opacidad es una decisión deliberada de diseño: permite que las organizaciones colaboren sin exponer prompts, memoria o razonamiento propietario.
Gobernanza, ecosistema y preguntas abiertas
Google publicó A2A como especificación abierta con SDK de referencia en 2025, respaldada en su lanzamiento por más de 50 socios tecnológicos que abarcaban proveedores de software empresarial, frameworks como LangChain y consultoras. Después donó el proyecto a la Linux Foundation para que ningún proveedor controlara su evolución. Ese movimiento de gobernanza importa para la adopción: los protocolos solo se convierten en infraestructura cuando los competidores pueden implementarlos sin temer que las reglas cambien bajo sus pies. La especificación, los SDK y los agentes de muestra son públicos, y el diseño reutiliza deliberadamente estándares web existentes en vez de inventar otros nuevos.
Los problemas difíciles por delante tienen menos que ver con los formatos de mensajes y más con la confianza. Una tarjeta de agente declara qué autenticación requiere un agente, pero nada en el protocolo te dice si debes creerla, lo que convierte el tráfico A2A entre organizaciones tanto en un problema de Seguridad de la IA como de integración. La Prompt Injection es un riesgo concreto: un agente remoto malicioso o comprometido puede insertar instrucciones hostiles en resultados de tareas que el modelo del agente cliente leerá obedientemente. Los equipos que hoy construyen Sistemas Multi-Agente sobre A2A suelen contrarrestarlo restringiendo el descubrimiento a registros curados, validando los artefactos antes de que lleguen a un modelo y tratando por defecto a cada agente remoto como no confiable.