AWS conecta três agentes de IA em duas contas por meio do protocolo A2A

Você criou um assistente de IA corporativo em LangChain, enquanto o fornecedor do serviço de verificação de segurança usa Strands. Agora é preciso conectá-los: repassar a tarefa, verificar o acesso e explicar ao serviço externo quais regras internas valem para o cliente. Normalmente, surge aqui uma camada de integração separada, que as duas equipes precisam manter.

A AWS publicou um exemplo dessa conexão via Agent-to-Agent, ou A2A. Nele, três agentes atuam em duas contas da AWS, trocam tarefas e solicitam contexto uns aos outros. O valor prático do material está no esquema concreto de interação entre empresas: frameworks diferentes, sistemas de identidade separados e uma chamada de retorno ao cliente.

Como o agente externo descobre as regras da empresa

Imagine uma solicitação de um gestor: verificar se as contas de trabalho violam os requisitos internos de segurança. O agente corporativo recebe a pergunta e repassa a verificação ao agente do fornecedor SaaS. Mas o fornecedor, por si só, não sabe quais contas pertencem à produção, quais dados são considerados confidenciais e a quem comunicar os problemas.

Por isso, o agente externo recorre a um terceiro participante: o agente interno de contexto. Ele fornece informações sobre as contas, as políticas aplicáveis e os contatos para escalonamento. Com o contexto em mãos, o agente SaaS conclui a verificação e devolve o resultado ao orquestrador corporativo, que prepara a resposta ao usuário.

Por exemplo, uma conta de produção pode estar sujeita à proibição de armazenamento público, e os dados confidenciais, à exigência de criptografia em repouso. Essas regras são definidas pela empresa. O fornecedor obtém as informações necessárias por meio de uma interface acordada e as usa em sua tarefa.

Na demonstração, os dados sobre violações são sintéticos. Os autores descrevem a conexão real com AWS Config, Security Hub ou GuardDuty como o próximo passo para um sistema de produção. Por isso, o exemplo mostra a organização da interação, mas não comprova a qualidade de uma auditoria de segurança automática.

O que exatamente o A2A padroniza

Na inicialização, o orquestrador carrega o Agent Card do agente externo, uma descrição de suas capacidades. Com base nas habilidades publicadas, ele cria ferramentas do LangChain, e o modelo escolhe a ferramenta adequada de acordo com a pergunta do usuário. Nesse esquema, não é preciso definir uma rota separada para cada pergunta.

O cartão do agente SaaS publica uma única capacidade aplicada: a verificação de conformidade com requisitos. As ferramentas internas, o prompt de sistema e a escolha do modelo permanecem do lado do fornecedor. Ele pode alterar a implementação desde que mantenha a compatibilidade do cartão e da interface A2A externa.

Para uma equipe de produto, essa é uma fronteira de responsabilidade útil: o cliente se integra à capacidade do serviço, e o fornecedor desenvolve por conta própria a sua estrutura interna. Mesmo assim, a compatibilidade da interface precisa ser mantida: o protocolo não elimina os acordos sobre o comportamento e o resultado da tarefa.

Nessa arquitetura, o A2A também tem um papel distinto do MCP. Por meio do MCP, o agente pode conectar suas próprias ferramentas e fontes de dados. Por meio do A2A, ele repassa o trabalho a outro agente. Um mesmo serviço pode usar os dois protocolos: MCP internamente e A2A para a interação com o cliente.

Onde termina o exemplo pronto

Cada lado usa seu próprio pool de usuários do Amazon Cognito. Na conexão, as empresas trocam parâmetros públicos: endereços, identificadores de clientes e escopos de acesso. Segredos não são transmitidos entre elas, embora dentro de cada lado existam segredos para obter tokens, armazenados no Secrets Manager.

A chamada de retorno só é permitida para o endereço registrado na conexão do cliente. Antes de chamar, o agente SaaS verifica o cartão do agente interno. É um detalhe importante: o endereço de destino é definido pela configuração da integração, e não por um texto arbitrário da tarefa recebida.

A implantação é dividida em três notebooks Jupyter. As estimativas dos autores para as etapas são de cerca de 3, 5 e 20 minutos; a preparação das contas e das permissões exigirá tempo adicional. A infraestrutura é paga, e parte dos recursos funciona de forma contínua, incluindo o gateway NAT, as tarefas do Fargate e o balanceador de carga.

O desenvolvedor deve estudar esse exemplo se o agente precisar trabalhar com serviços de parceiros ou de diferentes equipes internas. Dá para começar por um único cenário: repassar uma tarefa ao agente externo, permitir uma solicitação limitada de contexto e testar todo o caminho com os tokens de ambos os lados. Foi justamente esse trecho que a AWS detalhou o suficiente para que o material sirva de base para um protótipo próprio.