¿Qué es el protocolo A2A? Agent Cards y Tasks explicados

El Protocolo A2A, siglas de Agent2Agent Protocol (Protocolo de Agente a Agente), es un estándar abierto para la comunicación entre sistemas de agentes de IA independientes.

Esa frase suena simple, pero implica algo que la mayoría de las demostraciones de agentes de IA omiten por completo. La mayoría de las demostraciones aún asumen un asistente, un tiempo de ejecución, un bucle de herramientas y un propietario: el agente puede buscar, llamar a herramientas, escribir código, consultar APIs, tal vez usar servidores MCP y devolver una respuesta.

A2A está diseñado para un mundo diferente, uno en el que los agentes pueden ser construidos por diferentes equipos, frameworks, proveedores, lenguajes u organizaciones. Asume que un agente puede necesitar descubrir otro agente, entender qué puede hacer, enviarle trabajo, intercambiar mensajes, recibir archivos o salidas estructuradas y rastrear una tarea hasta su finalización, lo que lo convierte no solo en otro formato de llamada de herramientas, sino en un intento genuino de hacer que los agentes de IA sean interoperables como pares.

Los conceptos centrales son:

• Agent Cards (Tarjetas de Agente)
• Agentes y clientes
• Tareas
• Mensajes
• Partes
• Artefactos
• Estados de la tarea
• Transmisión en tiempo real (streaming) y actualizaciones asíncronas

Este artículo explica esos conceptos en términos técnicos claros, con suficiente detalle para entender dónde encaja A2A en los sistemas multiagente reales.

La definición corta

A2A es un protocolo para la comunicación entre agentes.

Permite que un agente o cliente se comunique con otro agente a través de un modelo común. El agente receptor puede describir sus capacidades, aceptar trabajo, gestionar el ciclo de vida de ese trabajo, solicitar más información, transmitir el progreso y devolver resultados concretos.

El objetivo no es estandarizar cómo piensa un agente internamente, sino estandarizar cómo se comunican los agentes en sus límites.

Un agente A2A podría utilizar internamente:

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• código personalizado
• servidores MCP
• APIs privadas
• bases de datos vectoriales
• motores de flujo de trabajo

El llamante no necesita saber nada de eso. Lo que el llamante sí necesita saber es:

• ¿Qué puede hacer este agente?
• ¿Cómo me comunico con él?
• ¿Qué entrada acepta?
• ¿Qué salida puede producir?
• ¿Cómo rastreo el trabajo?
• ¿Cómo recibo el resultado?

Esas seis preguntas definen el límite del protocolo que A2A intenta establecer entre agentes que operan de forma independiente.

Por qué existe A2A

Los sistemas de IA están evolucionando desde asistentes únicos hacia redes de agentes especializados.

Una empresa podría tener:

• Un agente de soporte
• Un agente de facturación
• Un agente de revisión legal
• Un agente de DevOps
• Un agente de análisis de datos
• Un agente de investigación
• Un agente de documentación
• Un agente de revisión de código

Cada agente puede tener sus propias herramientas, permisos, conocimiento del dominio, prompts, memoria, sistema de recuperación y reglas de auditoría.

Sin un protocolo compartido, cada integración se vuelve personalizada: el agente de soporte necesita un cableado especial para el agente de facturación, el agente de facturación necesita uno propio para el agente legal, y el agente de investigación necesita otro para el agente de documentación. Esta sobrecarga combinatoria no escala bien a medida que crece la red de agentes.

A2A ofrece a estos agentes una forma común de interactuar, reduciendo el problema de integración N×M a un único contrato compartido. La promesa no es la autonomía mágica; la promesa es la interoperabilidad.

A2A no es MCP

A2A a menudo se compara con MCP, pero resuelven problemas diferentes.

MCP, o Model Context Protocol (Protocolo de Contexto de Modelo), se centra principalmente en conectar una aplicación o agente de IA con herramientas, recursos y prompts, mientras que A2A se centra principalmente en conectar agentes con otros agentes.

Un modelo mental útil es:

MCP: agente a herramienta
A2A: agente a agente

Por ejemplo, un agente puede usar MCP para acceder a:

• GitHub
• un sistema de archivos
• una base de datos
• Slack
• un sistema de búsqueda de documentación
• una API en la nube

Guías prácticas para construir esos servidores MCP están disponibles para Go y Python.

