Una aseguradora quiere que su agente de atención solicite un análisis a un agente antifraude de un socio. Un marketplace debe colaborar con agentes logísticos de varias empresas. Si cada combinación exige SDK, payload y autenticación propios, el ecosistema se convierte en integraciones frágiles.
El 12 de noviembre de 2026, AWS publicó una arquitectura de referencia para sistemas multiagente interoperables con A2A, Agent-to-Agent, entre cuentas, organizaciones y frameworks distintos. El protocolo es un proyecto de Linux Foundation y reutiliza HTTP, JSON-RPC, OAuth 2.0 y OpenID Connect.
Qué resuelve A2A
Estandariza la relación entre un agente cliente que delega y otro remoto que ejecuta. Pueden descubrir capacidades, negociar formatos, crear tareas, transmitir progreso y entregar artefactos. Ninguno necesita conocer el framework, memoria o herramientas internas del otro.
Reduce acoplamiento y permite sustituir proveedor si el nuevo agente cumple el contrato de capacidad, seguridad y resultado.
A2A no es MCP
Son complementarios. MCP conecta un agente con herramientas y contexto: CRM, base de datos, archivos o API. A2A conecta agentes capaces de asumir tareas y mantener estado.
Un agente comercial consulta CRM por MCP. Para un cálculo fiscal, delega por A2A al agente tributario, que usa sus propios conectores sin revelarlos.
Elementos principales
Agent Card
Documento de descubrimiento con identidad, endpoint, capacidades, skills, modalidades y autenticación. Puede vivir en ruta estándar o catálogo privado. Nunca debe incluir secretos.
Tarea
Unidad duradera con identificador, estado, contexto, mensajes y artefactos. Puede terminar en segundos o esperar procesamiento y aprobación.
Mensajes y partes
Transportan texto, datos estructurados o referencias de archivo. El contrato fija esquema, tamaño, clasificación y conservación.
Actualizaciones asíncronas
Streaming y notificaciones siguen tareas largas sin polling agresivo. El cliente gestiona repetición, reconexión y eventos desordenados.
Identidad y permisos
OAuth y OIDC establecen identidad entre dominios. Cada tarea necesita alcance, audiencia, tenant y política de datos.
Arquitectura entre empresas
- El orquestador consulta un catálogo de Agent Cards aprobadas.
- Selecciona capacidad por riesgo, región, coste y SLA.
- Obtiene un token breve sin compartir secretos estáticos.
- Crea tarea con datos mínimos y correlación.
- El agente remoto valida identidad, alcance y esquema.
- Procesa con su framework y herramientas.
- Envía progreso y artefacto verificable.
- El orquestador valida antes de actuar internamente.
Ejemplo: cotización logística
El agente del comercio recibe destino, dimensiones y plazo. Encuentra agentes autorizados y crea tareas en paralelo sin enviar el nombre del cliente.
Cada transportista devuelve precio, plazo, restricciones y validez en formato estructurado. El orquestador aplica política, elige y genera etiqueta con el sistema interno. Si un agente no responde, su tarea caduca sin bloquear al resto.
Seguridad en la frontera
El agente remoto es una dependencia externa. Trata su respuesta como no fiable hasta validarla. No conviertas instrucciones dentro de artefactos en comandos; limita tipos, tamaño y URL; analiza malware y datos personales.
- tokens cortos y audiencia específica;
- mTLS o red privada cuando proceda;
- allowlist de agentes y capacidades;
- minimización y residencia de datos;
- límites de tasa, coste, tiempo y tamaño;
- idempotencia y protección frente a replay;
- hash o firma de artefactos;
- logs correlacionados;
- revocación por socio.
Contratos y compatibilidad
El protocolo normaliza transporte, no significado. Las empresas deben acordar esquema, moneda, zona horaria, estados y errores. Versiona la capacidad y prueba compatibilidad.
Evita campos implícitos y texto natural para automatización. Usa datos estructurados y validación. Los cambios incompatibles necesitan nueva versión y transición.
Observabilidad distribuida
Propaga correlation ID, tenant y trace context sin exponer razonamiento. Registra delegación, Agent Card, versión, latencia, coste, estados y artefactos.
Define SLO de disponibilidad, primera actualización, finalización y error. El diagnóstico debe señalar la frontera responsable.
Cuándo utilizar A2A
- agentes de proveedores o equipos independientes;
- frameworks y despliegues diferentes;
- tareas duraderas o asíncronas;
- el remoto conserva conocimiento y herramientas;
- hace falta descubrimiento y sustitución.
Para una llamada determinista, una API puede ser mejor. Usa A2A cuando exista verdadera capacidad autónoma y ciclo de tarea.
Plan de adopción
- Elige una colaboración con frontera clara.
- Define capacidad, datos, estados y artefacto.
- Publica una Agent Card privada y versionada.
- Configura OAuth/OIDC y autorización por tarea.
- Añade idempotencia, timeout y cancelación.
- Valida entrada y salida.
- Prueba indisponibilidad, replay y versiones.
- Mide SLA, coste e impacto.
Agentes conectados sin otro entramado
A2A permite componer especialistas independientes sin hacer que el orquestador dependa de cada SDK. El valor surge del protocolo abierto, los contratos y la seguridad entre dominios.
ProativaIA crea agentes empresariales, plataformas a medida e integraciones entre sistemas, socios y API. Podemos diseñar Agent Cards, autenticación, orquestación y observabilidad.