Protocolo A2A de Google en 2026: adopción, expectativas y realidad

A2A no está muerto. Simplemente no es universal.

Índice

El protocolo Agent2Agent de Google, habitualmente abreviado como A2A, tuvo un primer año extraño.

Cuando Google anunció A2A en abril de 2025, la propuesta era clara: los agentes de IA construidos por diferentes proveedores, marcos de trabajo (frameworks) y equipos necesitaban una forma estándar de comunicarse. El protocolo prometía descubrimiento de agentes, delegación de tareas, intercambio de mensajes, actualizaciones en streaming y compartición de artefactos. Sin embargo, la reacción fue considerablemente menos nítida que el anuncio.

Algunos desarrolladores vieron en A2A la capa faltante de comunicación entre agentes para la emergente pila agéntica (agentic stack). Otros lo vieron como otro protocolo de Google, otra sigla y otro intento de definir un mercado antes de que este tuviera necesidades reales de producción. La postura escéptica se reducía a una sola pregunta: “Ya tenemos MCP. ¿Por qué necesitamos A2A?”. Esa fue una pregunta justa en 2025, y sigue siéndolo en 2026, aunque la respuesta ha cambiado considerablemente.

Dos sistemas de agentes de IA conectados por el puente del protocolo A2A

A2A no está muerto, pero tampoco es universalmente útil. La realidad práctica es que A2A se está volviendo genuinamente valiosa en un contexto específico: donde los agentes son sistemas independientes con su propia propiedad, herramientas y límites de confianza, en lugar de ser simplemente funciones internas o envoltorios de herramientas. Esa distinción entre la integración de herramientas y la delegación de agentes es lo que el protocolo está realmente diseñado para abordar, y entenderla es la clave para evaluar A2A sin caer en el entusiasmo excesivo en ninguna dirección.

¿Qué es el protocolo A2A de Google?

A2A significa Protocolo Agent2Agent, y ese nombre captura su propósito con precisión. Es un estándar abierto para la comunicación e interoperabilidad entre sistemas de agentes de IA independientes; específicamente, agentes que pueden estar construidos utilizando diferentes marcos de trabajo, lenguajes o pilas de proveedores.

A2A no se trata principalmente de conectar un agente a una base de datos, sistema de archivos, calendario, API o índice de búsqueda. Eso está más cerca del trabajo de MCP, el Protocolo de Contexto del Modelo (Model Context Protocol). A2A trata sobre algo diferente: un agente comunicándose con otro agente, tratando al sistema par como un actor con sus propias capacidades en lugar de una fuente de datos pasiva.

Un flujo típico de A2A podría implicar:

Descubrir un agente a través de una Tarjeta de Agente (Agent Card)
Leer las habilidades y capacidades del agente
Enviar una tarea
Intercambiar mensajes
Recibir actualizaciones de estado
Manejar estados que requieren entrada
Recibir artefactos finales
Rastrear la finalización, falla o cancelación

La palabra importante en esa lista es “tarea”. A2A no es solo una llamada a función con un envoltorio diferente; es un protocolo de ciclo de vida de tareas para la colaboración de agentes, diseñado para manejar el arco completo desde el descubrimiento y la delegación, pasando por la ejecución y las actualizaciones de estado, hasta la devolución de artefactos. Para una revisión técnica profunda de cada concepto —Tarjetas de Agente, ciclo de vida de tareas, mensajes, partes y artefactos— consulte ¿Qué es el Protocolo A2A? Tarjetas de Agente y Tareas Explicadas.

Por qué A2A era fácil de burlar

A2A llegó a un mercado que ya se ahogaba en siglas de agentes.

Para 2025, los desarrolladores ya lidiaban con:

APIs de LLM
Llamadas a funciones (Function calling)
Llamadas a herramientas (Tool calling)
Marcos de trabajo para agentes (Agent frameworks)
Servidores MCP
Pipelines RAG
Motores de flujo de trabajo (Workflow engines)
Bibliotecas de orquestación multi-agente
Protocolos JSON personalizados
Sistemas de plugins internos

Así que cuando Google anunció A2A, una reacción común fue predecible:

“¿Realmente necesitamos otro estándar?”

El escepticismo no era irracional y provenía de varias direcciones a la vez. A2A parecía superponerse con MCP. Provino de Google, lo que hizo que algunos desarrolladores se preocuparan por el compromiso a largo plazo. Llegó antes de que la mayoría de los equipos hubieran resuelto incluso el acceso básico a herramientas, inyección de prompts, observabilidad, control de costos y seguridad para sistemas de un solo agente.