El mismo agente puede usar A2A para delegar trabajo a:

• un agente de revisión de seguridad
• un agente de investigación
• un agente de planificación
• un agente de cumplimiento
• un agente de codificación

Los dos protocolos pueden y a menudo trabajan juntos. Una arquitectura limpia suele ser:

A2A fuera del límite del agente.
MCP dentro del límite del agente.

Esto significa que otros agentes se comunican con tu agente usando A2A, mientras que tu agente utiliza internamente MCP para acceder a herramientas, una separación limpia de responsabilidades que mantiene estable la interfaz externa independientemente de los cambios internos. Para una comparación detallada de cómo los dos protocolos dividen la responsabilidad arquitectónica y cuándo realmente necesitas ambos, consulta A2A vs MCP: ¿Realmente los agentes de IA necesitan ambos protocolos?

Roles centrales en A2A

A2A utiliza un modelo de roles simple construido alrededor de dos partes: un agente que expone capacidades y un cliente que desea utilizarlas.

El cliente podría ser:

• otro agente
• un orquestador
• una aplicación asistente
• un sistema de flujo de trabajo
• una puerta de enlace (gateway)
• un entorno de prueba
• una aplicación para humanos

El agente podría ser:

• un servicio de IA especializado
• un asistente de dominio
• un agente propietario de un flujo de trabajo
• un agente de proveedor remoto
• un agente empresarial interno

Lo importante es que el agente no es solo una función. Posee alguna capacidad y la expone a través de una interfaz de agente.

Agent Cards (Tarjetas de Agente)

La Agent Card es uno de los conceptos más importantes en A2A.

Una Agent Card describe un agente; es el documento de descubrimiento que le dice a los clientes qué es el agente, qué puede hacer, cómo comunicarse con él y qué restricciones se aplican.

Piensa en una Agent Card como una mezcla de:

• metadatos del servicio
• declaración de capacidades
• documento de descubrimiento de API
• perfil del agente
• superficie de contrato

Una Agent Card típica puede describir cosas como:

• nombre del agente
• descripción
• punto final del servicio
• características del protocolo soportadas
• modos de entrada y salida soportados
• habilidades disponibles
• requisitos de autenticación
• información del proveedor
• información de versión
• enlaces de documentación
• metadatos opcionales

La Agent Card es importante porque los agentes no deberían necesitar conocimiento codificado de cada otro agente.

Un cliente puede inspeccionar la tarjeta y decidir:

• ¿Es este el agente adecuado para la tarea?
• ¿Soporta el tipo de contenido que necesito?
• ¿Soporta transmisión en tiempo real (streaming)?
• ¿Requiere autenticación?
• ¿Qué habilidades anuncia?
• ¿Puede devolver el tipo de artefacto que necesito?

En sistemas prácticos, las Agent Cards se convierten en la base para registros de agentes, portales de desarrolladores y catálogos internos de agentes: el equivalente legible por máquina de un directorio de servicios donde los clientes pueden buscar qué está disponible antes de comprometerse con una integración.

Las Agent Cards son límites de capacidad

Una Agent Card no debería tratarse como texto de marketing; es un límite de capacidad en el que otros sistemas confiarán en tiempo de ejecución.

Si tu tarjeta de agente dice que tu agente puede realizar análisis financieros, los clientes pueden comenzar a delegar trabajo de análisis financiero en él. Si dice que el agente acepta archivos, los clientes pueden enviar archivos. Si dice que el agente soporta transmisión en tiempo real, los clientes pueden esperar eventos de progreso.

Las Agent Cards deficientes crean sistemas deficientes porque las decisiones de enrutamiento y las suposiciones de capacidad se propagan en cascada por toda la red de agentes. Una Agent Card útil debería ser:

• específica
• precisa
• estable
• versionada
• consciente de la seguridad
• honesta sobre sus limitaciones

Una habilidad vaga como “realiza tareas comerciales” no es útil.

Una habilidad mejor sería:

Analizar datos de facturas de SaaS y producir un resumen mensual de gastos.

Aún mejor, incluir modos de entrada y salida esperados.

Entrada: Registros de facturas en CSV o JSON.
Salida: Resumen en Markdown y totales en JSON estructurado.

Cuanto más precisa sea la Agent Card, más fácil será que otros agentes enruten las tareas correctamente.

Descubrimiento de agentes

El descubrimiento de agentes es el proceso de encontrar una Agent Card.

