Google muestra A2A como red de agentes: el handoff empieza a importar más que el prompt
Google publicó el 18 de junio de 2026 una lectura de A2A enfocada en agentes colaborativos. Para builders, la señal práctica es separar agente principal, especialistas, agent cards y permisos antes de llenar el contexto con herramientas.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Google publicó el 18 de junio de 2026 una actualización sobre Agent2Agent Protocol, o A2A, con un mensaje bastante útil para quienes están construyendo agentes reales: el siguiente salto no es meter más tools en un solo prompt, sino permitir que un agente delegue trabajo a otros agentes especializados sin contaminar todo el contexto.
La pieza de Google usa ejemplos de agentes colaborativos y menciona handoffs donde un agente principal puede pedir apoyo a otro sistema. En términos prácticos, eso convierte la arquitectura de agentes en algo más parecido a una red con contratos claros que a un asistente gigante con acceso a todo.
Qué cambia para un builder
La tentación normal al crear un agente es agregarle más instrucciones, más tools y más contexto. Funciona en demos pequeñas, pero se rompe cuando el flujo mezcla dominios: investigación, datos internos, ejecución de código, aprobaciones, pagos, mensajes y documentos. Cada tool nueva aumenta superficie de error, costo y riesgo.
A2A propone otro patrón: un agente puede descubrir o invocar a otro agente mediante un contrato. El agente especializado conserva su contexto, sus permisos y su forma de trabajo. El coordinador recibe una respuesta o un estado, no todo el ruido interno.
Eso importa para equipos que ya usan MCP, ADK, Gemini CLI, Copilot, Codex o Claude Code. MCP ayuda a conectar tools. A2A apunta al handoff entre agentes. La pregunta deja de ser "¿cuántas tools puede usar mi agente?" y pasa a ser "¿qué trabajo debe resolver otro agente con su propio perímetro?".
Agent cards antes que magia
La parte menos vistosa es también la más importante: si vas a delegar trabajo, necesitas describir capacidades de forma legible por máquinas y auditable por humanos. Un agent card debería decir qué hace el agente, qué entradas acepta, qué estado devuelve, qué autenticación requiere y qué límites tiene.
Sin esa capa, A2A se vuelve otro nombre para llamadas opacas. Con esa capa, puedes empezar a versionar agentes como servicios internos: un agente de compliance, uno de búsqueda, uno de despliegue, uno de soporte, uno de análisis de datos.
Dónde se rompe si lo implementas rápido
El primer error es usar A2A para evitar diseño. Si el agente principal no sabe cuándo delegar, solo mueves la confusión a otra caja. Define criterios: delegar cuando el dominio requiere permisos separados, cuando el contexto del especialista es grande, cuando necesitas auditoría propia o cuando la tarea puede correr en paralelo.
El segundo error es olvidar identidad. Un agente que llama a otro agente no debería heredar permisos ilimitados del usuario. Necesitas scopes, tokens cortos, logs y una política clara para acciones irreversibles.
El tercero es no medir latencia. Un handoff puede mejorar calidad y seguridad, pero también agrega pasos, red y estados intermedios. Para workflows interactivos, eso puede sentirse lento. Para tareas largas, puede ser justo lo que necesitas.
La demanda de búsqueda no se reporta con volumen porque no hay SEO tooling conectado. Se infiere por señales actuales: Google publicó la actualización de A2A, la conversación de ARD y MCP está activa, y queries como A2A agents, Agent2Agent Protocol, agent cards y multi-agent handoff tienen intención técnica clara.
Si estás armando tu primer agente, empieza simple en el curso gratis. Si ya tienes varios agentes o tools compitiendo por contexto, la lectura útil de A2A es directa: separa coordinación, especialización e identidad antes de intentar que un solo agente lo haga todo.