AWS conecta tres agentes de IA en dos cuentas mediante el protocolo A2A

Has creado un asistente de IA empresarial con LangChain, mientras que tu proveedor de evaluaciones de seguridad utiliza Strands. Ahora necesitas conectarlos: delegar una tarea, verificar el acceso y explicar al servicio externo qué normas internas se aplican en la organización del cliente. Lo habitual es añadir una capa de integración específica que ambos equipos deben mantener.

AWS ha publicado un ejemplo de esta conexión mediante Agent-to-Agent, o A2A. En él, tres agentes operan en dos cuentas de AWS, intercambian tareas y se solicitan contexto entre sí. El valor práctico del artículo reside en una arquitectura concreta de interacción entre empresas: distintos frameworks, sistemas de identidad independientes y una llamada de retorno al cliente.

Cómo conoce el agente externo las normas de la empresa

Imagina que un directivo pide revisar las cuentas de trabajo de la organización para detectar incumplimientos de los requisitos internos de seguridad. El agente empresarial recibe la consulta y delega la evaluación en el agente del proveedor SaaS. Pero el proveedor no sabe de antemano qué cuentas se utilizan en producción, qué datos se consideran confidenciales ni a quién avisar si hay problemas.

Por eso, el agente externo contacta con un tercer participante: un agente interno de contexto. Este facilita información sobre las cuentas, las políticas aplicables y los contactos a los que escalar los problemas. Una vez recibido el contexto, el agente SaaS completa la evaluación y devuelve el resultado al orquestador empresarial, que prepara la respuesta para el usuario.

Por ejemplo, una cuenta de producción podría tener prohibido el almacenamiento público, mientras que los datos confidenciales podrían requerir cifrado en reposo. La empresa establece estas normas. El proveedor obtiene la información necesaria mediante una interfaz acordada y la utiliza para realizar su tarea.

En la demostración, los datos sobre incumplimientos son sintéticos. Los autores describen la conexión real con AWS Config, Security Hub o GuardDuty como un siguiente paso para un sistema en producción. Por tanto, el ejemplo muestra cómo organizar la interacción, pero no demuestra la calidad de una auditoría de seguridad automatizada.

Qué estandariza exactamente A2A

Al iniciarse, el orquestador carga la Agent Card del agente externo, que describe sus capacidades. A partir de las habilidades publicadas, crea herramientas de LangChain y el modelo selecciona la adecuada según la pregunta del usuario. Esta arquitectura no exige definir una ruta específica para cada pregunta.

La tarjeta del agente SaaS publica una única capacidad funcional de evaluación del cumplimiento. Las herramientas internas, el prompt del sistema y la elección del modelo quedan en manos del proveedor. Este puede modificar la implementación siempre que mantenga la compatibilidad de la tarjeta y de la interfaz A2A externa.

Para un equipo de producto, esto establece un reparto útil de responsabilidades: el cliente se integra con una capacidad del servicio y el proveedor desarrolla su funcionamiento interno de forma independiente. Sin embargo, sigue siendo necesario mantener la compatibilidad de la interfaz: el protocolo no elimina los acuerdos sobre el comportamiento y el resultado de la tarea.

En esta arquitectura, A2A también desempeña una función distinta de la de MCP. Mediante MCP, un agente puede conectar sus propias herramientas y fuentes de datos. Mediante A2A, delega trabajo en otro agente. Un mismo servicio puede utilizar ambos protocolos: MCP internamente y A2A para interactuar con el cliente.

Hasta dónde llega el ejemplo listo para usar

Cada parte utiliza su propio grupo de usuarios de Amazon Cognito. Durante la incorporación del cliente, las empresas intercambian parámetros públicos: direcciones, identificadores de cliente y ámbitos de acceso. No se transmiten secretos entre ellas, aunque cada parte sí dispone de secretos para obtener tokens y los almacena en Secrets Manager.

La llamada de retorno solo se permite a la dirección registrada durante la incorporación del cliente. Antes de realizar la solicitud, el agente SaaS comprueba la tarjeta del agente interno. Es un detalle relevante: la dirección de destino se establece en la configuración de la integración y no mediante texto arbitrario incluido en una tarea entrante.

El despliegue se divide en tres cuadernos de Jupyter. Los autores estiman que las etapas requieren unos 3, 5 y 20 minutos; preparar las cuentas y los permisos exige tiempo adicional. La infraestructura tiene coste y algunos recursos funcionan de forma continua, entre ellos una puerta de enlace NAT, tareas de Fargate y un balanceador de carga.

A los desarrolladores les conviene estudiar este ejemplo si su agente debe trabajar con servicios de socios o de distintos equipos internos. Se puede empezar con un único escenario: delegar una tarea en un agente externo, permitir una solicitud limitada de contexto y comprobar todo el recorrido con los tokens de ambas partes. AWS ha explicado esta parte con suficiente detalle concreto como para utilizar el material como base de un prototipo propio.