Los agentes que operan a través de los límites de una organización necesitan descubrirse entre sí, intercambiar tareas y colaborar sin exponer sus componentes internos ni obligar a ambas partes a usar el mismo framework. AWS ha publicado una arquitectura de referencia que resuelve esto con el protocolo Agent-to-Agent (A2A), que la empresa señala que ahora es un proyecto de la Linux Foundation que AWS apoya. Sin un protocolo así, cada integración entre organizaciones exige código a medida para cada cliente y framework; con A2A, los proveedores independientes de software (ISV) pueden distribuir agentes que interoperan con los frameworks compatibles con A2A que sus clientes ya utilizan.
Aunque el artículo se centra en el caso de los ISV, AWS indica que el mismo patrón sirve para cualquier organización que exponga agentes a socios, clientes o equipos internos con frameworks distintos. Las nuevas capacidades se añaden registrando Agent Cards en el orquestador, sin tocar los agentes en ejecución.
Arquitectura en dos cuentas
El ejemplo desplegado sitúa tres agentes en dos cuentas de AWS: una para la empresa y otra para el proveedor de SaaS. A2A transporta el tráfico entre ellos, autenticado con OAuth en ambas direcciones, y cada cuenta dispone de su propio grupo de usuarios de Amazon Cognito, de modo que cada lado se autentica con su propio proveedor de identidad.
Durante la incorporación solo se intercambian valores públicos: URL de proveedores de identidad, ID de cliente, ámbitos y URL de puntos de conexión. Después, cada lado confía en los tokens emitidos por el grupo de usuarios del otro y ningún secreto cruza el límite. Una vez completada la incorporación, cada solicitud sigue este recorrido: la aplicación empresarial obtiene un token de acceso de su grupo de Cognito y envía una pregunta por HTTPS a una API de usuario en Amazon API Gateway, y luego consulta la respuesta. API Gateway reenvía la solicitud de forma privada, mediante un enlace de VPC y un Network Load Balancer interno, hasta el Enterprise Orchestrator, un agente de LangChain. Cuando su modelo determina que la pregunta requiere un análisis de cumplimiento, el orquestador obtiene su propio token con un secreto de cliente guardado en AWS Secrets Manager y envía una solicitud A2A al agente de cumplimiento de SaaS alojado en el runtime de Amazon Bedrock AgentCore, usando la habilidad que leyó de la Agent Card de ese agente al arrancar. El agente de cumplimiento verifica la Agent Card del agente de contexto empresarial en la URL de devolución de llamada registrada durante la incorporación, obtiene un token del grupo propio del proveedor de SaaS, solicita los metadatos de cuenta, completa el análisis y devuelve el resultado a la aplicación a través del orquestador.
Los agentes
Dos agentes empresariales se ejecutan en Amazon Elastic Container Service (Amazon ECS) con AWS Fargate, dentro de subredes privadas de una Amazon VPC sin direcciones IP públicas. El Enterprise Orchestrator es el punto de entrada para los usuarios: LangChain aporta el framework y las abstracciones de llamada a herramientas, y Amazon Bedrock los modelos de base. El orquestador usa Anthropic Claude Sonnet 4.6. Al arrancar, descarga la Agent Card del agente de SaaS desde su URL conocida y crea una herramienta de LangChain por cada habilidad anunciada, de modo que el modelo elige la herramienta según la pregunta y no hace falta lógica de enrutamiento fija. Envía solicitudes de análisis por A2A con tokens de portador OAuth y resume los resultados para la dirección. Los usuarios llegan a él mediante un punto de conexión de API Gateway que solo acepta tokens del grupo empresarial.
El segundo agente, el Enterprise Context Agent, también usa LangChain, pero funciona con Amazon Nova Lite. Proporciona metadatos internos como reglas de política, clasificación de datos, criticidad del negocio y contactos de escalado, incluidas las rotaciones de guardia. Está construido con el a2a-sdk oficial (AgentCard, AgentExecutor y rutas JSON-RPC conformes a la especificación), fijado a a2a-sdk[http-server]==1.2.2. El agente de SaaS lo alcanza a través de una API de socio de API Gateway que solo acepta el token de devolución de llamada del proveedor.
Del lado del proveedor, el Compliance SaaS Agent se ejecuta en Amazon Bedrock AgentCore en su propia cuenta y está construido con el SDK de Strands Agents. Revisa cuentas de AWS frente a las políticas internas de la empresa, como la prohibición de almacenamiento público en producción y el cifrado en reposo de datos confidenciales. En producción, sus herramientas se conectarían a servicios como AWS Config, AWS Security Hub o Amazon GuardDuty; la demostración usa datos sintéticos que simulan hallazgos en varias cuentas. Antes de analizar, llama de vuelta al agente de contexto para obtener información que solo la empresa posee, lo que convierte a los dos agentes en pares y no en cliente y servidor. La devolución de llamada solo se dirige a la dirección registrada en la incorporación.
La decisión de diseño central es encaminar toda la comunicación entre límites por A2A. La empresa no puede ver las herramientas internas, el prompt del sistema ni el modelo del agente de SaaS, de modo que el ISV puede cambiar su arquitectura interna sin romper las integraciones de los clientes mientras la Agent Card y la interfaz A2A sigan siendo compatibles. La tarjeta publica una única habilidad seleccionada y no los nombres de las herramientas internas. En la tarjeta de ejemplo, esa habilidad es "compliance-scan", la tarjeta declara protocolVersion "0.3.0" y su sección securitySchemes describe un flujo OAuth 2.0 de credenciales de cliente contra el punto de tokens de Cognito del cliente con el ámbito "a2a-enterprise-compliance-saas/invoke". Las tarjetas se sirven en /.well-known/agent-card.json.
AWS también distingue A2A del Model Context Protocol (MCP): MCP conecta un agente con sus propias herramientas y datos en un modelo cliente-servidor, mientras que A2A conecta agentes entre sí como pares. Un agente de SaaS en producción podría usar MCP internamente y A2A externamente, manteniendo constante la interfaz exterior.
Aspectos destacados de la implementación
El orquestador utiliza deliberadamente llamadas httpx simples con JSON-RPC de A2A (método "message/send") sin depender del SDK de Strands; si el ISV cambiara a otro framework compatible con A2A, el lado empresarial seguiría funcionando. Su gestión de tokens falla de forma cerrada y reintenta una vez con una renovación forzada ante un HTTP 401. En el lado de la devolución de llamada, el agente de SaaS verifica la tarjeta de contexto del cliente con un GET anónimo que no sigue redirecciones antes de obtener su propio token; cualquier fallo llega al modelo como el único mensaje "Enterprise context unavailable" mientras los detalles permanecen en los registros del proveedor.
Cada solicitud de tarea A2A lleva un JWT. Amazon Bedrock AgentCore se configura con la URL de descubrimiento del grupo empresarial, un cliente permitido y un ámbito, y valida el JWT en cada solicitud entrante. Los autorizadores JWT de API Gateway restringen la API de socio al token de devolución de llamada del SaaS y la API de usuario al token de la aplicación empresarial. Cada cuenta guarda su secreto de cliente en AWS Secrets Manager, limitado por IAM y una política de recursos a la única carga de trabajo que lo usa. El único punto de conexión sin autenticación es la Agent Card pública del agente de contexto. AWS señala un error de configuración frecuente: un token de credenciales de cliente de Cognito lleva client_id y scope pero no el claim aud, de modo que el autorizador de API Gateway comprueba client_id contra la lista de audiencias, mientras que AgentCore debe configurarse con allowedClients y sin allowedAudience.
Despliegue y pruebas
El sistema se despliega desde tres notebooks de Jupyter que crean cinco pilas de AWS CloudFormation, tres en la cuenta empresarial y dos en la del proveedor de SaaS. El notebook 1 (empresa, unos 3 minutos) crea la identidad empresarial y escribe onboarding-request.json; el notebook 2 (proveedor de SaaS, unos 5 minutos) despliega el agente de cumplimiento y devuelve onboarding-response.json; el notebook 3 (empresa, unos 20 minutos) despliega los agentes empresariales y ejecuta las pruebas. Los archivos de incorporación solo contienen valores públicos. Los requisitos previos incluyen dos cuentas de AWS en us-east-1, us-east-2 o us-west-2, acceso a Anthropic Claude Sonnet 4.6 en ambas y a Amazon Nova Lite en la cuenta empresarial (con el formulario de primer uso de Anthropic enviado), Python 3.10 o posterior con JupyterLab y AWS CLI versión 2 o una instancia de notebook de Amazon SageMaker AI (ml.t3.medium es suficiente), y roles de IAM capaces de crear pilas de CloudFormation. Docker no es necesario en local porque AWS CodeBuild construye las imágenes de contenedor. Los notebooks comprueban el acceso a los modelos de Bedrock antes de desplegar y se detienen en el primer error; las secciones de limpieza quedan detrás de celdas de parada para que Run All no las alcance.
La prueba de extremo a extremo del notebook 3 envía una pregunta por la API de usuario y consulta el estado cada 5 segundos. Solo se supera si la respuesta contiene hallazgos de cumplimiento y un código de rotación de guardia que solo conoce el agente de contexto, y el registro de acceso de la API de socio muestra un 200 del cliente de devolución de llamada del SaaS. Un paso posterior ejecuta siete comprobaciones de límites de confianza enviando tokens incorrectos, ausentes o falsificados a cada puerta; todas deben ser rechazadas con 401. En la ejecución resumida que AWS publicó, el paso de extremo a extremo terminó en 52,5 segundos, las comprobaciones de límites en 1,4 segundos, y el informe cubrió dos cuentas de producción y seis hallazgos con contactos de escalado por cuenta.
Costes, notas de producción y limitaciones
Ejecutar la solución genera cargos: en la cuenta empresarial, los principales recursos siempre activos son una puerta de enlace NAT, dos tareas de Fargate, el Network Load Balancer interno y dos puntos de conexión de VPC de interfaz, mientras que Amazon Bedrock y AgentCore facturan por uso. Para producción, AWS sugiere un runtime por cliente o un frontal que acepte varios proveedores de identidad de clientes, autenticación de cliente basada en claves (private_key_jwt o TLS mutuo) en lugar de secretos, AWS PrivateLink y TLS dentro de la VPC, claves de AWS KMS administradas por el cliente, VPC Flow Logs y registros de acceso del Network Load Balancer, una función de rotación de Secrets Manager y un portal de incorporación autenticado. Las respuestas HTTP 503 intermitentes a través de API Gateway pueden indicar que el balanceo de carga entre zonas está desactivado en el Network Load Balancer interno, ya que cada servicio de ECS ejecuta una sola tarea que puede iniciarse en cualquiera de las dos zonas de disponibilidad.
AWS subraya que el ejemplo debe ejecutarse solo en cuentas de pruebas sin datos de clientes ni de negocio, que usa exclusivamente datos sintéticos y que no evalúa ni certifica el cumplimiento de ninguna ley, regulación o norma. Sus controles incluyen HTTPS en cada llamada entre cuentas, una guardarraíl de Bedrock con filtros de ataques de prompt y contenido dañino aplicada a cada llamada al modelo y al texto procedente de la otra organización, roles de IAM de mínimo privilegio, contenedores de ECS con sistema de archivos raíz de solo lectura y todas las capacidades de Linux eliminadas sobre una imagen base fijada por hash, y aislamiento total de cuentas sin secretos, claves ni permisos de IAM compartidos. Añadir un segundo ISV requiere actualmente asignar al orquestador un cliente OAuth y un ámbito por ISV, repetir el intercambio de incorporación, añadir la nueva URL de Agent Card y reiniciar el orquestador.