En ese entorno, la “interoperabilidad entre agentes” sonaba ambiciosa, pero también un poco prematura.

Y para ser directos, muchas demostraciones de agentes de IA en 2025 no necesitaban A2A en absoluto.

Necesitaban mejores prompts, mejores herramientas, mejores permisos, mejor lógica de reintento y mejores registros.

La actualización de 2026: A2A no está muerto

El gran cambio en 2026 es que A2A ya no es solo un anuncio de Google.

Para abril de 2026, la Fundación Linux informó que el proyecto A2A había superado las 150 organizaciones de apoyo, obtuvo integraciones en principales plataformas en la nube y alcanzó despliegues de producción en múltiples industrias.

Eso no significa que cada afirmación deba ser aceptada sin escepticismo. “Apoyado por” no es lo mismo que “utilizado profundamente en producción por la mayoría de los desarrolladores”. Los ecosistemas de protocolos a menudo parecen más grandes en los comunicados de prensa de lo que se sienten en el trabajo de ingeniería diario.

Sin embargo, la señal importa, porque es más difícil de descartar. A2A ha cruzado una línea importante: ya no es solo una publicación en el blog de Google. Tiene una especificación formal, impulso de gobernanza, ejemplos públicos, trabajo en SDKs, atención de plataformas en la nube y un ecosistema creciente en torno a la interoperabilidad de agentes. Eso hace que la etiqueta de “muerto” sea difícil de defender en términos técnicos o de adopción.

Una crítica más defendible es que A2A está vivo, pero su alcance útil es más estrecho de lo que sugiere el entusiasmo excesivo.

A2A vs MCP: La confusión que no quería morir

La mayoría de la confusión sobre A2A proviene de su relación con MCP.

MCP, creado por Anthropic, estandariza cómo las aplicaciones de IA se conectan a herramientas y fuentes de datos externas. Los servidores MCP exponen herramientas, recursos y prompts. Los hosts y clientes de IA los consumen.

En términos simples:

MCP conecta agentes a herramientas.
A2A conecta agentes a otros agentes.

Eso suena limpio, pero el mundo real es considerablemente más desordenado. Un servidor MCP puede exponer algo que parece muy agéntico; por ejemplo, una herramienta MCP llamada research_company que internamente ejecuta búsqueda, recuperación, resumen, clasificación y redacción de informes. Desde el punto de vista del host de MCP, es una herramienta. Desde un punto de vista arquitectónico, está ocultando un flujo de trabajo similar a un agente detrás de un límite de llamada a función. Esta ambigüedad es precisamente por qué algunos desarrolladores argumentaron que A2A era innecesario: si un agente puede representarse como una herramienta MCP, ¿por qué crear un protocolo separado?

La respuesta es que A2A da una estructura de primera clase a cosas que MCP trata de manera más torpe:

Descubrimiento de agentes
Capacidades del agente
Ciclo de vida de tareas
Trabajo de larga duración
Estado de tareas de múltiples turnos
Mensajería entre agentes
Artefactos
Colaboración entre agentes opacos
Delegación a través de límites organizacionales

MCP puede envolver mucho, pero envolver todo como una herramienta eventualmente se convierte en una mala abstracción. En algún punto, un sistema especialista tiene suficiente estado propio, política, ciclo de vida y autoridad de toma de decisiones que modelarlo como una herramienta oscurece la arquitectura en lugar de simplificarla. Ese es el punto de inflexión donde tratar a un agente par como un agente par, en lugar de como una llamada a herramienta, comienza a dar frutos. Para una comparación detallada de dónde cae el límite en la práctica, consulte A2A vs MCP: ¿Realmente los agentes de IA necesitan ambos protocolos?

El mejor modelo mental: MCP abajo, A2A arriba

La arquitectura más limpia no es “A2A vs MCP”.

La arquitectura más limpia es en capas:

flowchart TD U["Usuario o aplicación"] O["Asistente principal / orquestador"] S1["Agente especialista A"] S2["Agente especialista B"] T1["Herramientas, APIs, archivos, bases de datos"] T2["Más herramientas y fuentes de datos"] U --> O O -->|A2A| S1 O -->|A2A| S2 S1 -->|MCP| T1 S2 -->|MCP| T2

En este modelo:

