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

El A2A no está muerto. Solo 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, 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 limpia que el anuncio.

Algunos desarrolladores vieron en A2A la capa faltante 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 el mercado 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 era 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 valioso 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 integración de herramientas y 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 hype 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 frameworks, 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 se acerca más al trabajo de MCP, el Protocolo de Contexto de Modelo (Model Context Protocol). A2A se trata de 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 (input-required)
Recibir artefactos finales
Rastrear finalización, fallo 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 hasta la ejecución, las actualizaciones de estado y 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. Para saber cómo funcionan el streaming, las notificaciones push y las pausas con intervención humana en producción, consulte Streaming y Tareas Asíncronas de A2A para Flujos de Trabajo de Agentes de Larga Duración.

Por qué A2A fue fácil de burlar

A2A llegó a un mercado ya ahogado en siglas de agentes.

Para 2025, los desarrolladores ya lidiaban con:

APIs de LLM
Llamadas a funciones (Function calling)
Llamadas a herramientas (Tool calling)
Frameworks de agentes
Servidores MCP
Pipelines RAG
Motores de flujos de trabajo
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 venía de varias direcciones a la vez. A2A parecía superponerse con MCP. Venía 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 Linux Foundation informó que el proyecto A2A había superado las 150 organizaciones de apoyo, ganó integraciones en plataformas de nube principales y alcanzó despliegues en producción en múltiples industrias.

Esto 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 siente 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 de nube y un ecosistema en crecimiento alrededor de la interoperabilidad de agentes. Eso hace que la etiqueta de “muerto” sea difícil de defender desde puntos de vista 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 hype.

A2A vs MCP: La Confusión Que No Quería Morir

La mayor parte 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 se ve muy agéntico; por ejemplo, una herramienta MCP llamada research_company que internamente ejecuta búsqueda, recuperación, resumen, clasificación y escritura de informes. Desde el punto de vista del host MCP, es una herramienta. Desde un punto de vista arquitectónico, está ocultando un flujo de trabajo tipo 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 de agentes
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, política, ciclo de vida y autoridad de toma de decisiones propia 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 apilada:

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 marco al que la mayoría de los arquitectos de agentes serios están convergiendo. 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 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 de forma independiente
Propiedad de diferentes equipos
Construidos con diferentes frameworks
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 el trabajo a:

Un agente de compras
Un agente de revisión legal
Un agente de finanzas
Un agente de cumplimiento
Un agente de investigación de mercado
Un agente de escritura 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, repositorio 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 apilado 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 Sobredimensionado

A2A está sobredimensionado 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, A2A probablemente sea innecesario.

Es posible que necesite:

MCP
Esquemas de herramientas buenos
Barreras de protección (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 base
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 una cola sería más simple
El equipo no puede operar la complejidad extra

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

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

A2A Y El Problema De Google

Parte del escepticismo sobre 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 del todo justa con el diseño técnico de A2A, pero es un factor real de adopción.

La historia de alojamiento en la Linux Foundation ayuda aquí. Que A2A se vuelva 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 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 ser juzgado 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 más fácil evaluar los méritos técnicos de A2A 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 una 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 soporta el estándar, lo que puede reflejar una implementación genuina, posicionamiento estratégico, un prototipo o simplemente apoyo planificado que no se ha materializado. Ligeramente más fuerte es la adopción de SDK, 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 los ingenieros reales han encontrado que vale su tiempo. Aún más fuerte es la adopción de plataforma, donde las nubes, los frameworks 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 a largo plazo del ecosistema es la retención en producción. Para tener una idea de cómo se ven realmente las curvas de adopción en el espacio de agentes de IA —medidas en estrellas de GitHub, tokens de OpenRouter y tendencias de descarga— los datos de popularidad de OpenClaw vs Hermes Agent muestran qué tan rápido se construye y se estanca el impulso una vez que disminuye la energía de los primeros adoptadores: equipos que dependen del protocolo para flujos de trabajo en vivo más allá de la luna de miel inicial de 90 días. La actualización de 2026 de la Linux Foundation afirma uso en 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 a 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 hype de los desarrolladores es barato, y la retención en producción es costosa. Los dos rara vez son proporcionales, que es por qué la pregunta de retención de 90 días importa más que el entusiasmo de la semana de lanzamiento.

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

Problemas de autenticación
Problemas de autorización
Problemas de identidad de agente
Problemas de depuración
Casos límite 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

Es aquí donde muchos frameworks 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 en 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 usan en demostraciones mientras los sistemas de producción vuelven a APIs y colas personalizadas.

La Seguridad Es La Pregunta Más Grande Sin Resolver

Los problemas más difíciles de A2A no son problemas de sintaxis o especificación. Son problemas de confianza que emergen 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 lo posee?
¿Qué está permitido saber?
¿Qué 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 quede poco clara.
Datos sensibles podrían fluir a través de límites sin el registro adecuado.

Por eso, los sistemas serios de A2A necesitan más que cumplimiento del protocolo.

Necesitan:

Identidad de agente fuerte
Autorización con alcance (scoped)
Registros de auditoría a nivel de tarea
Seguimiento de delegación
Aprobación humana para acciones arriesgadas
Proveniencia de artefactos
Límites de tasa
Cumplimiento 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 cumplimiento de políticas en cada límite que cruce. Seguridad de Agentes A2A y MCP: Identidad, Delegación y Huellas de Auditoría detalla esa arquitectura circundante.

A2A Y La Idea De Mercado De Agentes

Uno de los casos de uso de A2A a largo plazo más interesantes 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 enviarles 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 hype se vuelve peligroso.

Un mercado de agentes abierto requiere más que Tarjetas de Agente. Necesita identidad, reputación, facturación, cumplimiento, aislamiento (sandboxing), responsabilidad, versionamiento 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 redes internas de agentes empresariales.

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 base. El clúster más amplio de Sistemas de IA cubre cómo los agentes especialistas como Hermes y OpenClaw se ajustan a este tipo de arquitectura apilada 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 de finanzas
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 poseído, operado, auditado y asegurado de forma independiente, lo que también hace que el sistema general sea más fácil de comprender cuando algo sale mal.

A2A Para Pequeños Equipos Y Indie Hackers

Para pequeños equipos 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 aún.

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

Añada 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 frameworks

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 más tarde es el camino correcto.

Un Marco De Decisión Práctico

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

Sin 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 de forma independiente. Una función Python, clase, servicio, cola o motor de flujos 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 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 tengan sus propias capacidades, políticas, estado, herramientas, propietarios, 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 realmente se están construyendo los sistemas multi-agente en producción.

Errores Comunes Con A2A

Usar A2A porque suena estratégico. Este es el clásico error 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 competidoras.

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 (directas), y la abstracción de 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, podría merecer 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 se intercambiaron, qué herramientas se llamaron, qué artefactos se produjeron, qué políticas se aplicaron 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 basados en IA y LLM, incluidas 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, ¿Está A2A Sobredimensionado?

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

Pero sobredimensionado no significa inútil. Muchas tecnologías importantes están sobredimensionadas antes de convertirse en infraestructura aburrida, y el hype a menudo llega bien antes de que el ecosistema esté lo suficientemente maduro para soportarlo. 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 vuelven actores genuinamente independientes en un sistema con límites reales, propiedad real y stakes (intereses/apuestas) reales.

Entonces, ¿Está A2A Muerto?

No.

El argumento de “A2A está muerto” tenía más sentido durante la fase inicial de escepticismo, 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, apoyo del ecosistema, impulso de la Linux Foundation, atención de grandes nubes y despliegues en 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 en producción más allá de los ecosistemas empresariales y de plataforma, que es donde viven la mayoría de los despliegues confirmados actualmente.

Entonces, ¿Está A2A Finalmente Útil En 2026?

Sí, pero solo en la arquitectura correcta. A2A es útil cuando su sistema tiene límites de agentes reales; 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 genuinamente 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

Ese es donde A2A gana su lugar, al proporcionar un contrato común para la colaboración que de otra manera 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í lo es. MCP resuelve un problema más inmediato y de aplicación más amplia: conectar agentes a herramientas y contexto útiles. 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 a MCP más útil hoy para la vasta mayoría de los desarrolladores individuales y pequeños equipos.

A2A puede volverse más importante a medida que los sistemas de agentes maduren desde demostraciones hasta flujos de trabajo empresariales. Una vez que las organizaciones tengan 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 por sí misma.

Mi recomendación práctica es comenzar con MCP, diseñar límites de agentes limpios desde el principio y añadir A2A solo cuando esos límites se conviertan en restricciones reales de despliegue, propiedad o interoperabilidad. No adopte A2A por “vibes” (sensaciones/impresiones). 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: comunicación entre agentes de IA independientes.

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

Si está construyendo un sistema empresarial multi-agente, un mercado de agentes, una red de agentes neutral a proveedores o un conjunto de agentes especialistas desplegados de forma independiente, A2A merece una 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 una narrativa 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.