En despliegues simples, el descubrimiento puede ser estático. Un cliente ya conoce la URL de un agente específico.

En despliegues más grandes, el descubrimiento puede implicar:

• un registro
• un portal de desarrolladores
• un catálogo interno
• descubrimiento basado en DNS
• gestión de configuración
• enrutamiento específico del entorno
• puertas de enlace (gateways) conscientes del inquilino

La decisión de diseño importante es si el descubrimiento es público, privado o con permisos.

No todos los agentes deberían ser descubribles por todos: un agente de nómina interno no debería exponer la misma Agent Card a cada llamante, y un agente de socio podría ver solo habilidades seguras para socios. El descubrimiento de agentes no es solo una función de conveniencia; es parte de tu modelo de seguridad y gobernanza, y el alcance de la visibilidad es una decisión de diseño de primera clase.

Tareas

Una Tarea representa el trabajo realizado por un agente.

Aquí es donde A2A se vuelve más interesante que las APIs simples de solicitud y respuesta.

Algunas interacciones de agentes son rápidas. Un cliente envía un mensaje y el agente devuelve una respuesta directa.

Pero muchos flujos de trabajo reales de agentes no son instantáneos.

Una tarea podría implicar:

• buscar en múltiples fuentes
• pedir aclaraciones
• llamar a herramientas
• delegar trabajo
• esperar aprobación
• generar un informe
• producir archivos
• transmitir progreso
• manejar reintentos
• devolver múltiples artefactos

A2A modela este tipo de trabajo como una Tarea, otorgándole al trabajo una identidad y un ciclo de vida, lo cual es importante porque el trabajo de agentes de larga ejecución necesita ser rastreado, inspeccionado y potencialmente cancelado o reintentado.

Ciclo de vida de la tarea

Una tarea puede pasar por diferentes estados.

El modelo de estado exacto depende de la versión del protocolo y la implementación, pero la idea básica es sencilla:

• enviada
• en progreso
• se requiere entrada
• completada
• fallida
• cancelada
• rechazada

El punto importante es que una tarea no es solo una carga útil de respuesta; es una unidad de trabajo en curso con su propio estado que un cliente puede consultar en cualquier momento. Un cliente puede usar el estado de la tarea para entender qué está sucediendo:

• ¿Ha aceptado el agente la tarea?
• ¿Sigue trabajando?
• ¿Necesita más entrada?
• ¿Terminó con éxito?
• ¿Falló?
• ¿Fue cancelada?
• ¿Hay artefactos disponibles?

Esto es especialmente útil para flujos de trabajo que toman segundos, minutos o más.

Por ejemplo, un agente de investigación puede devolver una tarea de inmediato, luego continuar trabajando en segundo plano mientras transmite eventos de progreso o hace el resultado disponible más tarde.

Mensaje sin estado o tarea con estado

A2A soporta tanto interacciones simples como complejas.

Para una interacción simple, un agente puede devolver un Mensaje directo; para una interacción compleja, puede devolver una Tarea. Esta distinción es importante porque no todo necesita seguimiento de tareas, y sobreingenierizar interacciones cortas en flujos de trabajo completos de tareas añade sobrecarga innecesaria.

Si un cliente pregunta:

Resume este solo párrafo.

Una respuesta directa puede ser suficiente.

Si un cliente pregunta:

Investiga las cinco principales bases de datos vectoriales de código abierto, compáralas y produce una recomendación de migración.

Una tarea es más apropiada.

La regla práctica es sencilla: usa un Mensaje directo para interacciones simples e inmediatas, y usa una Tarea para trabajo de larga ejecución, con estado, auditable o que produzca artefactos.

Mensajes

Los mensajes son las unidades de comunicación intercambiadas entre el cliente y el agente.

Un mensaje puede contener una o más partes.

Un mensaje puede representar:

• una solicitud de usuario
• una respuesta del agente
• una pregunta de aclaración
• entrada adicional
• comunicación relacionada con la tarea
• contexto de progreso
• instrucciones estructuradas

Los mensajes no son solo cadenas de texto; la comunicación de agentes a menudo necesita transportar mucho más que texto plano, y la estructura del mensaje está diseñada para acomodarlo.

Un mensaje podría incluir:

• texto
• archivos
• JSON estructurado
• imágenes
• referencias
• metadatos