A2A es la capa de colaboración de agentes.
MCP es la capa de integración de herramientas.

Ese es el patrón que tiene más sentido en 2026, y es el enfoque hacia el cual convergen la mayoría de los arquitectos de agentes serios. A2A no debería reemplazar a MCP, y MCP no debería verse obligado a representar cada límite de agente; resuelven problemas diferentes en diferentes capas de la pila. El encuadre de “guerra de protocolos” es mayormente un análisis perezoso que genera buenos titulares mientras no ayuda en nada a los ingenieros a diseñar mejores sistemas.

Dónde A2A es realmente útil

A2A se vuelve útil cuando un agente ya no es solo una llamada a una biblioteca dentro de su aplicación.

Es útil cuando los agentes son:

Desplegados independientemente
Propiedad de diferentes equipos
Construidos con diferentes marcos de trabajo
Expuestos por proveedores
Ejecutándose con sus propias herramientas y permisos
Responsables de tareas de larga duración
Devolviendo artefactos en lugar de valores simples
Parte de un flujo de trabajo multi-agente más amplio

Por ejemplo, imagine un asistente empresarial que necesita preparar un informe de riesgo de proveedores.

Podría delegar trabajo a:

Un agente de compras
Un agente de revisión legal
Un agente financiero
Un agente de cumplimiento
Un agente de investigación de mercado
Un agente de redacción de informes

Cada agente tiene su propio dominio, herramientas, reglas, permisos y requisitos de auditoría.

Para ese tipo de sistema, A2A no es absurdo. Es un límite razonable.

El asistente principal no debería necesitar acceso directo a cada base de datos de compras, almacén de políticas legales, hoja de cálculo financiera y flujo de trabajo de cumplimiento. Debería pedirle al agente responsable que realice la tarea.

Esa es la distinción esencial: el acceso a herramientas es una conexión vertical entre un agente y sus recursos, mientras que la delegación de dominio es una transferencia horizontal entre agentes autónomos, cada uno con su propio límite de autoridad y responsabilidad. El modelo en capas de cómo se combinan estos componentes —LLM, memoria, herramientas, enrutamiento y observabilidad— se cubre en Arquitectura de Asistentes de IA: LLM, Memoria, Herramientas, Enrutamiento, Observabilidad.

Dónde A2A sigue teniendo un entusiasmo excesivo

A2A tiene un entusiasmo excesivo cuando las personas lo presentan como infraestructura obligatoria para cada proyecto de IA.

La mayoría de los proyectos no lo necesitan.

Si está construyendo un asistente de código local, un chatbot para sus documentos, un pequeño agente de automatización interna o un flujo de trabajo único que llama a un puñado de herramientas, probablemente A2A sea innecesario.

Podría necesitar:

MCP
Buenas esquemas de herramientas
Barreras de seguridad (Guardrails)
Evaluación
Registro (Logging)
Control de costos
Lógica de reintento
Mejores prompts
Mejor recuperación

Probablemente no necesite un protocolo completo de agente a agente.

A2A puede ser un error cuando:

Solo hay un agente
Todos los componentes viven en un mismo código fuente
Los flujos de trabajo son cortos y síncronos
Los agentes no necesitan descubrimiento
Los agentes no necesitan estado de tarea independiente
No hay proveedores de agentes externos
Una API o cola sería más simple
El equipo no puede operar la complejidad adicional

Un protocolo no es gratis. Añade conceptos, modos de falla, sobrecarga de depuración, preocupaciones de seguridad y trabajo operativo.

En muchos sistemas pequeños, adoptar A2A es cosplay de arquitectura: tomar prestado el vocabulario de sistemas de agentes distribuidos sin ninguno de los problemas reales de límite que hacen que el protocolo sea valioso.

A2A y el problema de Google

Parte del escepticismo hacia A2A proviene de Google mismo.

Los desarrolladores tienen larga memoria. Cuando Google lanza una plataforma, protocolo, producto o ecosistema, muchos ingenieros preguntan inmediatamente:

“¿Esto seguirá existiendo en tres años?”

Esa reacción no es completamente justa con el diseño técnico de A2A, pero es un factor real de adopción.

La historia de la sede en la Fundación Linux ayuda aquí. Que A2A se convierta en parte de un entorno de gobernanza abierta más amplio lo hace menos dependiente de las prioridades internas de Google.

