¿Qué es el protocolo A2A? Explicación de Agent Cards y Tareas

El Protocolo A2A, siglas de Protocolo Agent2Agent (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 solo asistente, un solo entorno de ejecución, un solo ciclo de herramientas y un solo 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, marcos de trabajo, proveedores, lenguajes u organizaciones. Asume que un agente puede necesitar descubrir otro agente, entender qué puede hacer, enviarle trabajo, intercambiar mensajes, recibir archivos o resultados estructurados 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:

• Tarjetas de Agente (Agent Cards)
• 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 de ingeniería claros, con suficiente detalle para entender dónde encaja A2A en sistemas reales de múltiples agentes.

La Definición Breve

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 usar internamente:

• Python
• Go
• JavaScript
• LangGraph
• CrewAI
• Semantic Kernel
• código personalizado
• servidores MCP
• APIs privadas
• bases de datos vectoriales
• motores de flujos 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 pasando de asistentes individuales a redes de agentes especialistas.

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 convierte en algo personalizado: el agente de soporte necesita cableado personalizado para conectarse al agente de facturación, el agente de facturación necesita el suyo propio para el agente legal, y el agente de investigación necesita otro más para el agente de documentación. Esa sobrecarga combinatoria no escala bien a medida que crece la red de agentes.

A2A les da 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 se compara a menudo con MCP, pero resuelven problemas diferentes.

MCP, o Protocolo de Contexto de Modelo (Model Context Protocol), trata principalmente sobre conectar una aplicación o agente de IA a herramientas, recursos y prompts, mientras que A2A trata principalmente sobre 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

Están disponibles guías prácticas para construir esos servidores MCP en 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.

Eso significa que otros agentes se comunican con tu agente usando A2A, mientras que tu agente usa MCP internamente para acceder a herramientas, una separación limpia de responsabilidades que mantiene la interfaz externa estable independientemente de lo que cambie internamente. 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 Principales en A2A

A2A utiliza un modelo de roles simple basado en dos partes: un agente que expone capacidades y un cliente que quiere usarlas.

El cliente podría ser:

• otro agente
• un orquestador
• una aplicación de asistente
• un sistema de flujos de trabajo
• una puerta de enlace (gateway)
• un arnés de pruebas
• una aplicación orientada al usuario

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 cierta capacidad y la expone a través de una interfaz de agente.

Tarjetas de Agente (Agent Cards)

La Tarjeta de Agente es uno de los conceptos más importantes en A2A.

Una Tarjeta de Agente 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 Tarjeta de Agente como una mezcla de:

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

Una Tarjeta de Agente típica puede describir cosas como:

• nombre del agente
• descripción
• punto de acceso 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 Tarjeta de Agente es importante porque los agentes no deberían necesitar tener conocimiento codificado de cada otro agente.

Un cliente puede inspeccionar la tarjeta y decidir:

• ¿Es este el agente adecuado para el trabajo?
• ¿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 Tarjetas de Agente 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 consultar qué está disponible antes de comprometerse con una integración.

Las Tarjetas de Agente Son Límites de Capacidad

Una Tarjeta de Agente 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 financiero, los clientes pueden comenzar a delegarle trabajo de análisis financiero. Si dice que el agente acepta archivos, los clientes pueden enviar archivos. Si dice que el agente soporta transmisión, los clientes pueden esperar eventos de progreso.

Las Tarjetas de Agente deficientes crean sistemas deficientes porque las decisiones de enrutamiento y las suposiciones de capacidad se propagan por toda la red de agentes. Una Tarjeta de Agente útil debería ser:

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

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

Una mejor habilidad sería:

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

Incluso mejor, incluye los 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 Tarjeta de Agente, más fácil será para otros agentes enrutar las tareas correctamente.

Descubrimiento de Agentes

El descubrimiento de agentes es el proceso de encontrar una Tarjeta de Agente.

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 involucrar:

• 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 conscientes del inquilino (tenant-aware gateways)

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

No cada agente debería ser descubrible por todos: un agente de nómina interno no debería exponer la misma Tarjeta de Agente a cada llamante, y un agente de socio puede 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 que está siendo 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 de agentes reales no son instantáneos.

Una tarea podría involucrar:

• 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, dá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 curso
• entrada requerida
• 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 inmediatamente, 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 cortadas en flujos de trabajo completos de tareas añade sobrecarga innecesaria.

Si un cliente pregunta:

Resume este párrafo único.

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 acomodar eso.

Un mensaje podría incluir:

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

El mensaje es el sobre; las partes son el contenido tipado 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, imagen, carga JSON, archivo de registro o 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 final.

Artefactos

Los Artefactos son resultados concretos producidos por un agente durante el procesamiento de una 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 “Encontré la respuesta”, eso es un mensaje. Cuando devuelve market-analysis.md, sources.json e risk-summary.csv, esos son artefactos: resultados concretos 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 la conversación.
Los Artefactos son la 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 pruebas 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 Tarjeta de Agente que dice que puede:

• escribir documentación de API
• aceptar especificaciones OpenAPI
• aceptar guías de estilo Markdown
• producir documentos 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 la audiencia 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 de acceso.

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, comunica según sea necesario y rastrea el resultado hasta la finalización”.

Por Qué las Tareas Importan Para Sistemas Reales

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

Una llamada normal de API HTTP a menudo es demasiado básica 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 de múltiples pasos
• flujos de trabajo de aprobación humana

Sin un modelo de tareas, los desarrolladores generalmente reconstruyen esta lógica ellos mismos con IDs de trabajo personalizados, colas, puntos de acceso 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 Asíncrono y Streaming

A2A soporta la idea de que el trabajo de agentes puede ser en tiempo real (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 multi-agente
• 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 de larga ejecución interactivo y asíncrono para trabajo de fondo durable que pueda sobrevivir a cualquier conexión individual.

Tarjetas de Agente y Soporte de Streaming

Una Tarjeta de Agente 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 simple, algunos pueden soportar sondeo (polling) de tareas y otros pueden soportar notificaciones push o eventos enviados por el servidor (server-sent events). Un buen cliente inspecciona la Tarjeta de Agente antes de elegir un patrón de interacción, por lo que las Tarjetas de Agente 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 de texto 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 fuente o diferencias (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 acumula en cada salto de una cadena multi-agente.

A2A No Es Un Marco de Trabajo 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 modelos
• marco de herramientas
• entorno 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 debería entenderse de la misma manera.

A2A No Es Un Reemplazo Para APIs

A2A tampoco reemplaza cada API.

Si tienes un servicio determinista con un contrato estable de solicitud y respuesta, 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 de acceso 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 encaje genuinamente con el problema.

Dónde Encaja A2A en la Arquitectura de Sistemas de IA

A2A encaja mejor en el límite entre agentes desplegables 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 encajan la inferencia de LLM, la memoria, el enrutamiento, las herramientas y la observabilidad dentro de 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 probablemente sea orquestador más especialistas.

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

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 especialistas 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 efectivamente; la selección del modelo subyacente y las compensaciones de orquestación se cubren en Diseño de Sistemas Multi-Modelo: Cuando Un Modelo No Es Suficiente. Sin embargo, para la mayoría de los equipos, esta es la mejor arquitectura multi-agente inicial a la que recurrir antes de explorar topologías más complejas.

Patrón de Arquitectura: Agentes Pares

En un patrón punto a punto (peer-to-peer), 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 fuertes y una propiedad clara sobre cada borde en el gráfico.

Patrón de Arquitectura: Puerta de Enlace A2A

Un patrón más amigable para la producción es una puerta de enlace (gateway) 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 (tenant mapping)
• registro (logging)
• límites de tasa
• verificaciones de política
• manejo de versiones del protocolo
• observabilidad
• rastros 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 solo 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 una atención seria.

La comunicación 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 de seguridad centrales son:

• ¿Qué agentes están permitidos para descubrir este agente?
• ¿Qué agentes están permitidos para enviarle tareas?
• ¿Qué autenticación se requiere?
• ¿Qué permisos están adjuntos al 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 Tarjetas de Agente no deberían contener secretos estáticos, y las Tarjetas de Agente sensibles deberían estar protegidas 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 dar forma a la red desde el principio, porque parchear los 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.

Consideraciones de Observabilidad

Los sistemas A2A necesitan una observabilidad fuerte.

Cuando una tarea cruza límites de agentes, la depuración se vuelve sustancialmente más difícil porque ningún sistema individual tiene el panorama completo. 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 ocurrieron
• cuánto tiempo tomó cada paso
• qué herramientas se usaron internamente
• si se llamó a otro agente
• quién aprobó acciones arriesgadas

Un trazo (trace) útil debería seguir el trabajo a través de la cadena completa.

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 trazo de extremo a extremo, los sistemas multi-agente se vuelven muy difíciles de confiar en producción; no puedes responder confiadamente por qué el sistema produjo una salida dada, ni mucho menos 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 Agente a Cada Herramienta

No cada herramienta es un agente.

Una calculadora es una herramienta. Un lector de archivos es una herramienta. Un punto de acceso 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 Tarjetas de Agente Demasiado Vagas

Una Tarjeta de Agente no debería decir:

Este agente ayuda con tareas empresariales.

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; saltarlo 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 aplana 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 cada agente debería estar permitido para llamar a cada otro agente con cada tipo de datos; usa autenticación, autorización y rastros de auditoría para aplicar el principio de mínimo privilegio a través de la red de agentes.

¿Cuándo Deberías Usar A2A?

Usa A2A cuando tienes límites reales de agentes.

Las buenas razones incluyen:

• los agentes son propiedad de diferentes equipos
• los agentes se despliegan como servicios separados
• los agentes se construyen con diferentes marcos de trabajo
• 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

Las razones débiles incluyen:

• suena moderno
• quieres llamar a una 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 multi-agente; es una ceremonia innecesaria cuando el sistema 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:

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

Ese es el núcleo de A2A; el resto es principalmente sobre hacer que esos cinco conceptos sean lo suficientemente confiables, observables y seguros para usar 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 sucederá 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 más que 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 transporten 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 está intentando 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 de producción en 2026, incluidas las capas de adopción, las 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/