A AWS publicou em 12 de novembro de 2026 uma arquitetura de referência em que um orquestrador LangChain e um agente Strands colaboram pelo protocolo Agent-to-Agent, ou A2A, em contas AWS separadas. Cada lado mantém seu framework, modelo e ferramentas internas, enquanto a descoberta ocorre por Agent Cards e a autenticação usa OAuth 2.0 e OpenID Connect. O padrão reduz integrações exclusivas, mas não elimina onboarding, contratos, validação de URLs, menor privilégio, observabilidade e controle de custo.
Use A2A para comunicação entre agentes
A2A conecta agentes como pares por uma interface padronizada. No exemplo da AWS, o orquestrador empresarial chama um agente de conformidade de um fornecedor e esse agente faz um callback para buscar contexto interno. Nenhum lado precisa compartilhar o mesmo SDK nem expor prompt, modelo ou ferramentas internas.
MCP e A2A atendem fronteiras diferentes. MCP costuma conectar um agente às próprias ferramentas e fontes de dados. A2A conecta um agente a outro agente que oferece uma capacidade. Uma solução pode usar MCP internamente e publicar uma interface A2A externa sem revelar sua implementação.
Publique um contrato mínimo no Agent Card
O Agent Card é um documento JSON em um endereço bem conhecido que descreve nome, capacidades, skills, endpoint e esquema de segurança. O consumidor pode descobrir o que o agente faz e criar uma ferramenta de orquestração sem incorporar o SDK do fornecedor. A compatibilidade depende da estabilidade desse contrato.
Publique somente capacidades curadas, não nomes de ferramentas internas, credenciais ou detalhes desnecessários. Versione o cartão, defina exemplos de entrada e saída, limite tamanhos e documente erros. Uma descrição vaga pode levar o modelo orquestrador a chamar o agente errado; uma descrição excessiva amplia a superfície de informação.
- Identificador e versão do agente
- Skills e exemplos de uso permitidos
- Esquema de autenticação e escopos
- Formato de tarefa, resposta e erro
- Limites de tempo, tamanho e idempotência
Faça onboarding sem compartilhar segredos
Na referência, empresa e fornecedor trocam URLs dos provedores de identidade, IDs de cliente, escopos e endpoints. Cada lado confia nos tokens emitidos pelo pool do outro, e os segredos permanecem no próprio ambiente. Valores públicos de onboarding não devem ser confundidos com autorização irrestrita.
Mantenha um registro aprovado de parceiros, emissores, audiências, escopos e URLs. Valide HTTPS, domínio, certificado e redirecionamentos antes de aceitar um cartão ou callback. Não permita que uma mensagem do usuário escolha o endpoint. A aplicação deve usar o endereço fixado durante a descoberta e falhar fechada quando a identidade ou o contrato não puder ser verificado.
Restrinja OAuth e callbacks em duas direções
O fluxo bidirecional é útil quando o agente externo precisa de contexto que somente a empresa possui. Ele também aumenta o risco: o fornecedor passa a iniciar chamadas de retorno. Conceda escopos específicos, audiência restrita, validade curta e uma URL cadastrada. O callback deve entregar apenas os campos necessários para a tarefa.
Separe a identidade do usuário da identidade de serviço do agente. Registre emissor, sujeito, audiência, escopo, tarefa e resultado, sem gravar tokens. Trate renovação e revogação de clientes, rotação de segredos locais e resposta a um parceiro comprometido. Uma falha de contexto deve encerrar ou degradar a tarefa de forma previsível, não liberar acesso alternativo.
Teste contratos, falhas e conteúdo não confiável
Faça testes de contrato entre versões diferentes de cartões, SDKs e frameworks. Cubra token vencido, escopo insuficiente, skill removida, resposta atrasada, tarefa duplicada, callback indisponível e mudança de esquema. O orquestrador precisa distinguir falha técnica, recusa de autorização e resultado de negócio.
A saída de um agente externo continua sendo conteúdo não confiável. Valide campos, limites e referências antes de usá-la em outra ferramenta. Não transforme texto retornado em instrução de sistema nem permita que ele altere endpoint, permissão ou política. A interoperabilidade transporta uma resposta; ela não prova a correção dessa resposta.
Observe cada tarefa de ponta a ponta
Propague um identificador de correlação entre API, orquestrador, chamada A2A, callback e resposta. Meça latência por etapa, taxa de sucesso, renovação de token, tentativas, custo de modelo e volume de dados. O usuário deve receber um estado claro quando uma tarefa longa continua em execução ou falha.
Defina timeout, repetição limitada, idempotência e circuit breaker por parceiro. Um retry sem controle pode duplicar uma ação ou multiplicar custo. Registre a versão do Agent Card e do contrato usada em cada execução para reproduzir incidentes e comparar mudanças.
Calcule o custo completo do piloto
A arquitetura de referência cria recursos sempre ativos, como tarefas Fargate, NAT Gateway, balanceador e endpoints de VPC, além do consumo de Bedrock e AgentCore. A própria AWS recomenda executar a limpeza após o teste. Um protocolo aberto não torna a infraestrutura gratuita nem reduz automaticamente a operação.
Comece com uma skill reversível e um parceiro controlado. Compare tempo de integração, mudanças necessárias em cada lado, taxa de tarefas corretas, latência, custo e incidentes. Amplie apenas quando o contrato continuar estável entre frameworks e quando a equipe conseguir revogar acesso, rastrear uma chamada e interromper o fluxo sem depender do fornecedor.
Para levar daqui
A2A reduz acoplamento entre agentes quando o contrato externo permanece pequeno, autenticado e observável. Agent Cards, OAuth, callbacks fixados, testes de contrato e custo total precisam entrar no desenho desde o piloto.