Eso no garantiza el éxito. La gobernanza abierta no crea mágicamente la adopción de desarrolladores. Pero sí reduce una de las mayores preocupaciones: que A2A sea solo un movimiento estratégico controlado por Google.

En 2026, A2A debería juzgarse menos como “el protocolo de Google” y más como un estándar emergente de interoperabilidad de agentes que Google ayudó a iniciar.

Esa es una lente más saludable, y es la que hace que los méritos técnicos de A2A sean más fáciles de evaluar por sus propios términos en lugar de a través del filtro de la relación histórica de Google con los ecosistemas de desarrolladores.

Adopción: Señal fuerte, pero no toda la historia

Las 150+ organizaciones de apoyo reportadas son significativas, pero no deben confundirse con la adopción universal por parte de los desarrolladores. “Apoyado por” es un espectro, no un binario, y ayuda leer las afirmaciones de adopción con eso en mente.

En el extremo más débil está la adopción de logotipos: una empresa dice que apoya el estándar, lo que puede reflejar una implementación genuina, posicionamiento estratégico, un prototipo o simplemente soporte planificado que no se ha materializado. Ligeramente más fuerte es la adopción de SDKs, donde los desarrolladores realmente pueden construir con bibliotecas, ejemplos y documentación disponibles; esto significa que el protocolo ha pasado de las presentaciones a una implementación funcional, y que ingenieros reales han encontrado que vale su tiempo. Más fuerte aún es la adopción de plataformas, donde las nubes, los marcos de trabajo de agentes y los sistemas empresariales exponen soporte nativo real, haciendo de A2A una elección arquitectónica predeterminada plausible en lugar de algo que los equipos tienen que cablear ellos mismos.

El único nivel de adopción que realmente importa para la salud del ecosistema a largo plazo es la retención en producción. Para tener una idea de cómo se ven las curvas de adopción reales en el espacio de agentes de IA —medidas en estrellas de GitHub, tokens de OpenRouter y tendencias de descargas— los datos de popularidad de OpenClaw vs Hermes Agent muestran qué tan rápido se construye y se estanca el impulso una vez que la energía de los primeros adoptadores disminuye.: equipos que dependen del protocolo para flujos de trabajo en vivo más allá de las primeras 90 días de luna de miel. La actualización de 2026 de la Fundación Linux afirma uso de producción en múltiples industrias, lo cual es evidencia significativa. Pero la pregunta más útil no es “¿quién apoya a A2A?”, sino “¿quién mantiene A2A en producción después del primer incidente operativo real?”. La retención a largo plazo bajo presión es la señal que separa la infraestructura genuina del teatro de protocolos.

La prueba real: Retención en producción

El entusiasmo de los desarrolladores es barato, y la retención en producción es cara. Los dos rara vez son proporcionales, por lo que la pregunta de la retención de 90 días importa más que el entusiasmo de la semana de lanzamiento.

A2A se demostrará a sí mismo si los equipos continúan usándolo después de encontrar:

Problemas de autenticación
Problemas de autorización
Problemas de identidad del agente
Problemas de depuración
Casos extremos del ciclo de vida de tareas
Fallos en streaming
Compatibilidad de versiones
Diferencias entre proveedores
Sorpresas de costos
Revisiones de seguridad
Requisitos de auditoría
Flujos de trabajo de aprobación humana

Aquí es donde muchos marcos de trabajo y protocolos de agentes fallan. Se ven elegantes en diagramas, luego se vuelven dolorosos en producción.

A2A tiene una buena razón para existir, pero las buenas razones no se traducen automáticamente en resiliencia de producción. El protocolo tiene que sobrevivir a la realidad operativa que encuentra en el camino desde la demostración hasta el despliegue.

La mejor señal para A2A en 2026 no es que las personas estén escribiendo publicaciones de blog sobre ello. La mejor señal es que las empresas están comenzando a usarlo para límites reales multi-agente.

La peor señal sería si los desarrolladores solo lo usaran en demostraciones mientras los sistemas de producción vuelven a APIs y colas personalizadas.

La seguridad es la mayor pregunta sin resolver

Los problemas más difíciles de A2A no son de sintaxis o especificación. Son problemas de confianza que surgen cuando realmente despliega agentes autónomos a través de límites organizacionales o de sistema.

Cuando un agente habla con otro agente, varias preguntas se vuelven urgentes:

