Protocolo A2A 1.2 en producción: Qué los arquitectos de la…
Cloud Next 2026: A2A 1.2 en producción en 150+ organizaciones. Cómo el protocolo de agente interactúa con Istio/Linkerd existente.
En Google Cloud Next 2026, el 22 de abril, Google ha puesto en producción el protocolo Agent2Agent (A2A) en versión 1.2 como proyecto de la Linux Foundation. 150 organizaciones ya utilizan A2A en producción, entre ellas Microsoft, AWS, Salesforce, SAP y ServiceNow. Existe soporte nativo en Google Agent Development Kit, LangGraph, CrewAI, LlamaIndex Agents, Semantic Kernel y AutoGen. Para los arquitectos de la nube en DACH (Alemania, Austria y Suiza), surge una pregunta que desde el anuncio inicial de A2A el año pasado solo era teórica: ¿Necesita A2A su propia capa de infraestructura además del Service Mesh existente, o encaja en el modelo Sidecar actual?
- A2A 1.2 en Cloud Next 2026 (22.04.2026) en producción, proyecto de Agentic AI de la Linux Foundation, tarjetas de agente firmadas con verificación de dominio.
- A2A complementa a MCP (Model Context Protocol), no lo reemplaza: MCP = Agente a Herramienta, A2A = Agente a Agente a través de límites organizativos y de plataforma.
- Istio y Linkerd siguen siendo las opciones principales de Service Mesh para mTLS, gestión de tráfico y políticas L7; A2A funciona por encima como protocolo de capa de aplicación, no en paralelo.
- La integración funciona correctamente mediante el modelo Sidecar existente, pero requiere tres ajustes: servicio de tarjetas de agente, validación de firmas y rastro de auditoría de delegación.
- Para la PYME de DACH con una infraestructura Istio existente, la integración es realista en ocho a doce semanas, sin reemplazar el Mesh.
Lo que A2A realmente es técnica
¿Qué es el protocolo Agent2Agent (A2A)? A2A es un protocolo de aplicación abierto basado en HTTP/JSON para la comunicación entre agentes de IA autónomos de diferentes proveedores. Define estándares para Agent-Cards (metadatos, capacidades, endpoints), delegación de tareas, devolución de resultados y verificación de firmas. A2A 1.2 introduce Agent-Cards criptográficamente firmadas con enlace de dominio, permitiendo que un agente de Salesforce pueda autenticamente reconocer a un agente Google-Vertex sin que ambos sistemas se conozcan internamente. El protocolo está bajo el paraguas de la Linux Foundation Agentic AI Foundation desde Cloud Next 2026.
La propiedad arquitectural crucial: A2A funciona en la capa 7, es decir, por encima de la capa de Service Mesh. Una configuración clásica de Istio (mTLS, Envoy-Sidecar, Control-Plane) permanece completamente intacta. A2A utiliza la conexión TLS que proporciona el Mesh; sobre esta descansa la propia cadena de firma. Quien entienda A2A como competencia para Service Mesh, está interpretando mal el protocolo. A2A es una abstracción de capa de aplicación para interoperabilidad de agentes, no una alternativa de capa de transporte.
Un breve vistazo a las notas de lanzamiento de A2A 1.2: las Agent-Cards firmadas contienen un Agent-DID (Identificador Descentralizado) vinculado al dominio. La cadena de firma se valida a través de registros DNS-TXT o mediante un Well-Known-Endpoint. En la práctica, esto significa que un agente A2A propio debe proporcionar una Agent-Card públicamente accesible, cuya firma está contrasignada con una clave de dominio. Quien opera DNSSEC y un Well-Known-Endpoint ya tiene el requisito técnico en su estándar corporativo.
La diferencia con MCP que la mayoría de las rondas de arquitectura pasan por alto
El Model Context Protocol (MCP) de Anthropic, establecido desde 2024, describe la interfaz entre un agente individual y herramientas externas o fuentes de datos. Por el contrario, A2A regula la comunicación entre dos agentes, incluso a través de límites de plataforma y organización. Un escenario típico: un agente de Salesforce en Agentforce recibe a través de A2A una tarea de un agente Vertex-AI, consulta a través de MCP una herramienta CRM interna, devuelve el resultado mediante A2A. Ambos protocolos se complementan. Quien planifique uno sin el otro generará costes de integración innecesarios.
Tres números para contextualizar
Integración en la malla de servicios existente: tres decisiones arquitectónicas
La pregunta práctica que actualmente domina la agenda en las reuniones de arquitectura DACH (Alemania, Austria y Suiza) es: ¿cómo integrar A2A (Application-to-Application) en una configuración existente de Istio o Linkerd sin romper el diseño de la malla? Tres decisiones específicas deben tomarse.
Decisión 1: Separar el servicio de tarjetas de agente o integrarlo en el descubrimiento de servicios existente
A2A requiere un endpoint de tarjetas de agente accesible por cada agente publicado. Desde el lanzamiento de la versión 1.0, se han establecido dos patrones. En primer lugar, un servicio dedicado de tarjetas de agente como implementación propia detrás del Ingress, con su propio almacenamiento en caché y su propia política de límite de tasa. En segundo lugar, la integración de la tarjeta de agente en el descubrimiento de servicios existente (Consul, Istio Workload Entries), donde la tarjeta se incluye como atributo de metadatos. Nuestra experiencia: el servicio separado es más limpio de operar y auditar, ya que aísla los patrones de acceso. Para una implementación Greenfield, recomendamos el servicio separado; para entornos brownfield con una fuerte presencia de Consul, la solución de metadatos es suficiente.
Decisión 2: Validación de firmas en el sidecar o en el runtime del agente
A2A 1.2 incluye tarjetas de agente firmadas criptográficamente. La validación de la firma puede realizarse ya sea en el Envoy-Sidecar mediante un filtro Lua o un plugin WASM, o directamente en el runtime del agente a través del SDK oficial de agente. Para configuraciones de alto rendimiento (más de 200 llamadas de agente por segundo por servicio), recomendamos la variante de sidecar, ya que gestiona uniformemente el calentamiento de caché y las listas de revocación. Para configuraciones experimentales y de tamaño medio, la variante de runtime es más simple y rápida de implementar. Importante: quien elija la validación de sidecar debe sincronizar la CRL (Certificate Revocation List) de tarjetas de agente con el ciclo de actualización de la malla. De lo contrario, las tarjetas revocadas llegarán con retraso al sistema, lo que falsifica las pistas de auditoría.
Decisión 3: Pista de auditoría de delegaciones en SIEM o dedicada
La delegación de agente a agente genera una pista de auditoría que no es completamente visible en los registros de acceso clásicos de Istio. Para los requisitos de cumplimiento (DORA, NIS2, Ley de IA de la UE), la pista de delegación es un artefacto de auditoría separado: ¿qué agente le ha pasado qué tarea a qué agente, con qué justificación, qué resultado y qué tiempo de ejecución? Vemos dos patrones en la práctica. En primer lugar, exportación a SIEM a través de una pipeline de eventos A2A dedicada (tema de Kafka más analizador). En segundo lugar, una herramienta de observabilidad de agente dedicada (Arize, Helicone, LangSmith). Para sectores regulados, la exportación a SIEM suele ser obligatoria, mientras que la herramienta de observabilidad funciona en paralelo para el análisis de rendimiento. Ambas juntas cuestan en las empresas de tamaño medio realísticamente entre 15.000 y 35.000 euros al año, dependiendo del volumen de transacciones.
Qué significa esto para la hoja de ruta de arquitectura
Para los arquitectos de DACH, las tres decisiones resultan en una hoja de ruta concreta de ocho a doce semanas. Semana uno a tres: inventario de agentes existentes e identificación de los primeros casos de uso de integración (normalmente un agente de asistente más un agente de sistema). Semana cuatro a seis: servicio de tarjeta de agente como implementación separada, configuración de registro DNS-TXT para cadena de firma, integración SDK en el agente de destino. Semana siete a nueve: activar validación de sidecar o validación en tiempo de ejecución, pruebas de carga, pipeline de observabilidad. Semana diez a doce: exportación SIEM, revisión de rastro de auditoría, liberación productiva. Quien termine antes, tiene un caso de uso muy simple o ha hecho concesiones en la documentación de cumplimiento.
Qué realmente cambia en el día a día de las operaciones Mesh propias
La pregunta operativa más interesante para los arquitectos de nube de DACH no es «¿necesito A2A?», sino «¿qué cambia en la realidad operativa de mi Mesh cuando introduzco A2A?». Tres observaciones de los primeros proyectos de integración. En primer lugar, la latencia de la Control-Plane aumenta ligeramente (tres a siete por ciento), porque la validación de firma produce escrituras adicionales en caché. En segundo lugar, los plugins Envoy-WASM necesitan más revisión que los filtros Lua clásicos, porque la semántica de A2A es compleja y las correcciones de errores pueden tardar de dos a tres días. En tercer lugar, el equipo de Observabilidad recibe una nueva clase de eventos (Agent-Delegation-Events), que debe integrarse en los dashboards existentes. Quien no planifique esto proactivamente, al final tendrá dos superficies de Observabilidad paralelas.
Un conjunto concreto de recomendaciones de las revisiones: ejecute la primera producción A2A al menos tres semanas en modo Shadow antes de que el tráfico real se reenvíe. Shadow-Mode significa que las llamadas reales de los agentes se procesan en paralelo, pero las respuestas no se reenvían a la lógica de la aplicación. Así, el equipo detecta regresiones en el formato de respuesta, el manejo de firmas y la latencia, sin riesgo de impacto en el negocio. Estas tres semanas dan sus frutos en casi todos los casos, porque las regresiones se hacen visibles temprano, antes de convertirse en un problema en la aceptación productiva.
Una mirada honesta al grado de madurez
Aunque A2A 1.2 está en producción, el protocolo no está completo. Faltan componentes que esperamos en los próximos 18 meses: límites de tasa estandarizados para llamadas cross-org, un mecanismo de rollback para delegaciones defectuosas, reglas de gobernanza más claras para la revocación de Agent-Card. Quien introduzca A2A hoy, debe planificar estas lagunas como sus propios módulos adicionales. La buena noticia: La gobernanza de la Linux Foundation ha publicado la hoja de ruta de forma clara; los miembros activos (Google, Microsoft, AWS, Salesforce, SAP, ServiceNow) se han comprometido a proporcionar actualizaciones de hoja de ruta trimestralmente. Esto es más disciplina de gobernanza de la que se vio en la mayoría de otros estándares de IA en 2025.
El Reife-Check en tres preguntas antes de la introducción: ¿Es el propio primer caso de uso un escenario Intra-Org (dos agentes propios) o ya Cross-Org (agente de partner)? ¿Cuánta presión regulatoria actúa sobre la delegación (bancos, aseguradoras, sector público son aquí significativamente más sensibles que la industria)? ¿Está el equipo existente de Mesh-Ops listo para operar plugins de sidecar y gestionar el ciclo de vida del certificado A2A? Quien pueda responder claramente las tres preguntas, tiene la base para una introducción limpia. Quien dude en alguna de las preguntas, debería comenzar con una prueba de concepto y no con un despliegue productivo.
Tres suposiciones incorrectas que aparecen regularmente en los primeros proyectos
La primera suposición incorrecta se refiere a la separación con MCP: muchos equipos asumen que A2A se encarga de la integración de herramientas. Esto no es técnicamente correcto. A2A describe exclusivamente Agente-a-Agente, cada integración de herramientas funciona sin cambios a través de MCP o llamadas API directas. Quien en la ronda de arquitectura no dibuje claramente esta separación, producirá en tres meses dos capas de protocolo superpuestas, que cada una solo cubre la mitad de las interacciones.
La segunda suposición incorrecta se refiere a los costos de rendimiento: muchos equipos calculan un recargo lineal por llamada de agente y dimensionan la infraestructura en consecuencia. En la práctica, el sobrecosto es sublineal, porque el almacenamiento en caché de firmas y el agrupamiento de conexiones generan efectos de escala. Quien dimensione la infraestructura desde el principio para el peor caso lineal, pagará un 20 a 30 por ciento de más durante los primeros seis meses.
La tercera suposición incorrecta se refiere a la gobernanza: muchas organizaciones creen que la firma de Agent-Card proporciona automáticamente cumplimiento. Proporciona la base técnica, pero la aprobación organizativa (¿Quién puede firmar Agent-Cards? ¿Qué procesos existen en caso de revocación de una tarjeta?) debe construirse en paralelo. Sin estos procesos, la firma es un sello que nadie supervisa. Para las organizaciones de DACH que operan en sectores regulados, recomendamos definir la capa de gobernanza incluso antes de la introducción técnica, para que la primera liberación productiva no se convierta en un cuello de botella en la auditoría.
Preguntas frecuentes
¿A2A requiere necesariamente Istio o Linkerd?
No. A2A es agnóstico respecto a Mesh y funciona en cualquier infraestructura basada en HTTP. Un Mesh simplifica la perspectiva operativa (mTLS, Observabilidad, Policy-Enforcement) y reduce el esfuerzo de integración, pero no es un requisito. Para configuraciones Kubernetes cloud-natives, recomendamos el Mesh. Para empresas heredadas con AKS/EKS sin Mesh, A2A funciona igualmente a través de Ingress estándar.
¿Cuáles son los costos de rendimiento de la validación de firmas de A2A en el Sidecar?
Con el plugin Envoy-WASM y un buen caché, calculamos una latencia adicional de 2 a 5 milisegundos por llamada, con menos de 1 milisegundo en caché caliente. Esto es problemático en casi todos los escenarios empresariales. Para trading en tiempo real o juegos de baja latencia, la validación en tiempo de ejecución sería la mejor opción, ya que solo se activa cuando es necesario.
¿Cómo se posiciona A2A en relación con el Acta de IA de la UE?
El Acta de IA de la UE exige transparencia y trazabilidad en sistemas autónomos. A2A proporciona con Agent-Cards firmadas y Delegations-Audit-Trail dos de los cuatro componentes obligatorios. Las partes faltantes (identificación de modelo y documentación de salida) están a nivel MCP y en el agente de aplicación. Quien instrumente correctamente A2A más MCP, cubre aproximadamente el 70% de los requisitos de documentación del Acta de IA.
¿Cuál es el coste realista de una implementación de A2A?
Para un contexto de PYME con configuración Istio existente, calculamos entre 40.000 y 90.000 euros en el primer proyecto, dependiendo de la complejidad del caso de uso y del número de agentes. Los escenarios multiorganización con varios partners suelen duplicar este coste, porque se añaden gobernanza y aspectos contractuales.
¿Qué riesgos tiene una delegación A2A multiorganización?
Los tres riesgos principales: inyección de prompts a través del agente externo, fugas de datos a través del payload de tareas y escalada de privilegios en la cadena de delegación. Las contramedidas: saneamiento de entrada antes de la llamada al agente, política estricta de clasificación de datos para los contenidos del payload y una profundidad máxima de delegación en el runtime del agente. Los tres están documentados en la implementación de referencia oficial de A2A y no deberían omitirse en la propia implementación.
Red: Siga leyendo en cloudmagazin
- Análisis sobre el impulso de Commvault-Clumio en Cloud Next 2026
- Verificación de hechos sobre los cambios en precios de GCP y condiciones CUD en abril de 2026
- Arquitecturas en el ámbito Multi-Cloud 2026 y plataformas broker
Fuente imagen de portada: Pexels / Christina Morillo (px:1181675)
