Resumo: anunciado pelo Google em abril de 2025, o Agent2Agent Protocol passou à governança da Linux Foundation em junho daquele ano e chegou à versão 1.0 em março de 2026. A mudança torna a proposta mais concreta, mas não elimina os problemas de identidade, autorização, auditoria e compatibilidade que aparecem quando um agente delega trabalho a outro.
Em 9 de abril de 2025, o Google apresentou o Agent2Agent Protocol, ou A2A, como uma forma aberta de agentes de IA descobrirem capacidades, trocarem mensagens e acompanharem tarefas entre plataformas diferentes. Naquele momento, o anúncio citava apoio e contribuições de mais de 50 parceiros de tecnologia e serviços. A parte importante, porém, não era a lista de empresas. Era a tentativa de transformar a comunicação entre agentes em um contrato técnico verificável, em vez de depender de integrações feitas uma a uma.
O projeto não ficou parado no anúncio. Em 23 de junho de 2025, a Linux Foundation informou que assumiria a casa institucional do A2A sob uma governança neutra. Depois de uma sequência de versões preliminares, o repositório publicou a versão 1.0 em 12 de março de 2026 e a correção 1.0.1 em 26 de maio. Isso não prova adoção ampla nem garante maturidade em qualquer cenário. Mostra, sim, que o protocolo ganhou uma especificação versionada e continuou mudando depois da apresentação inicial.
Quando isso aconteceu
- 9 de abril de 2025: o Google anunciou publicamente o A2A e publicou uma especificação ainda em rascunho.
- 23 de junho de 2025: a Linux Foundation anunciou o projeto Agent2Agent sob sua governança.
- 12 de março de 2026: o repositório oficial publicou a versão 1.0, com mudanças incompatíveis em relação às versões anteriores.
- 26 de maio de 2026: a versão 1.0.1 corrigiu detalhes da especificação, incluindo o tipo de mídia preferido para a ligação HTTP e valores de estado de tarefas.
Essa cronologia importa porque muitos textos ainda descrevem o A2A como se ele fosse apenas o rascunho mostrado no lançamento. Para avaliar uma implementação hoje, é necessário conferir qual versão do protocolo e qual SDK ela realmente usa.
O que o A2A tenta padronizar
O A2A não é um modelo de linguagem, um agente pronto nem uma plataforma de automação. Ele define uma linguagem comum para sistemas de agentes independentes. A especificação atual organiza esse contrato em três camadas: um modelo de dados canônico, operações que os agentes entendem e ligações concretas a protocolos como JSON-RPC, gRPC e HTTP/REST.
Na prática, um agente cliente pode consultar um cartão do agente, chamado Agent Card, para descobrir capacidades e formas de conexão. Depois, envia uma mensagem que pode iniciar uma tarefa. A tarefa tem estado, pode durar mais do que uma requisição comum e pode produzir artefatos. O protocolo também prevê respostas em fluxo e notificações para trabalhos longos.
A distinção entre mensagem e artefato é útil. Mensagens servem para pedir, esclarecer e relatar progresso. Artefatos representam o resultado produzido. Essa separação ajuda sistemas diferentes a concordarem sobre o que é conversa, o que é estado e o que deve ser tratado como saída da tarefa.
A2A e MCP resolvem problemas diferentes
O anúncio do Google descreveu o A2A como complementar ao Model Context Protocol, ou MCP. A comparação mais simples é esta: o MCP ajuda um agente a acessar ferramentas, dados e contexto; o A2A ajuda agentes independentes a se descobrir, delegar tarefas e trocar resultados. Há sobreposição possível nas implementações, mas os papéis não são idênticos.
Um agente de atendimento, por exemplo, pode usar MCP para consultar uma base interna e A2A para encaminhar uma tarefa a um agente especializado de logística. O segundo agente não precisa expor sua memória interna nem a lista completa de ferramentas. Ele declara capacidades, recebe a solicitação e devolve mensagens, estados e artefatos segundo o contrato do protocolo.
Para entender a outra metade desse cenário, vale ler também o nosso conteúdo sobre a especificação do MCP e seu núcleo sem estado.
O que mudou com a versão 1.0
Chegar a 1.0 não significa que toda integração anterior continuará funcionando sem ajustes. As notas da versão registram mudanças incompatíveis, entre elas a reorganização de configurações de notificações, alterações de nomes e identificadores, uma revisão ampla que separa a definição do protocolo das ligações de transporte e a remoção de campos antigos. A versão também adicionou listagem de tarefas com filtros e paginação, suporte a multitenancy em gRPC e mecanismos para SDKs lidarem com compatibilidade.
A especificação atual exige que clientes indiquem a versão do A2A usada na requisição. O servidor deve aplicar a semântica correspondente ou devolver um erro de versão não suportada. Esse detalhe reduz a chance de uma atualização silenciosa fazer o agente perder recursos sem que a equipe perceba, mas só funciona se cliente e servidor tratarem versionamento de forma explícita.
A correção 1.0.1 reforça outro ponto: mesmo depois do marco 1.0, detalhes de interoperabilidade continuam sendo ajustados. Portanto, a pergunta operacional não deve ser apenas “suporta A2A?”. O correto é perguntar qual versão, qual ligação de transporte, quais extensões e quais comportamentos foram testados em conjunto.
Governança neutra ajuda, mas não substitui validação
A ida para a Linux Foundation reduz a dependência institucional de um único fornecedor e cria um espaço comum para evolução do padrão. Isso é relevante para empresas que não querem desenhar toda a arquitetura de agentes em torno de uma plataforma exclusiva.
Esse benefício, porém, precisa ser separado de uma inferência que os anúncios não demonstram: governança aberta não garante que dois produtos rotulados como compatíveis trabalharão corretamente em produção. Diferenças de versão, extensões proprietárias, autenticação, formatos de artefato e interpretação das capacidades ainda podem quebrar a integração.
Também não há, nas fontes consultadas, prova de que o A2A sozinho reduza custos, aumente produtividade ou evite dependência de fornecedor em qualquer implantação. Esses são objetivos e argumentos de arquitetura. O resultado depende da implementação, dos controles e dos testes feitos no ambiente real.
Segurança não vem pronta com o protocolo
A especificação reaproveita práticas conhecidas da web e prevê autenticação, autorização e escopos. Ela determina, por exemplo, que o servidor rejeite credenciais inválidas, negue operações sem permissão e evite revelar recursos que o cliente não pode acessar. Para notificações, o cliente deve validar a origem e tratar entregas repetidas de forma segura.
Mesmo assim, uma implementação precisa tomar decisões que o padrão não pode tomar pela equipe. Qual agente pode chamar qual outro? Que dados podem atravessar a fronteira? Uma tarefa pode executar ação externa ou apenas consultar? Como revogar credenciais? Onde ficam os registros para reconstruir uma delegação? O que exige aprovação humana?
Um Agent Card descreve capacidades, mas não deve ser tratado como prova automática de confiança. A equipe ainda precisa validar identidade, origem, versão, permissões e comportamento. Antes de conectar agentes a contas e arquivos, use um processo de revisão de permissões e menor privilégio.
O que uma equipe deve testar antes de adotar
- Fixe a versão: registre a versão A2A e as versões dos SDKs nos dois lados da integração.
- Valide a descoberta: trate cartões de agente como metadados não confiáveis até confirmar origem e assinatura quando aplicável.
- Comece com leitura: use uma tarefa de baixo risco, sem escrita em sistemas externos, para observar estados, mensagens e artefatos.
- Teste falhas: simule credencial expirada, agente indisponível, versão incompatível, resposta duplicada e cancelamento de tarefa.
- Restrinja dados: envie somente o contexto necessário e bloqueie segredos, dados pessoais e anexos que não façam parte da tarefa.
- Registre delegações: guarde quem iniciou a tarefa, qual agente remoto foi acionado, quais permissões foram usadas e qual artefato voltou.
- Defina aprovação humana: ações financeiras, publicação, exclusão, contratação ou mudança de acesso não devem ser liberadas apenas porque a troca técnica funcionou.
Por que isso ainda importa
O valor histórico do anúncio de 2025 está na mudança de unidade de integração. Em vez de pensar apenas em um modelo chamando uma ferramenta, o A2A propõe que sistemas de agentes mantenham fronteiras próprias e cooperem por meio de capacidades declaradas, tarefas, estados e artefatos.
A chegada à versão 1.0 em 2026 tornou essa proposta mais verificável. Há uma versão definida, notas de migração, regras de compatibilidade e uma base normativa. Ao mesmo tempo, a quantidade de mudanças incompatíveis até 1.0 é um alerta contra a adoção baseada apenas em demonstrações antigas.
Para quem está montando uma arquitetura de agentes, o A2A merece um piloto controlado quando existe uma necessidade real de interoperabilidade entre sistemas independentes. Para fluxos simples, um agente com ferramentas bem delimitadas pode continuar sendo mais fácil de proteger, testar e operar. Mais agentes não significam automaticamente um sistema melhor.
Fontes primárias consultadas
- Google Developers Blog: anúncio do Agent2Agent Protocol, 9 de abril de 2025
- Linux Foundation: lançamento do projeto Agent2Agent sob governança da fundação, 23 de junho de 2025
- Repositório oficial do A2A: notas das versões 1.0.0 e 1.0.1
- Especificação oficial do Agent2Agent Protocol
A imagem de capa é uma ilustração editorial original. Não representa uma interface, captura de tela ou arquitetura oficial do A2A.