¿Quién es este agente?
¿Quién es su dueño?
¿Qué le está permitido saber?
¿Qué le está permitido hacer?
¿Puede delegar trabajo más allá?
¿Puede llamar a herramientas en nombre de un usuario?
¿Puede preservar la intención del usuario?
¿Puede probar qué sucedió?
¿Puede ser auditado después de que la tarea se complete?

Estas preguntas no son opcionales en entornos empresariales.

A2A facilita la colaboración de agentes. También crea nuevos lugares donde la confianza puede romperse.

Por ejemplo:

Un agente malicioso podría malrepresentar sus capacidades.
Un agente comprometido podría solicitar contexto sensible.
Una tarea delegada podría exceder la autoridad del usuario.
Un agente podría devolver artefactos envenenados.
Una cadena de agentes podría hacer que la responsabilidad sea poco clara.
Los datos sensibles podrían fluir a través de límites sin el registro adecuado.

Es por eso que los sistemas serios de A2A necesitan más que cumplimiento del protocolo.

Necesitan:

Identidad de agente fuerte
Autorización con alcance
Registros de auditoría a nivel de tarea
Rastreo de delegación
Aprobación humana para acciones riesgosas
Procedencia de artefactos
Límites de tasa
Aplicación de políticas
Observabilidad a través de los límites de los agentes

A2A no es una arquitectura de seguridad por sí mismo; es un protocolo de comunicación que debe desplegarse dentro de una, con decisiones explícitas tomadas sobre identidad, autorización, auditoría y aplicación de políticas en cada límite que cruza.

A2A y la idea de un mercado de agentes

Uno de los casos de uso a largo plazo más interesantes de A2A son los mercados de agentes.

Si los agentes pueden anunciar capacidades a través de Tarjetas de Agente, entonces otros agentes o plataformas pueden descubrirlos, evaluarlos y enviar tareas.

Eso crea un futuro posible donde las capacidades de los agentes se vuelven más modulares:

Un agente de impuestos
Un agente legal
Un agente de revisión de código
Un agente de planificación de viajes
Un agente de análisis de seguridad
Un agente de compras
Un agente de calidad de datos

Cada uno podría exponer una interfaz estándar para la colaboración basada en tareas.

Esto suena emocionante, pero también es donde el entusiasmo excesivo se vuelve peligroso.

Un mercado de agentes abierto requiere más que Tarjetas de Agente. Necesita identidad, reputación, facturación, cumplimiento, sandboxing, responsabilidad, versionado y resolución de disputas.

Sin eso, un mercado de agentes se convierte en un incidente de seguridad esperando suceder.

A2A es un bloque de construcción útil para este tipo de futuro, pero es una pieza de un rompecabezas mucho más grande que también requiere sistemas de identidad, mecanismos de reputación, infraestructura de facturación, controles de cumplimiento y resolución de disputas antes de que se vuelva un mercado seguro para operar.

A2A para agentes empresariales internos

El caso de uso a corto plazo más realista no son los mercados de agentes públicos.

Son las redes de agentes empresariales internos.

Las grandes organizaciones ya tienen muchos límites:

Equipos
Departamentos
Sistemas
Proveedores
Dominios de datos
Zonas de cumplimiento
Políticas de seguridad
Procesos de aprobación

A2A se mapea naturalmente sobre estos límites, porque el protocolo está diseñado alrededor de la misma necesidad fundamental: comunicación estructurada entre sistemas que tienen su propia propiedad y no comparten un código fuente. El clúster más amplio de Sistemas de IA cubre cómo los agentes especialistas como Hermes y OpenClaw encajan en este tipo de arquitectura en capas en la práctica.

En lugar de construir un asistente gigante con acceso directo a todo, una empresa puede construir agentes especialistas con responsabilidad limitada:

Agente de RRHH
Agente financiero
Agente de soporte
Agente de DevOps
Agente de seguridad
Agente de gestión del conocimiento
Agente de plataforma de datos

Cada agente puede poseer sus herramientas y políticas internamente. Otros agentes pueden interactuar con él a través de A2A.

Este es un modelo mucho mejor que dar a un solo agente de propósito general acceso directo a cada sistema en la organización, tanto desde una perspectiva de seguridad como operativa. Cada agente especialista puede ser propiedad, operado, auditado y asegurado de manera independiente, lo que también hace que el sistema general sea más fácil de razonar cuando algo sale mal.

A2A para equipos pequeños e Indie Hackers

