La mayoría de los sistemas de IA actuales siguen el mismo patrón: un agente, un bucle de prompts y un conjunto de herramientas. Eso funciona hasta que la tarea requiere otro agente especializado, mantenido por otro equipo o implementado con otro framework. El problema aparece cuando ambos agentes necesitan descubrirse, intercambiar trabajo y devolver resultados sin una integración personalizada. Agent2Agent (A2A) define ese contrato común.
En esta guía verás qué es A2A, qué problema resuelve, cómo funciona por dentro, cómo se diferencia de MCP y cómo empezar a probar un agente A2A. Si quieres depurar uno después, continúa con la guía del Depurador A2A de Apidog.
¿Qué es Agent2Agent (A2A)?
Agent2Agent (A2A) es un protocolo abierto para comunicación entre agentes de IA. Define cómo un agente:
- publica sus capacidades;
- permite que otro agente lo descubra;
- recibe mensajes, archivos y datos estructurados;
- expone el estado de una tarea;
- devuelve resultados como artefactos.
La palabra clave es entre. A2A no intenta darle más herramientas a un agente. Su objetivo es que agentes separados, posiblemente construidos con frameworks distintos y por equipos distintos, colaboren sin exponer su implementación interna.
Piensa en A2A como una capa de interoperabilidad para agentes. Igual que HTTP permite que un navegador hable con cualquier servidor web, A2A permite que un agente construido con LangGraph hable con otro construido con CrewAI, AutoGen o código propio. Ambos respetan el mismo contrato de comunicación.
Google introdujo A2A en 2025 y luego lo trasladó a la Linux Foundation como proyecto open source neutral para proveedores. La especificación está disponible 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 implicaba escribir código de integración específico para cada caso.
Por ejemplo, si tu agente necesitaba llamar al agente de investigación de otro equipo, normalmente tenías que decidir manualmente:
- qué endpoint llamar;
- qué payload enviar;
- cómo autenticarte;
- cómo interpretar la respuesta;
- cómo manejar errores;
- cómo consultar el progreso;
- cómo recibir archivos o salidas estructuradas.
Ese enfoque no escala porque cada pareja de agentes necesita una integración nueva.
Los problemas típicos son:
- Sin descubrimiento estándar. Un agente no tiene una forma común de preguntar “¿qué puedes hacer?”.
- Sin modelo de tarea compartido. Un agente devuelve texto plano, otro JSON personalizado y otro transmite tokens.
- Sin autenticación consistente. Cada integración define sus propios encabezados o credenciales.
- Sin interoperabilidad real. No puedes sustituir fácilmente un agente de AutoGen por uno de LangGraph aunque hagan tareas similares.
A2A resuelve esto de forma parecida a como OpenAPI ayudó con REST: define un contrato común para que cualquier agente compatible pueda comunicarse con otro agente compatible.
Cómo funciona A2A
A2A se basa en cuatro conceptos principales:
- Tarjeta de Agente.
- Tareas.
- Mensajes y artefactos.
- Streaming y actualizaciones.
1. Tarjeta de Agente
La Tarjeta de Agente es un documento JSON que describe qué hace un agente y cómo llamarlo. Es el punto de entrada para el descubrimiento.
Normalmente incluye:
- nombre del agente;
- descripción;
- capacidades;
- habilidades declaradas;
- tipos de entrada soportados;
- tipos de salida soportados;
- requisitos de autenticación;
- versión del protocolo.
Por convención, suele estar disponible en una ruta conocida como:
https://your-agent.example.com/.well-known/agent.json
Un agente llamador primero obtiene esa tarjeta, lee sus capacidades y decide si puede delegarle una tarea.
Un ejemplo simplificado podría verse así:
{
"name": "research-agent",
"description": "Agente especializado en investigación y resumen de fuentes",
"protocolVersion": "0.2.0",
"capabilities": {
"streaming": true
},
"skills": [
{
"id": "web-research",
"name": "Investigación web",
"description": "Busca información y devuelve un resumen estructurado"
}
]
}
2. Tareas
Una tarea es la unidad de trabajo en A2A.
Cuando un agente le pide a otro que haga algo, esa solicitud se representa como una tarea con:
- un ID propio;
- un estado;
- mensajes de entrada;
- posibles actualizaciones;
- artefactos de salida.
Los estados pueden incluir valores como:
submitted
working
input-required
completed
Esto permite que el agente llamador maneje cualquier agente A2A de forma uniforme. No necesita saber si el trabajo lo hace un agente de LangGraph, CrewAI, AutoGen o una implementación propia.
Un flujo típico sería:
submitted → working → completed
O, si el agente necesita más información:
submitted → working → input-required → working → completed
3. Mensajes y artefactos
Un mensaje transporta el contenido entre agentes.
Puede contener varias partes:
- texto;
- archivos;
- datos estructurados;
- combinaciones de los anteriores.
Por ejemplo, un agente podría enviar:
{
"role": "user",
"parts": [
{
"kind": "text",
"text": "Resume este documento y extrae los riesgos principales."
}
]
}
Cuando el agente termina, devuelve artefactos. Un artefacto representa una salida de la tarea, por ejemplo:
- un resumen;
- un informe;
- una tabla;
- un archivo generado;
- una referencia a un recurso;
- datos estructurados.
El beneficio práctico es que la entrada y la salida siguen un modelo común. El agente llamador no necesita adaptadores personalizados para cada implementación.
4. Streaming y actualizaciones
A2A también soporta tareas de larga duración mediante eventos enviados por el servidor.
Esto permite que un agente emita progreso mientras trabaja. Por ejemplo:
submitted
working: buscando fuentes
working: encontradas 3 fuentes
working: generando resumen
completed
En una interfaz, esto evita que el usuario vea solo un spinner. En un sistema backend, permite tomar decisiones según el progreso o cancelar/reintentar si algo se bloquea.
Flujo básico de una llamada A2A
Un intercambio A2A típico se implementa así:
- El Agente A obtiene la Tarjeta de Agente del Agente B.
- El Agente A lee sus habilidades y requisitos de autenticación.
- El Agente A envía un mensaje para crear una tarea.
- El Agente B procesa la tarea.
- El Agente B envía actualizaciones de estado si corresponde.
- El Agente B devuelve artefactos cuando la tarea termina.
- El Agente A consume esos artefactos y continúa su flujo.
En la práctica, todo viaja como JSON sobre HTTP. No necesitas una infraestructura exótica para empezar.
A2A vs MCP
A2A y Model Context Protocol (MCP) suelen confundirse porque ambos aparecen en arquitecturas con agentes. Pero resuelven problemas distintos.
| 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 multiagente entre equipos o sistemas | Un agente llamando a una base de datos, filesystem o API |
| Unidad de intercambio | Tareas, mensajes y artefactos | Llamadas a herramientas, recursos y prompts |
Usa MCP cuando un agente necesita acceder a herramientas o datos externos.
Usa A2A cuando un agente necesita delegar trabajo a otro agente.
En producción, ambos pueden convivir. Por ejemplo:
- Un agente coordinador recibe una solicitud.
- Usa MCP para consultar una base de datos.
- Usa A2A para delegar el análisis a un agente especializado.
- Recibe artefactos del agente especializado.
- Genera la respuesta final.
Para profundizar en la comparación, consulta el desglose de servidor MCP vs A2A. Para ver el lado de MCP en la práctica, revisa el depurador cliente MCP de Apidog.
Colaboración multiagente en la práctica
A2A no es la única forma de hacer colaboración multiagente. Otra opción es la orquestación directa, donde una parte conoce explícitamente a la otra y decide cómo delegarle trabajo.
Un ejemplo open source es Codex-Claude-Collab, una habilidad que coordina un flujo entre OpenAI Codex y Claude Code.
El patrón es:
- Codex planifica la tarea.
- Claude Code implementa el cambio.
- Codex revisa el diff.
- Codex verifica el resultado.
- El sistema responde al usuario.
Ese enfoque funciona bien cuando controlas ambos extremos. Pero es una orquestación cableada: una parte sabe exactamente a quién llama.
A2A generaliza esa idea. En lugar de llamar a un agente concreto por nombre, el llamador lee una Tarjeta de Agente y trabaja con cualquier agente compatible.
Usa esta regla práctica:
- Orquestación directa: útil dentro de un mismo equipo o producto.
- A2A: útil cuando los agentes pertenecen a equipos distintos, deben ser sustituibles o se integran como capacidades externas.
En sistemas maduros, es común usar ambos patrones: orquestación interna para flujos controlados y A2A para cruzar límites entre equipos o proveedores.
Cómo probar un agente A2A
Cuando construyes o consumes un agente A2A, necesitas inspeccionar el tráfico real.
Los logs de consola suelen ocultar detalles importantes:
- encabezados incorrectos;
- payloads mal formados;
- estados inesperados;
- errores de autenticación;
- respuestas parciales;
- artefactos incompletos.
Un depurador visual ayuda a separar dos tipos de problemas:
- problemas de transporte: HTTP, autenticación, JSON-RPC, headers, payload;
- problemas de lógica: el agente recibió bien la solicitud, pero decidió o respondió mal.
Apidog incluye un Depurador A2A en su cliente estándar.
El flujo de prueba es directo:
- Pega la URL de la Tarjeta de Agente.
- Haz clic en conectar.
- Revisa el nombre, capacidades y habilidades detectadas.
- Envía un mensaje de prueba.
- Adjunta archivos si el agente los soporta.
- Añade metadatos si tu caso lo requiere.
- Inspecciona la respuesta en vista previa, contenido raw y payload JSON-RPC completo.
También puedes configurar autenticación con:
- Bearer Token;
- Basic Auth;
- API keys.
Esto evita tener que reproducir cada prueba con curl o scripts temporales.
La guía del Depurador A2A de Apidog muestra el ciclo completo de conectar, enviar y leer respuestas. El mismo principio se aplica a probar agentes de IA que llaman a tus APIs: confirma primero el tráfico antes de depurar la lógica.
Cómo empezar con A2A
Si quieres construir o conectar un agente A2A, sigue este camino mínimo:
- Lee la especificación A2A para entender la Tarjeta de Agente, tareas, mensajes y artefactos.
- Ejecuta uno de los agentes de ejemplo de referencia localmente.
- Localiza la URL de su Tarjeta de Agente, por ejemplo:
http://localhost:3000/.well-known/agent.json
- Abre esa URL y confirma que devuelve JSON válido.
- Usa un depurador A2A para enviar un mensaje simple como:
hola
- Verifica que recibes una tarea y una respuesta.
- Construye tu propio agente y expón una Tarjeta de Agente válida.
- Prueba primero texto plano.
- Añade autenticación.
- Añade archivos adjuntos.
- Añade streaming cuando el flujo básico funcione.
El orden importa. No empieces con autenticación, archivos y streaming a la vez. Primero confirma el camino mínimo de ida y vuelta.
Checklist para implementar un agente A2A
Antes de integrar tu agente en un flujo real, valida lo siguiente:
- [ ] La Tarjeta de Agente está disponible en una URL estable.
- [ ] La tarjeta declara correctamente nombre, descripción y versión del protocolo.
- [ ] Las habilidades están descritas con suficiente claridad para que otro agente las seleccione.
- [ ] Los tipos de entrada y salida son explícitos.
- [ ] El agente crea tareas con IDs únicos.
- [ ] Los estados de tarea se actualizan correctamente.
- [ ] Los errores se devuelven de forma estructurada.
- [ ] Los artefactos finales son consistentes.
- [ ] La autenticación está documentada.
- [ ] El flujo funciona con un cliente externo, no solo con pruebas internas.
- [ ] El tráfico puede inspeccionarse para depuración.
A2A todavía es joven, pero tratar la comunicación entre agentes como un protocolo de primera clase evita acumular integraciones frágiles y código de unión personalizado.
Para el contexto más amplio, lee Los agentes de IA son los nuevos consumidores de API. Si estás diseñando APIs para que las consuman agentes, revisa también diseñar APIs para agentes de IA.
Preguntas frecuentes
¿A2A fue creado por Google?
Sí. Google introdujo A2A en 2025 y luego lo donó a la Linux Foundation como proyecto abierto neutral para proveedores. La especificación se desarrolla de forma abierta y cualquier proveedor puede implementarla.
¿Necesito A2A si solo tengo un agente?
No. A2A resuelve comunicación de agente a agente. Si tienes un solo agente que necesita acceder a herramientas, bases de datos o APIs, probablemente necesitas MCP, no A2A.
¿Qué frameworks soportan A2A?
A2A es agnóstico del framework. Cualquier agente que publique una Tarjeta de Agente válida y hable el protocolo puede participar. El agente puede estar construido con LangGraph, CrewAI, AutoGen o una implementación propia.
¿A2A es lo mismo que MCP?
No. MCP conecta un agente con herramientas y fuentes de datos. A2A conecta agentes entre sí. Son protocolos complementarios.
¿Cómo depuro una integración A2A?
Usa 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 distinguir errores de transporte de errores de lógica.
¿A2A soporta tareas de larga duración?
Sí. El modelo de tareas incluye estados explícitos y el protocolo admite eventos enviados por el servidor para transmitir progreso y resultados parciales.
Top comments (0)