El mensaje es el sobre; las partes son el contenido tipificado real dentro de él.

Partes

Una Parte es un fragmento de contenido dentro de un mensaje o artefacto.

Así es como A2A soporta comunicación multimodal y estructurada.

Una parte puede contener diferentes tipos de contenido, como:

• texto
• datos de archivo
• datos estructurados
• contenido binario por referencia
• datos similares a JSON

Una parte también puede incluir metadatos como:

• tipo de medio (media type)
• nombre de archivo
• contexto adicional

El tipo de medio es importante porque le dice al agente receptor cómo interpretar el contenido.

Por ejemplo:

text/plain
application/json
text/markdown
image/png
application/pdf
text/csv

Esta es una de las partes infravaloradas de A2A. La comunicación de agentes no debería colapsar todo en texto plano; si un agente aguas abajo necesita una hoja de cálculo, una imagen, una carga útil JSON, un archivo de registro o un PDF, el protocolo debería preservar ese contenido como contenido en lugar de malformarlo en un párrafo. Los buenos sistemas de agentes evitan estos cuellos de botella de texto innecesarios permitiendo que cada parte transporte su tipo de medio natural hasta el consumidor.

Artefactos

Los artefactos son salidas concretas producidas por un agente durante el procesamiento de la tarea.

Esto es diferente de un mensaje general: un mensaje es comunicación entre agentes, mientras que un artefacto es un entregable concreto que la tarea ha producido.

Los ejemplos de artefactos incluyen:

• un informe en Markdown
• un resultado de análisis en JSON
• una exportación CSV
• una imagen generada
• un documento PDF
• un parche de código
• un archivo de resultados de prueba
• un plan de despliegue
• un diagrama
• un extracto de datos

Esta distinción es útil en la práctica. Cuando un agente de investigación dice “He encontrado la respuesta”, eso es un mensaje. Cuando devuelve market-analysis.md, sources.json y risk-summary.csv, esos son artefactos: salidas concretas que hacen que el trabajo de la tarea sea inspeccionable, reutilizable y componible. El artefacto de un agente se convierte en la entrada de otro agente sin pérdida de estructura.

Mensajes vs Artefactos

Una forma simple de pensarlo:

Los mensajes son conversación.
Los artefactos son salida.

Los mensajes ayudan a los agentes a coordinarse; los artefactos son lo que la tarea realmente produjo.

Por ejemplo, en un flujo de trabajo de desarrollo de software:

• El cliente envía un mensaje pidiendo una corrección de error.
• El agente de codificación envía mensajes con preguntas de aclaración.
• El agente de codificación trabaja en la tarea.
• El agente devuelve artefactos como un archivo de parche, salida de prueba y explicación.

Esta separación es útil porque evita mezclar la coordinación de tareas con los entregables, haciendo mucho más fácil registrar, auditar y pasar las salidas a consumidores aguas abajo.

Un ejemplo práctico

Imagina que un asistente principal necesita ayuda de un agente de documentación.

El usuario pregunta:

Crea documentación de desarrollador para nuestra nueva API de webhook de facturación.

El asistente principal verifica un registro de agentes y encuentra un agente de documentación.

El agente de documentación tiene una Agent Card que dice que puede:

• escribir documentación de API
• aceptar especificaciones OpenAPI
• aceptar guías de estilo Markdown
• producir documentos en Markdown
• producir ejemplos en Python y JavaScript
• soportar tareas de larga ejecución
• devolver artefactos

El asistente principal envía un mensaje con:

• una instrucción corta
• un archivo OpenAPI
• una guía de estilo
• metadatos sobre el público objetivo

El agente de documentación crea una Tarea.

La tarea entra en un estado de trabajo.

El agente de documentación puede enviar mensajes como:

Estoy extrayendo descripciones de puntos finales.

Luego:

Necesito aclaración sobre los ejemplos de autenticación.

El asistente principal proporciona la entrada faltante.

La tarea continúa.

Finalmente, el agente de documentación devuelve artefactos:

billing-webhooks.md
billing-webhook-examples-python.md
billing-webhook-examples-javascript.md

Ese es el modelo A2A en acción: no solo “llama a esta función”, sino “delega esta tarea a otro agente, comunícate según sea necesario y rastrea el resultado hasta su finalización”.

Por qué las tareas importan para los sistemas reales

Las tareas son lo que hacen que A2A sea adecuado para flujos de trabajo serios.