Para equipos pequeños que construyen productos con uno o dos agentes, A2A es genuinamente menos urgente y, a menudo, una distracción de problemas más inmediatos. Probablemente no necesite un protocolo de agente a agente todavía.

Use código normal. Use APIs HTTP. Use colas. Use MCP donde la integración de herramientas importa.

Agregue A2A cuando realmente tenga:

Múltiples agentes independientes
Límites de agentes de terceros
Tareas delegadas de larga duración
Requisitos de descubrimiento de agentes
Requisitos de intercambio de artefactos
Necesidades de interoperabilidad entre marcos de trabajo

La secuencia importa más que la ambición. Comience con la arquitectura más simple que exponga los puntos de presión reales, y deje que esos puntos de presión le digan si realmente necesita A2A antes de comprometerse con la complejidad que trae. Para la mayoría de los pequeños constructores, MCP primero y A2A después es el camino correcto.

Un marco de decisión práctico

Use este marco al decidir si A2A pertenece en su sistema.

No A2A cuando el flujo de trabajo es local. Evite A2A cuando todo se ejecuta dentro de una aplicación y los componentes no son desplegable independientemente. Una función Python, clase, servicio, cola o motor de flujo de trabajo probablemente sea suficiente.

MCP cuando el agente necesita herramientas. Use MCP cuando su agente necesite acceso estandarizado a archivos, bases de datos, APIs, sistemas SaaS, índices de búsqueda, repositorios, documentación interna o sistemas de observabilidad. MCP da un valor práctico inmediato y es el punto de partida correcto para la mayoría de los equipos que construyen agentes hoy.

A2A cuando el agente necesita pares. Use A2A cuando su agente necesite comunicarse con otros agentes independientes; especialmente cuando esos agentes tienen sus propias capacidades, políticas, estado, herramientas, dueños, ciclo de vida de despliegue y límite de seguridad.

Ambos cuando la arquitectura tiene capas. Use ambos cuando los agentes especialistas colaboran entre sí y cada especialista también necesita herramientas. El patrón de producción es A2A entre agentes y MCP entre agentes y herramientas. Esa es la versión más sensata de la pila de protocolos de agentes de 2026, y la arquitectura que se mapea más limpiamente sobre cómo los sistemas multi-agente de producción realmente se están construyendo.

Errores comunes con A2A

Usar A2A porque suena estratégico. Esta es la trampa clásica de la arquitectura empresarial. A2A debería resolver un problema de límite real que exista en la arquitectura, no uno inventado para justificar la elección del protocolo. Si no hay un límite genuino; sin despliegue independiente, sin propiedad separada, sin perímetro de seguridad distinto; probablemente no haya necesidad de A2A.

Tratar a MCP y A2A como competidores. MCP no está obsoleto porque A2A existe, y A2A no es innecesario porque MCP existe. Abordan problemas estructurales diferentes y funcionan mejor como capas complementarias, no como alternativas competitivas.

Exponer cada capacidad como un agente. Una calculadora no necesita ser un agente. Una API del clima no necesita ser un agente. Una consulta de base de datos no necesita ser un agente. Muchas cosas son herramientas straightforward, y la abstracción del agente añade sobrecarga sin añadir claridad cuando se aplica a componentes que no tienen autonomía, estado o ciclo de vida significativos propios.

Ocultar un agente completo detrás de una sola herramienta. El error opuesto también es común. Si una “herramienta” tiene su propio ciclo de vida de tareas, memoria, políticas, artefactos y comportamiento de delegación, quizás merezca ser modelada como un agente en lugar de ser apretada detrás de un límite de llamada a función.

Ignorar la observabilidad. Los sistemas multi-agente sin trazas son dolorosos de depurar e imposibles de auditar. Necesita saber qué agente recibió la tarea, qué mensajes fueron intercambiados, qué herramientas fueron llamadas, qué artefactos fueron producidos, qué políticas fueron aplicadas y qué agente tomó la decisión final. Sin esa visibilidad, la depuración se convierte en arqueología; reconstruir qué sucedió por inferencia en lugar de observación. La pila completa de observabilidad para sistemas respaldados por IA y LLM, incluyendo métricas, trazas distribuidas y SLOs que abarcan límites de agentes, se cubre en Observabilidad para Sistemas LLM: Métricas, Trazas, Registros y Pruebas en Producción.

Entonces, ¿A2A tiene un entusiasmo excesivo?

