La mayoría de los sistemas de IA hoy en día son agentes únicos. Un modelo, un bucle de prompts, un conjunto de herramientas. Eso funciona hasta que la tarea es demasiado grande para un solo agente, o hasta que necesitas un agente construido por otro equipo para manejar un paso que tu agente no puede. Entonces te encuentras con un muro: no hay una forma estándar para que dos agentes independientes se encuentren, intercambien trabajo y reporten resultados. Agent2Agent (A2A) es el protocolo creado para eliminar ese muro.
Esta guía explica qué es A2A, el problema que resuelve, cómo funciona internamente y en qué se diferencia de MCP. Si deseas probar un agente A2A después de leer esto, la guía del Depurador A2A de Apidog continúa donde termina esta publicación.
¿Qué es Agent2Agent (A2A)?
Agent2Agent (A2A) es un protocolo abierto para la comunicación entre agentes de IA. Define cómo un agente anuncia sus capacidades, cómo otro agente se conecta a él, cómo ambos intercambian mensajes y archivos, y cómo el estado de la tarea fluye de vuelta al llamador.
La palabra clave es entre. A2A no se trata de dar más herramientas a un agente. Se trata de permitir que agentes separados, a menudo construidos en diferentes marcos por diferentes equipos, trabajen juntos sin que ninguna de las partes conozca los internos de la otra.
Piensa en ello como HTTP para el tráfico de agentes. HTTP permite que un navegador hable con cualquier servidor web sin importar el lenguaje en el que se ejecuta el servidor. A2A permite que un agente de LangGraph hable con un agente de CrewAI sin importar cómo se construyó ese agente. Ambas partes acuerdan el envoltorio; ninguna de las partes revela su implementación.
Google introdujo A2A en 2025 y más tarde lo trasladó a la Linux Foundation como un proyecto de código abierto neutral para proveedores. La especificación está disponible públicamente en el repositorio de GitHub de A2A, y las implementaciones de referencia se publican en el sitio del proyecto A2A.
El problema que resuelve A2A
Antes de A2A, conectar dos agentes significaba escribir código de unión. Cada emparejamiento era personalizado. Si tu agente necesitaba llamar al agente de investigación de un equipo asociado, alguien escribía un cliente a medida, elegía una forma de carga útil, inventaba un esquema de autenticación y mantenía todo manualmente. El siguiente emparejamiento comenzaba de nuevo desde cero.
Ese enfoque se desmorona rápidamente:
- Sin descubrimiento. No había una forma estándar para que un agente preguntara "¿qué puedes hacer?" antes de enviar trabajo.
- Sin modelo de tarea compartido. Un agente devolvía una cadena de texto simple, otro devolvía un blob JSON personalizado, un tercero transmitía tokens. El llamador tenía que manejar cada caso de forma especial.
- Sin autenticación común. Cada integración reinventaba las credenciales y los encabezados.
- Sin interoperabilidad. Un agente construido sobre AutoGen no podía sustituir a uno construido sobre LangGraph, incluso cuando realizaban el mismo trabajo.
A2A soluciona esto de la misma manera que OpenAPI solucionó las integraciones REST: un contrato acordado, para que cualquier agente compatible pueda hablar con cualquier otro agente compatible.
Cómo funciona A2A
A2A tiene cuatro conceptos centrales. Una vez que los conoces, todo el protocolo cabe en tu cabeza.
La Tarjeta de Agente
La Tarjeta de Agente es un documento JSON que un agente publica para describirse a sí mismo. Es el punto de entrada para el descubrimiento. Enumera el nombre del agente, la descripción, las capacidades, las habilidades declaradas, los tipos de entrada y salida compatibles, los requisitos de autenticación y la versión del protocolo.
Por convención, la tarjeta se encuentra en una ruta conocida, a menudo https://your-agent.example.com/.well-known/agent.json. Un agente llamador obtiene esa URL primero, lee la tarjeta y aprende exactamente qué puede solicitar antes de enviar un solo mensaje.
Tareas
Una tarea es la unidad de trabajo en A2A. Cuando un agente le pide a otro que haga algo, esa solicitud se convierte en una tarea con su propia ID y un estado que pasa por estados como submitted (enviada), working (en curso), input-required (entrada requerida) y completed (completada). El llamador puede sondear la tarea o suscribirse a las actualizaciones. Este modelo de tarea compartido es lo que hace que los agentes A2A sean intercambiables; el llamador maneja el estado de la misma manera, independientemente de quién esté realizando el trabajo.
Mensajes y artefactos
Un mensaje lleva el contenido real entre agentes. Un mensaje está compuesto por partes: una parte de texto, una parte de archivo, datos estructurados o una mezcla. El agente receptor lee las partes que su habilidad necesita.
Cuando el agente termina, devuelve artefactos; las salidas estructuradas de la tarea. Un artefacto podría ser un documento generado, una tabla de datos, un resumen o una referencia de archivo. Los artefactos también se construyen a partir de partes, por lo que el formato se mantiene consistente en ambas direcciones.
Streaming y actualizaciones
Las tareas de larga duración no tienen por qué bloquearse. A2A admite eventos enviados por el servidor, por lo que un agente puede transmitir resultados parciales y cambios de estado a medida que avanza el trabajo. Un agente de investigación puede emitir "encontradas 3 fuentes" antes de emitir el informe final. El llamador muestra el progreso en lugar de quedarse mirando un spinner.
En conjunto, un intercambio A2A típico se ve así:
- El Agente A recupera la Tarjeta de Agente del Agente B y lee sus habilidades.
- El Agente A envía un mensaje que crea una tarea.
- El Agente B trabaja en la tarea y transmite actualizaciones de estado.
- El Agente B devuelve artefactos cuando la tarea alcanza el estado
completed(completada). - El Agente A consume los artefactos y continúa.
Toda la conversación es JSON sobre HTTP. Nada exótico.
A2A vs MCP
A2A y el Protocolo de Contexto de Modelo (MCP) se confunden constantemente porque ambos involucran agentes y ambos son protocolos abiertos. Resuelven problemas diferentes.
| A2A | MCP | |
|---|---|---|
| Conecta | Agente con agente | Agente con herramientas y datos |
| Pregunta que responde | "¿Puede otro agente hacer este paso por mí?" | "¿A qué herramientas y recursos puede acceder este agente?" |
| Uso típico | Flujos de trabajo multiagente entre equipos | Un solo agente llamando a una base de datos, sistema de archivos o API |
| Unidad de intercambio | Tareas, mensajes, artefactos | Llamadas a herramientas, recursos, prompts |
MCP es cómo un agente accede a sistemas externos. A2A es cómo un agente se comunica con otro agente. Un sistema de producción real a menudo usa ambos: un agente usa MCP para consultar una base de datos y A2A para entregar una subtarea a un agente especialista. El desglose de servidor MCP vs A2A cubre la decisión en profundidad, y el depurador cliente MCP de Apidog muestra el lado de MCP en la práctica.
Colaboración multiagente en la práctica
A2A es una forma de hacer que los agentes colaboren, pero no la única. Algunos sistemas utilizan la orquestación directa en su lugar, donde un agente planifica el trabajo y lo delega explícitamente a otro.
Un ejemplo claro de código abierto es Codex-Claude-Collab, una habilidad que coordina un flujo de trabajo en tiempo real entre OpenAI Codex y Claude Code. Codex planifica la tarea, delega la implementación a Claude Code, luego revisa la diferencia y verifica el resultado antes de responder al usuario. Es un bucle ajustado de planificador y constructor entre dos agentes de codificación diferentes.
Ese patrón es una orquestación cableada; una parte sabe exactamente quién es la otra. A2A generaliza la misma idea: en lugar de que Codex sepa que está llamando específicamente a Claude Code, un llamador A2A lee una Tarjeta de Agente y trabaja con cualquier agente compatible que responda. La orquestación es excelente cuando controlas ambos extremos. A2A es lo que quieres cuando los agentes son independientes, pertenecen a diferentes equipos o necesitan ser intercambiables. La mayoría de los sistemas maduros terminan con ambos: orquestación dentro de un equipo, A2A a través de los límites del equipo.
Cómo probar un agente A2A
Una vez que construyes o consumes un agente A2A, necesitas ver el tráfico. Los registros de la consola ocultan los campos estructurados, y los scripts de prueba a medida se deterioran. Aquí es donde un depurador A2A visual se gana su lugar.
Apidog incluye un Depurador A2A en su cliente estándar. Pegas una URL de Tarjeta de Agente, haces clic en Conectar, y Apidog lee la tarjeta y muestra el nombre, las capacidades y las habilidades del agente. Envías un mensaje de prueba, adjuntas archivos, añades metadatos y lees la respuesta en tres vistas: una vista previa legible, el contenido sin procesar y la carga útil completa de JSON-RPC. Maneja encabezados de Bearer Token, Basic Auth y claves API sin necesidad de curl.
El punto es el aislamiento. Cuando un agente se comporta mal, quieres saber si el transporte es incorrecto o si la lógica del agente es incorrecta. Ver la carga útil exacta en el cable responde a eso en segundos. La guía del Depurador A2A de Apidog recorre un ciclo completo de conectar-enviar-leer, y el principio más amplio de probar agentes de IA que llaman a tus APIs aplica la misma disciplina de confirmar primero el cable.
Empezando con A2A
Si deseas construir o conectar un agente A2A, un camino corto es:
- Lee la especificación A2A para conocer los campos requeridos de la Tarjeta de Agente y el ciclo de vida de las tareas.
- Ejecuta uno de los agentes de ejemplo de referencia localmente. La mayoría se inician en pocos minutos y exponen una Tarjeta de Agente funcional.
- Apunte un depurador A2A a la URL de la Tarjeta de Agente del ejemplo y envíe un mensaje "hola". Confirme que puede ver el viaje de ida y vuelta.
- Construya su propio agente, exponga una Tarjeta de Agente válida y pruébelo de la misma manera antes de integrarlo en un flujo de trabajo.
- Agregue autenticación, archivos adjuntos y streaming una vez que la ruta de texto plano funcione.
A2A es joven, pero está respaldado por una fundación neutral de proveedores y una lista creciente de integraciones de frameworks. Tratar el tráfico de agentes como un protocolo de primera clase ahora le ahorrará la reescritura de código de unión personalizado más adelante. La publicación Los agentes de IA son los nuevos consumidores de API expone el argumento más amplio, y diseñar APIs para agentes de IA cubre lo que cambia cuando su consumidor es un agente en lugar de un humano.
Preguntas frecuentes
¿A2A es creado por Google?
Google introdujo A2A en 2025, luego lo donó a la Linux Foundation como un proyecto abierto neutral de proveedores. La especificación se desarrolla de forma abierta y cualquier proveedor puede implementarla.
¿Necesito A2A si solo tengo un agente?
No. A2A resuelve la comunicación de agente a agente. Un solo agente con un conjunto de herramientas necesita MCP, no A2A. Recurres a A2A una vez que un segundo agente entra en escena.
¿Qué frameworks soportan A2A?
A2A es agnóstico del framework por diseño. Cualquier agente que publique una Tarjeta de Agente válida y hable el protocolo puede participar, por lo que LangGraph, CrewAI, AutoGen y agentes personalizados funcionan. El framework interno del agente es invisible para los llamadores.
¿Es A2A lo mismo que MCP?
No. MCP conecta un agente a herramientas y fuentes de datos. A2A conecta agentes entre sí. Son complementarios, y muchos sistemas ejecutan ambos a la vez.
¿Cómo depuro una integración A2A?
Utiliza un depurador A2A visual como el Depurador A2A de Apidog. Pega la URL de la Tarjeta de Agente, envía mensajes de prueba e inspecciona la solicitud y respuesta en bruto para poder distinguir los errores de transporte de los errores de lógica del agente.
¿A2A soporta tareas de larga duración?
Sí. El modelo de tareas tiene estados de estado explícitos, y el protocolo admite eventos enviados por el servidor para transmitir resultados parciales y actualizaciones de progreso, de modo que las tareas largas no bloqueen al llamador.