Una llamada de API HTTP normal a menudo es demasiado delgada para el trabajo de agentes. Las tareas de agentes pueden involucrar incertidumbre, múltiples pasos, resultados intermedios y preguntas de seguimiento.

Una Tarea te da un lugar para adjuntar:

• estado
• historial
• mensajes
• artefactos
• errores
• metadatos
• progreso
• cancelación
• información de auditoría

Esto es útil para:

• flujos de trabajo de investigación
• generación de código
• análisis de datos
• revisión de cumplimiento
• producción de documentos
• investigación de incidentes
• planificación en múltiples pasos
• flujos de trabajo de aprobación humana

Sin un modelo de tareas, los desarrolladores suelen reconstruir esta lógica ellos mismos con IDs de trabajo personalizados, colas, puntos finales de estado y callbacks de webhook; A2A intenta estandarizar la versión específica de agentes de ese patrón para que no tengas que reinventarlo para cada nueva integración de agente.

Trabajo en streaming y asíncrono

A2A soporta la idea de que el trabajo de los agentes puede ser en streaming o asíncrono.

El streaming es útil cuando el cliente quiere actualizaciones en vivo.

Por ejemplo:

• eventos de progreso
• resultados parciales
• estado intermedio
• texto generado
• actualizaciones de pasos

Los flujos de trabajo asíncronos son útiles cuando la tarea puede tomar mucho tiempo o el cliente no puede mantener una conexión abierta.

Por ejemplo:

• investigación en segundo plano
• generación de documentos grandes
• revisión multiagente
• procesamiento de datos
• aprobación humana
• análisis por lotes

En la práctica, un sistema A2A robusto debería diseñarse alrededor de tres modos: respuesta inmediata para trabajo simple, streaming para trabajo interactivo de larga ejecución y asíncrono para trabajo de fondo durable que puede sobrevivir a cualquier conexión individual. Para SSE, webhooks de empuje, suscripción nuevamente, HITL vía input_required, manejo de errores y listas de verificación de producción, consulta A2A Streaming y Tareas Asíncronas para Flujos de Trabajo de Agentes de Larga Ejecución.

Agent Cards y soporte de streaming

Una Agent Card puede anunciar si un agente soporta streaming.

Esto es importante porque los clientes no pueden asumir que cada agente soporta streaming; algunos agentes pueden soportar solo solicitud y respuesta simples, algunos pueden soportar sondeo de tareas y otros pueden soportar notificaciones de empuje o eventos enviados por el servidor. Un buen cliente inspecciona la Agent Card antes de elegir un patrón de interacción, por lo que las Agent Cards no son solo documentación: moldean directamente el comportamiento en tiempo de ejecución.

A2A y agentes multimodales

A2A está diseñado para soportar más que texto plano.

Esto es importante porque los sistemas de agentes reales procesan cada vez más entradas y salidas mixtas:

• texto
• imágenes
• audio
• video
• PDFs
• hojas de cálculo
• JSON estructurado
• registros
• código
• diagramas

Si cada límite de agente convierte todo en texto, se puede perder información importante.

Por ejemplo, un agente de solución de problemas visuales debería recibir una imagen como una imagen, no como una descripción textual débil. Un agente financiero debería recibir datos estructurados de hojas de cálculo, no un párrafo copiado. Un agente de revisión de código debería recibir archivos de fuente o diffs, no un resumen vago.

Las partes y los tipos de medio son cómo A2A preserva contenido más rico a través de los límites de los agentes, y este es uno de los lugares donde el protocolo es más importante de lo que parece a primera vista, porque la pérdida de información en el límite se complica en cada salto de una cadena multiagente.

A2A no es un framework de agentes

A2A no te dice cómo construir un agente.

No define:

• estrategia de razonamiento
• algoritmo de planificación
• sistema de memoria
• base de datos vectorial
• plantilla de prompt
• proveedor de modelo
• framework de herramientas
• tiempo de ejecución de orquestación
• método de evaluación

Eso es una característica, no un error. A2A es un protocolo de límite que permite que diferentes implementaciones de agentes se comuniquen sin requerir que compartan la misma arquitectura interna, al igual que HTTP no te dice cómo construir una aplicación web, solo define cómo se comunican los sistemas. A2A debe entenderse de la misma manera.

A2A no es un reemplazo para las APIs

A2A tampoco reemplaza cada API.