Sí, en parte. A2A tiene un entusiasmo excesivo cuando se presenta como el predeterminado inevitable para todos los sistemas de agentes de IA, cuando las personas implican que cada desarrollador necesita adoptarlo inmediatamente, cuando las demostraciones de agentes usan A2A para coordinar lo que podría haber sido tres llamadas a funciones, o cuando la discusión del protocolo ignora la identidad, autorización, observabilidad y operaciones de producción. Estos son ejemplos reales de entusiasmo que hacen que A2A suene más universal de lo que es.

Pero tener un entusiasmo excesivo no significa ser inútil. Muchas tecnologías importantes tienen un entusiasmo excesivo antes de convertirse en infraestructura aburrida, y el entusiasmo a menudo llega bien antes de que el ecosistema sea lo suficientemente maduro para apoyarlo. La pregunta real no es si el marketing es excesivo; claramente lo es a veces. La pregunta real es si la abstracción subyacente es útil, y para A2A, la respuesta es sí cuando los agentes se convierten en actores genuinamente independientes en un sistema con límites reales, propiedad real y apuestas reales.

Entonces, ¿A2A está muerto?

No.

El argumento de “A2A está muerto” tenía más sentido durante la fase de escepticismo inicial, cuando el protocolo parecía una respuesta liderada por Google al impulso de MCP.

En 2026, ese argumento es más débil.

A2A tiene una especificación formal, soporte del ecosistema, impulso de la Fundación Linux, atención de grandes nubes y despliegues de producción reportados.

Nada de eso hace que A2A sea dominante, obligatorio o universalmente amado por la comunidad de desarrolladores; pero claramente no está muerto. Una declaración mejor es que A2A está vivo y aún demostrando su valor de producción más allá de los ecosistemas empresariales y de plataformas, donde la mayoría de los despliegues confirmados actualmente residen.

Entonces, ¿A2A es finalmente útil en 2026?

Sí, pero solo en la arquitectura correcta. A2A es útil cuando su sistema tiene límites reales de agentes; no solo porque su código tenga múltiples prompts, o porque su sistema use la palabra “agente” en nombres de variables. Se vuelve útil cuando la colaboración de agentes realmente necesita estructura estándar:

Descubrimiento
Capacidades
Ciclo de vida de tareas
Mensajes
Artefactos
Trabajo de larga duración
Límites de implementación opacos
Interoperabilidad entre proveedores

Es donde A2A gana su lugar, proporcionando un contrato común para la colaboración que de otro modo requeriría trabajo de protocolo personalizado en cada límite.

Mi opinión personal

A2A no es el protocolo con el que la mayoría de los desarrolladores deberían comenzar; MCP sí. MCP resuelve un problema más inmediato y ampliamente aplicable: conectar agentes a herramientas y contexto útil. A2A resuelve un problema de etapa posterior: conectar agentes independientes entre sí a través de límites reales de despliegue y propiedad. Eso hace que MCP sea más útil hoy para la vasta mayoría de desarrolladores individuales y equipos pequeños.

A2A puede volverse más importante a medida que los sistemas de agentes maduran de demostraciones a flujos de trabajo empresariales. Una vez que las organizaciones tienen múltiples agentes especialistas propiedad de diferentes equipos, la necesidad de un límite estándar de agente a agente se vuelve obvia y la sobrecarga del protocolo comienza a pagarse a sí misma.

Mi recomendación práctica es comenzar con MCP, diseñar límites de agentes limpios desde el principio y agregar A2A solo cuando esos límites se conviertan en restricciones reales de despliegue, propiedad o interoperabilidad. No adopte A2A por “vibes”. Adóptelo cuando la arquitectura lo exija.

Veredicto final

El protocolo A2A de Google no está muerto.

Tampoco es el futuro universal de cada proyecto de agente de IA.

Es un protocolo útil, aún en maduración, para un problema específico: la comunicación entre agentes de IA independientes.

Si está construyendo un asistente simple, probablemente A2A sea innecesario.

Si está construyendo un sistema empresarial multi-agente, un mercado de agentes, una red de agentes neutral al proveedor o un conjunto de agentes especialistas desplegados independientemente, A2A merece atención seria.

El mejor encuadre de 2026 no es:

A2A vs MCP

Es:

MCP para herramientas.
A2A para agentes.
Ambos para sistemas multi-agente serios.

Eso es menos dramático que un relato de guerra de protocolos, pero también es más preciso y más útil para los ingenieros que necesitan tomar decisiones arquitectónicas reales.