Agentes que atuam além dos limites de uma organização precisam se descobrir, trocar tarefas e colaborar sem expor seus componentes internos nem exigir o mesmo framework dos dois lados. A AWS publicou uma arquitetura de referência que resolve isso com o protocolo Agent-to-Agent (A2A), que a empresa destaca ser agora um projeto da Linux Foundation com apoio da AWS. Sem um protocolo desse tipo, cada integração entre organizações exige código sob medida para cada cliente e framework; com A2A, fornecedores independentes de software (ISVs) podem entregar agentes que interoperam com os frameworks compatíveis com A2A que seus clientes já utilizam.
Embora o artigo seja estruturado em torno do caso de uso dos ISVs, a AWS afirma que o mesmo padrão serve para qualquer organização que exponha agentes a parceiros, clientes ou equipes internas com frameworks diferentes. Novas capacidades são adicionadas registrando Agent Cards no orquestrador, sem alterar os agentes em execução.
Arquitetura em duas contas
O exemplo implantado coloca três agentes em duas contas da AWS: uma para a empresa e outra para o provedor de SaaS. O A2A transporta o tráfego entre eles, autenticado com OAuth nas duas direções, e cada conta tem seu próprio grupo de usuários do Amazon Cognito, de modo que cada lado se autentica com seu próprio provedor de identidade.
Durante a integração inicial, apenas valores públicos são trocados: URLs de provedores de identidade, IDs de cliente, escopos e URLs de endpoints. Depois disso, cada lado confia nos tokens emitidos pelo grupo de usuários do outro, e nenhum segredo atravessa o limite. Concluída a integração, cada requisição segue este caminho: o aplicativo empresarial obtém um token de acesso do seu grupo do Cognito e envia uma pergunta por HTTPS a uma API de usuário no Amazon API Gateway, e em seguida consulta a resposta. O API Gateway encaminha a requisição de forma privada, por um link de VPC e um Network Load Balancer interno, até o Enterprise Orchestrator, um agente LangChain. Quando seu modelo decide que a pergunta exige uma varredura de conformidade, o orquestrador obtém seu próprio token com um segredo de cliente armazenado no AWS Secrets Manager e envia uma requisição A2A ao agente de conformidade de SaaS hospedado no runtime do Amazon Bedrock AgentCore, usando a habilidade lida do Agent Card desse agente na inicialização. O agente de conformidade verifica o Agent Card do agente de contexto empresarial na URL de retorno registrada na integração, obtém um token do grupo próprio do provedor de SaaS, solicita os metadados da conta, conclui a varredura e devolve o resultado ao aplicativo por meio do orquestrador.
Os agentes
Dois agentes empresariais rodam no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate, em sub-redes privadas de uma Amazon VPC sem endereços IP públicos. O Enterprise Orchestrator é o ponto de entrada dos usuários: o LangChain fornece o framework e as abstrações de chamada de ferramentas, e o Amazon Bedrock fornece os modelos de fundação. O orquestrador usa o Anthropic Claude Sonnet 4.6. Na inicialização, ele busca o Agent Card do agente de SaaS em sua URL conhecida e cria uma ferramenta LangChain para cada habilidade anunciada, de modo que o modelo escolhe a ferramenta conforme a pergunta e não é necessária lógica de roteamento fixa. Ele envia requisições de varredura por A2A com tokens de portador OAuth e resume os resultados para a liderança. Os usuários o acessam por um endpoint do API Gateway que aceita apenas tokens do grupo empresarial.
O segundo agente, o Enterprise Context Agent, também usa LangChain, mas roda com o Amazon Nova Lite. Ele fornece metadados internos como regras de política, classificação de dados, criticidade de negócio e contatos de escalação, incluindo escalas de plantão. É construído com o a2a-sdk oficial (AgentCard, AgentExecutor e rotas JSON-RPC conformes à especificação), fixado em a2a-sdk[http-server]==1.2.2. O agente de SaaS o alcança por uma API de parceiro do API Gateway que aceita apenas o token de retorno do provedor.
Do lado do provedor, o Compliance SaaS Agent roda no Amazon Bedrock AgentCore em sua própria conta e é construído com o SDK do Strands Agents. Ele verifica contas da AWS em relação às políticas internas da empresa, como a proibição de armazenamento público em produção e a criptografia em repouso de dados confidenciais. Em produção, suas ferramentas se conectariam a serviços como AWS Config, AWS Security Hub ou Amazon GuardDuty; a demonstração usa dados sintéticos que simulam achados em várias contas. Antes de varrer, o agente chama de volta o agente de contexto para obter informações que só a empresa possui, o que torna os dois agentes pares, e não cliente e servidor. O retorno só vai para o endereço registrado na integração.
A decisão central de design é encaminhar toda a comunicação entre limites pelo A2A. A empresa não pode ver as ferramentas internas, o prompt de sistema nem a escolha de modelo do agente de SaaS, de modo que o ISV pode alterar sua arquitetura interna sem quebrar as integrações dos clientes, desde que o Agent Card e a interface A2A permaneçam compatíveis. O cartão publica uma única habilidade selecionada, e não os nomes das ferramentas internas. No cartão de exemplo, essa habilidade é "compliance-scan", o cartão declara protocolVersion "0.3.0" e sua seção securitySchemes descreve um fluxo OAuth 2.0 de credenciais de cliente contra o endpoint de tokens do Cognito do cliente, com o escopo "a2a-enterprise-compliance-saas/invoke". Os cartões são servidos em /.well-known/agent-card.json.
A AWS também diferencia o A2A do Model Context Protocol (MCP): o MCP conecta um agente às suas próprias ferramentas e fontes de dados em um modelo cliente-servidor, enquanto o A2A conecta agentes entre si como pares. Um agente de SaaS em produção poderia usar MCP internamente e A2A externamente, mantendo a interface externa inalterada.
Destaques da implementação
O orquestrador usa deliberadamente chamadas httpx simples com JSON-RPC de A2A (método "message/send"), sem depender do SDK do Strands; se o ISV migrasse para outro framework compatível com A2A, o lado empresarial continuaria funcionando. O tratamento de tokens falha de forma fechada e tenta novamente uma vez com renovação forçada diante de um HTTP 401. No lado do retorno, o agente de SaaS verifica o cartão de contexto do cliente com um GET anônimo que não segue redirecionamentos antes de obter seu próprio token; qualquer falha chega ao modelo como a única mensagem "Enterprise context unavailable", enquanto os detalhes permanecem nos logs do provedor.
Toda requisição de tarefa A2A carrega um JWT. O Amazon Bedrock AgentCore é configurado com a URL de descoberta do grupo empresarial, um cliente permitido e um escopo, e valida o JWT em cada requisição recebida. Os autorizadores JWT do API Gateway restringem a API de parceiro ao token de retorno do SaaS e a API de usuário ao token do aplicativo empresarial. Cada conta guarda seu segredo de cliente no AWS Secrets Manager, limitado por IAM e por uma política de recursos à única carga de trabalho que o utiliza. O único endpoint sem autenticação é o Agent Card público do agente de contexto. A AWS aponta um erro de configuração frequente: um token de credenciais de cliente do Cognito carrega client_id e scope, mas não o claim aud, de modo que o autorizador do API Gateway verifica client_id contra a lista de audiências, enquanto o AgentCore deve ser configurado com allowedClients e sem allowedAudience.
Implantação e testes
O sistema é implantado a partir de três notebooks Jupyter que criam cinco pilhas do AWS CloudFormation, três na conta empresarial e duas na conta do provedor de SaaS. O notebook 1 (empresa, cerca de 3 minutos) cria a identidade empresarial e grava o onboarding-request.json; o notebook 2 (provedor de SaaS, cerca de 5 minutos) implanta o agente de conformidade e devolve o onboarding-response.json; o notebook 3 (empresa, cerca de 20 minutos) implanta os agentes empresariais e executa os testes. Os arquivos de integração contêm apenas valores públicos. Os pré-requisitos incluem duas contas da AWS em us-east-1, us-east-2 ou us-west-2, acesso ao Anthropic Claude Sonnet 4.6 em ambas e ao Amazon Nova Lite na conta empresarial (com o formulário de primeiro uso da Anthropic enviado), Python 3.10 ou superior com JupyterLab e AWS CLI versão 2 ou uma instância de notebook do Amazon SageMaker AI (ml.t3.medium é suficiente), e funções do IAM capazes de criar pilhas do CloudFormation. O Docker não é necessário localmente porque o AWS CodeBuild constrói as imagens de contêiner. Os notebooks verificam o acesso aos modelos do Bedrock antes de implantar e param no primeiro erro; as seções de limpeza ficam atrás de células de parada para que o Run All não as alcance.
O teste de ponta a ponta do notebook 3 envia uma pergunta pela API de usuário e consulta o status a cada 5 segundos. Ele só passa se a resposta contiver achados de conformidade e um código de escala de plantão conhecido apenas pelo agente de contexto, e se o log de acesso da API de parceiro mostrar um 200 do cliente de retorno do SaaS. Uma etapa seguinte executa sete verificações de limites de confiança enviando tokens incorretos, ausentes ou forjados a cada porta; todas devem ser rejeitadas com 401. Na execução resumida publicada pela AWS, a etapa de ponta a ponta terminou em 52,5 segundos, as verificações de limites em 1,4 segundo, e o relatório cobriu duas contas de produção e seis achados com contatos de escalação por conta.
Custos, notas de produção e limitações
Executar a solução gera cobranças: na conta empresarial, os principais recursos sempre ativos são um gateway NAT, duas tarefas do Fargate, o Network Load Balancer interno e dois endpoints de VPC de interface, enquanto o Amazon Bedrock e o AgentCore cobram por uso. Para produção, a AWS sugere um runtime por cliente ou uma camada de entrada que aceite vários provedores de identidade de clientes, autenticação de cliente baseada em chaves (private_key_jwt ou TLS mútuo) em vez de segredos, AWS PrivateLink e TLS dentro da VPC, chaves do AWS KMS gerenciadas pelo cliente, VPC Flow Logs e logs de acesso do Network Load Balancer, uma função de rotação do Secrets Manager e um portal de integração autenticado. Respostas HTTP 503 intermitentes pelo API Gateway podem indicar que o balanceamento de carga entre zonas está desativado no Network Load Balancer interno, já que cada serviço do ECS executa uma única tarefa que pode iniciar em qualquer uma das zonas de disponibilidade.
A AWS enfatiza que o exemplo deve ser executado apenas em contas de teste sem dados de clientes ou de negócios, que usa exclusivamente dados sintéticos e que não avalia nem certifica a conformidade com nenhuma lei, regulamento ou norma. Seus controles incluem HTTPS em toda chamada entre contas, uma guarda do Bedrock com filtros de ataques de prompt e conteúdo prejudicial aplicada a cada chamada de modelo e ao texto vindo da outra organização, funções do IAM de menor privilégio, contêineres do ECS com sistema de arquivos raiz somente leitura e todas as capacidades do Linux removidas sobre uma imagem base fixada por digest, e isolamento total das contas sem segredos, chaves ou permissões de IAM compartilhados. Adicionar um segundo ISV exige atualmente atribuir ao orquestrador um cliente OAuth e um escopo por ISV, repetir a troca de integração, adicionar a nova URL de Agent Card e reiniciar o orquestrador.