Si tienes un servicio determinista con un contrato de solicitud y respuesta estable, una API normal puede ser mejor.

Por ejemplo:

• conversión de divisas
• validación de direcciones
• búsqueda de facturas
• redimensionamiento de imágenes
• punto final de búsqueda
• búsqueda de banderas de características (feature flags)
• servicio CRUD interno

Estos no se convierten automáticamente en agentes solo porque son llamados por un sistema de IA. A2A tiene sentido cuando el sistema remoto se comporta genuinamente como un agente:

• posee una tarea
• puede pedir más entrada
• puede usar herramientas internamente
• puede tardar tiempo
• puede producir artefactos
• tiene capacidades que vale la pena descubrir
• puede operar como un par en un flujo de trabajo más grande

No uses A2A solo porque está de moda; úsalo cuando la abstracción se ajuste genuinamente al problema.

Dónde encaja A2A en la arquitectura del sistema de IA

A2A encaja mejor en el límite entre agentes desplegados de forma independiente.

Una arquitectura útil podría verse así:

Usuario
  |
  v
Asistente principal
  |
  |-- A2A --> Agente de investigación
  |-- A2A --> Agente de codificación
  |-- A2A --> Agente de cumplimiento
  |-- A2A --> Agente de documentación

Cada agente especializado puede usar herramientas internamente:

Agente de investigación
  |
  |-- MCP --> búsqueda web
  |-- MCP --> almacén de documentos
  |-- MCP --> base de datos vectorial

Esto te da capas separadas:

Capa de interfaz de usuario
Capa de coordinación de agentes
Capa de integración de herramientas
Capa de datos y ejecución

A2A vive en la capa de coordinación de agentes, MCP a menudo vive en la capa de integración de herramientas, y las APIs normales, colas, bases de datos y sistemas de almacenamiento viven debajo de eso, cada capa con su propia abstracción y sus propios modos de fallo. Para un mapa transversal de cómo la inferencia de LLM, la memoria, el enrutamiento, las herramientas y la observabilidad se unen dentro de los asistentes de producción, consulta Arquitectura de Asistentes de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad.

Patrón de arquitectura: Orquestador y Especialistas

El patrón A2A más común es probablemente orquestador más especialistas.

En este patrón, un agente principal recibe la solicitud del usuario y delega piezas de trabajo a agentes especializados.

Ejemplo:

Asistente principal
  |
  |-- A2A --> Agente legal
  |-- A2A --> Agente financiero
  |-- A2A --> Agente de investigación
  |-- A2A --> Agente de escritura

Este patrón es fácil de entender: el orquestador posee el flujo de trabajo general, y los agentes especializados poseen el trabajo específico del dominio. El inconveniente es que el orquestador puede convertirse en un cuello de botella, y necesita una estrategia de enrutamiento sólida para delegar eficazmente; la selección del modelo subyacente y las compensaciones de orquestación se cubren en Diseño de Sistema Multi-Modelo: Cuando un modelo no es suficiente. Sin embargo, para la mayoría de los equipos, esta es la mejor primera arquitectura multiagente a la que recurrir antes de explorar topologías más complejas.

Patrón de arquitectura: Agentes pares

En un patrón de pares, los agentes pueden comunicarse entre sí más directamente.

Por ejemplo:

Agente de investigación --> Agente de datos --> Agente de gráficos --> Agente de escritura

Esto puede ser poderoso, pero es más difícil de controlar.

Necesitas reglas fuertes para:

• quién puede llamar a quién
• qué contexto puede compartirse
• cómo se previenen los bucles
• quién posee la salida final
• cómo se controla el costo
• cómo se audita la delegación

Las redes de agentes pares suenan elegantes, pero pueden volverse caóticas rápidamente; úsalas solo cuando tengas reglas de gobernanza sólidas y una propiedad clara sobre cada borde en el grafo.

Patrón de arquitectura: Puerta de enlace (Gateway) A2A

Un patrón más amigable para la producción es una puerta de enlace A2A.

En lugar de que cada agente llame directamente a cada otro agente, el tráfico fluye a través de una puerta de enlace.

La puerta de enlace puede manejar:

• autenticación
• autorización
• enrutamiento
• mapeo de inquilinos
• registro
• límites de tasa
• verificaciones de política
• manejo de versiones de protocolo
• observabilidad
• registros de auditoría

