O teu fornecedor escreve-te a dizer que o agente dele já fala A2A e que o teu se pode ligar amanhã. Parece canalização, coisa de uma tarde de engenharia. Mas assim que dois agentes de duas organizações diferentes negoceiam uma tarefa — uma encomenda, uma marcação, uma reclamação —, a pergunta que importa deixa de ser como viajam as mensagens. É quem responde quando a mensagem está certa e o resultado não.
A tese numa frase: o protocolo A2A para agentes entre empresas resolve o transporte e deixa intacto o problema de fundo, que é contratual. Para quase todas as PME, hoje, a decisão não é técnica: é o que assinas com quem opera o outro agente, que permissões dás ao teu e como vais reconstituir uma conversa que nenhuma das partes vê por inteiro.
Protocolo A2A e agentes entre empresas: o que resolve e o que deixa em aberto
O A2A (Agent2Agent) é um protocolo aberto que permite a um agente entregar trabalho a outro sem saber como este é feito por dentro. Nasceu na Google e, a 9 de abril de 2026, a Linux Foundation anunciou a versão 1.0, a primeira especificação estável, com mais de 150 organizações a apoiá-la, segundo a própria fundação. Cuidado com o número: vem de um comunicado de quem promove o padrão e mede apoios, não uso em produção.
Tem duas peças principais. O «cartão de agente», um documento que diz quem é o agente, o que sabe fazer e como se autenticar, e que na 1.0 pode ser assinado. E um ciclo de vida das tarefas com estados padrão: em curso, concluída, falhada, rejeitada, à espera de dados, à espera de autorização.
O que não faz pesa tanto como o que faz. Segundo a sua especificação, cada agente colabora sem aceder ao estado interno, à memória nem às ferramentas do outro. É uma virtude técnica — cada parte protege a sua implementação — e é, ao mesmo tempo, o problema de governação: o agente do teu fornecedor é, por desenho, uma caixa negra para ti, e o teu é-o para ele.
| Pergunta | O que o A2A traz | O que fica para o teu contrato |
|---|---|---|
| Quem é o outro agente? | Cartão de agente, que pode ser assinado | Quem o emite e quem responde pela sua veracidade |
| Como se pede e se entrega o trabalho? | Mensagens e estados de tarefa padrão | O que conta como «entregue» e quanto tempo há para o contestar |
| Quem pode pedir o quê? | Esquemas de autenticação e autorização habituais na web | Que âmbito se concede, a quem e como se revoga |
| E se se enganar? | Estados «falhada» ou «rejeitada» | Quem assume o erro quando a tarefa aparece como «concluída» e está errada |
| Como se audita? | Nada de específico | O que cada parte regista e durante quanto tempo |
A última coluna não é só uma opinião nossa. A especificação limita-se ao protocolo e deixa a confiança, a responsabilidade e a auditoria entre organizações nas mãos de quem o implementa, e as análises independentes do setor concordam que a segurança entre organizações é a pergunta por resolver.
Em que é que o A2A se distingue do MCP?
Resposta curta: o MCP liga o teu agente às tuas ferramentas; o A2A liga o teu agente ao agente de outra organização. Com o MCP és tu que decides que ferramentas existem, o que fazem e com que credenciais; explicamo-lo em o que é o MCP e porque muda os agentes de empresa. Com o A2A, do outro lado está alguém que decide por conta própria, com o seu modelo, os seus erros e o seu calendário de alterações. É a diferença entre comprar uma ferramenta e subcontratar uma oficina.
Um exemplo hipotético, sem nomes
O agente de compras de um cliente pede ao agente de vendas do seu distribuidor para «repor este material ao melhor preço». O segundo responde com um preço e um prazo, e a tarefa fica marcada como concluída. Esse preço vincula? O prazo é um compromisso? Quem verificou que o agente do distribuidor usava a tabela certa? Nada disto viaja na mensagem. Tudo isto é contrato, e se não estiver escrito decide quem reclamar com mais força.
Quatro perguntas de contrato antes de ligares o teu agente ao de um terceiro
1. Quem responde pelo resultado?
Quando a tarefa chega como concluída e o resultado está errado — um preço mal confirmado, uma marcação duplicada, uma encomenda com a quantidade errada —, o protocolo não tem opinião. O contrato tem de a ter: o que conta como entrega, quem a verifica e quanto tempo há para a discutir.
2. O que acontece se o agente do outro se enganar?
O teu agente age sobre o que o outro lhe diz. Se o outro inventa um prazo de entrega e o teu o promete ao teu cliente, o erro já é teu aos olhos do cliente. Decide de antemão o que o teu agente pode fazer sozinho com uma resposta externa e o que exige confirmação humana: é o raciocínio dos níveis de autonomia de um agente, aplicado a uma fonte que não controlas.
3. Como se audita uma conversa entre duas caixas negras?
Cada parte vê só a sua metade. Para reconstituir o que aconteceu precisas de guardar o que o teu agente enviou, o que recebeu, com que identidade e com que resultado, e acordar que a outra parte conserva o seu durante um prazo. Sem isso, o primeiro litígio resolve-se com duas versões incompatíveis. A base é a rastreabilidade das decisões de IA; para o prazo, durante quanto tempo guardar os logs de um agente de IA.
4. O que pode pedir cada um e como se revoga?
Um agente que fala com o exterior abre uma superfície nova. Dá-lhe identidade própria, âmbito por tarefa e uma revogação testada, como detalha o guia sobre permissões de um agente de IA, e exige o mesmo ao outro. Um cartão de agente assinado atesta quem é o agente; não atesta que mereça o âmbito que pede.
Quando NÃO precisas do A2A (ainda)
Três situações em que adotá-lo é antecipar um problema que não tens:
- O outro lado oferece uma API normal. Se o teu cliente ou fornecedor expõe um serviço com entradas e saídas definidas, uma integração clássica é mais barata, mais fácil de auditar e não depende de dois modelos se entenderem. O A2A compensa quando o trabalho é aberto e há negociação, não numa consulta com resposta fechada.
- Todos os teus agentes vivem dentro da tua empresa. A coordenação interna resolve-se com orquestração, não com um padrão entre organizações. Começa por orquestrar vários agentes de IA e por perguntar se precisas de um agente ou de muitos.
- Ninguém pediu que o teu agente fale com outro. Um protocolo com muitos logótipos de apoio não equivale a muitos casos em produção: a própria análise do setor separa apoiar um padrão de o manter em produção depois do primeiro incidente a sério.
O que fazer esta semana
- Pergunta aos teus fornecedores-chave se o agente deles oferece A2A e o que oferece hoje por API. Se a resposta for «estamos a avaliar», já sabes o calendário.
- Para o primeiro caso candidato, escreve as quatro perguntas acima com nome e apelido: quem verifica, quem assume o erro, o que se regista e que âmbito se concede.
- Define que decisões do teu agente exigem confirmação humana quando o dado vem de fora, e testa-o com uma resposta errada propositada.
- Confirma que o teu registo guarda o enviado e o recebido com a identidade do agente que atuou. Se não, corrige isso antes de abrires qualquer ligação.