Esto es especialmente útil en entornos empresariales, donde la puerta de enlace se convierte en el plano de control para la comunicación de agentes, aplicando la política en un lugar en lugar de reimplementarla en cada agente. En sistemas más pequeños, esto puede ser excesivo, pero en sistemas más grandes con múltiples equipos y proveedores, a menudo se vuelve necesario antes de lo esperado.

Consideraciones de seguridad

La seguridad de A2A merece atención seria.

La comunicación de agente a agente puede mover contexto sensible a través de límites. También puede delegar trabajo a sistemas que pueden tener sus propias herramientas y permisos.

Las preguntas centrales de seguridad son:

• ¿Qué agentes tienen permiso para descubrir este agente?
• ¿Qué agentes tienen permiso para enviarle tareas?
• ¿Qué autenticación se requiere?
• ¿Qué permisos están asociados con el llamante?
• ¿Puede un agente delegar la autoridad del usuario a otro?
• ¿Qué datos pueden incluirse en los mensajes?
• ¿Qué artefactos pueden devolverse?
• ¿Cómo se audita la tarea?
• ¿Puede el agente receptor llamar a herramientas u otros agentes?
• ¿Cómo se protegen los secretos?

Las Agent Cards no deberían contener secretos estáticos, y las Agent Cards sensibles deberían protegerse detrás de autenticación en lugar de publicarse abiertamente. Diferentes clientes a menudo necesitan diferentes vistas del mismo agente: un llamante interno puede ver más habilidades que un socio externo, mientras que un cliente público puede ver solo un conjunto limitado de capacidades seguras.

La seguridad no debería agregarse después de que se construya la red de agentes; debería moldear la red desde el principio, porque retrofitting límites de autenticación y permisos a través de una topología de agentes en vivo es significativamente más difícil que diseñarlos desde el inicio. Para el tratamiento completo — modelo de amenazas, capas de identidad, plano de control de la puerta de enlace, alcance de delegación y registros de auditoría — consulta Seguridad de Agentes A2A y MCP: Identidad, Delegación y Registros de Auditoría.

Consideraciones de observabilidad

Los sistemas A2A necesitan una observabilidad sólida.

Cuando una tarea cruza límites de agentes, la depuración se vuelve sustancialmente más difícil porque ningún sistema individual tiene la imagen completa. Necesitas saber:

• qué agente creó la tarea
• qué agente la aceptó
• qué mensajes se intercambiaron
• qué cambios de estado ocurrieron
• qué artefactos se produjeron
• qué errores sucedieron
• cuánto tiempo tomó cada paso
• qué herramientas se usaron internamente
• si se llamó a otro agente
• quién aprobó acciones arriesgadas

Un traza útil debería seguir el trabajo a través de toda la cadena.

Por ejemplo:

solicitud del usuario
  -> tarea del asistente principal
  -> tarea del agente de investigación
  -> llamada a la herramienta de búsqueda de documentos
  -> artefacto de resumen
  -> respuesta final

Sin ese traza de extremo a extremo, los sistemas multiagente se vuelven muy difíciles de confiar en producción; no puedes responder con confianza por qué el sistema produjo una salida dada, ni siquiera identificar dónde salió mal. Observabilidad para Sistemas de LLM: Métricas, Traces, Registros y Pruebas en Producción cubre el lado de la instrumentación y las herramientas de este problema en profundidad.

Errores comunes

Error 1: Llamar a cada herramienta un agente

No cada herramienta es un agente.

Una calculadora es una herramienta. Un lector de archivos es una herramienta. Un punto final de consulta de base de datos es una herramienta.

Si no posee una tarea, no pide entrada, no produce artefactos o no se comporta como un par independiente, probablemente no necesite A2A.

Error 2: Hacer las Agent Cards demasiado vagas

Una Agent Card no debería decir:

Este agente ayuda con tareas comerciales.

Eso es inútil para cualquier agente que intente enrutar trabajo de manera inteligente. Una buena tarjeta debería decir qué hace realmente el agente, qué acepta, qué devuelve y qué restricciones se aplican.

Error 3: Ignorar el estado de la tarea

Si usas A2A pero tratas cada interacción como solicitud y respuesta, estás perdiendo gran parte del valor.

El modelo de tareas es una de las razones principales para usar A2A sobre una API simple; omitirlo significa reconstruir la misma lógica de seguimiento del ciclo de vida en cada integración.

Error 4: Devolver todo como texto

A2A soporta contenido estructurado y multimodal. Úsalo.

Si la salida es un informe, devuelve un artefacto de informe.

Si la salida es JSON, devuelve datos estructurados.

Si la salida es un archivo, devuelve un archivo.

No aplanes todo en texto plano a menos que el texto plano sea la salida correcta.

Error 5: Sin modelo de permisos

Las redes de agentes sin límites de permisos son arriesgadas.

No a cada agente se le debería permitir llamar a cada otro agente con cada tipo de datos; usa autenticación, autorización y registros de auditoría para aplicar el principio de mínimo privilegio en toda la red de agentes.

¿Cuándo deberías usar A2A?

Usa A2A cuando tengas límites reales de agentes.

Buenas razones incluyen:

• los agentes son propiedad de diferentes equipos
• los agentes se despliegan como servicios separados
• los agentes se construyen con diferentes frameworks
• los agentes necesitan descubrirse mutuamente
• los agentes necesitan delegar tareas
• las tareas pueden ser de larga ejecución
• los resultados pueden incluir artefactos
• los clientes no deberían conocer las herramientas internas
• los metadatos de capacidad del agente son importantes

Razones débiles incluyen:

• suena moderno
• quieres llamar a una sola función
• tienes una aplicación de agente único
• una API normal funcionaría
• MCP ya resuelve tu problema de integración de herramientas

A2A es poderoso cuando el sistema es realmente multiagente; es una ceremonia innecesaria cuando no lo es, y el costo de esa ceremonia — conceptos añadidos, infraestructura, superficie de depuración y requisitos de seguridad — es real.

Un modelo mental mínimo

Si recuerdas solo una cosa, recuerda esto:

Agent Card: qué puede hacer el agente.
Mensaje: lo que los agentes se dicen entre sí.
Parte: contenido tipificado dentro de un mensaje o artefacto.
Tarea: trabajo que posee el agente.
Artefacto: salida que produjo la tarea.

Ese es el núcleo de A2A; el resto es principalmente sobre hacer que esos cinco conceptos sean confiables, observables y suficientemente seguros para usarlos en sistemas de producción reales.

Reflexiones finales

A2A no es solo otro acrónimo de IA; es parte de un cambio más grande desde asistentes aislados hacia sistemas de agentes interoperables. Ese cambio no ocurrirá en todas partes a la vez, y muchas aplicaciones permanecerán como sistemas de agente único con buen acceso a herramientas donde MCP y las APIs normales son completamente suficientes.

Pero una vez que los agentes se convierten en pares desplegados de forma separada, necesitas límites más fuertes: descubrimiento, propiedad de tareas, mensajes que transportan más que texto, artefactos como salidas de primera clase, y seguridad, estado y observabilidad que abarquen los límites de los agentes. Ese es el espacio que A2A intenta ocupar, y es un problema genuinamente diferente del problema de integración de herramientas que resuelve MCP.

Para una perspectiva práctica sobre dónde A2A realmente tiene tracción en producción en 2026 — incluyendo niveles de adopción, preocupaciones de seguridad, el caso de uso empresarial y un marco de decisión — consulta Protocolo A2A de Google en 2026: Adopción, Hype y Realidad.

Mi opinión: no comiences con A2A para proyectos pequeños. Comienza con un agente útil, buenas herramientas y una arquitectura clara; el clúster de Sistemas de IA cubre asistentes autohospedados, servidores MCP y memoria de agentes como un conjunto conectado si quieres el contexto más amplio. Pero cuando tu “herramienta” comienza a parecerse a otro especialista autónomo con su propio ciclo de vida de tareas, probablemente ya no es solo una herramienta; y es cuando A2A se vuelve interesante.

Fuentes

• Especificación del Protocolo A2A: https://a2a-protocol.org/latest/specification/
• Conceptos Clave de A2A: https://a2a-protocol.org/latest/topics/key-concepts/
• Vida de una Tarea en A2A: https://a2a-protocol.org/latest/topics/life-of-a-task/
• Descubrimiento de Agentes en A2A: https://a2a-protocol.org/latest/topics/agent-discovery/
• Operaciones de Streaming y Asíncronas en A2A: https://a2a-protocol.org/latest/topics/streaming-and-async/
• A2A y MCP: https://a2a-protocol.org/latest/topics/a2a-and-mcp/