Introdução
O protocolo A2A (Agent-to-Agent) do Google é um padrão aberto de comunicação entre agentes de IA que resolve um problema prático: agentes construídos em frameworks diferentes não conversam entre si. Lançado em abril de 2025 com mais de 50 parceiros, ele define como agentes descobrem uns aos outros, trocam mensagens e coordenam tarefas usando JSON-RPC 2.0 sobre HTTPS. Em junho de 2025 o projeto foi transferido para a Linux Foundation, ganhando governança vendor-neutral.
Se você está começando agora com sistemas multi-agente, vale a pena ler antes o guia de Orquestração de Agentes de IA: Guia de Arquitetura e Padrões que contextualiza onde o A2A se encaixa no ecossistema de orquestração.
O anúncio oficial do Google destaca o protocolo como uma resposta direta à falta de interoperabilidade entre agentes — cada framework (LangGraph, CrewAI, AutoGen, Google ADK) falava a própria língua. O A2A unifica isso com um contrato padrão que qualquer agente pode implementar, independentemente da stack.
O Que é o Protocolo A2A (Agent-to-Agent) do Google?
O protocolo A2A é um padrão aberto de comunicação entre agentes de IA, lançado pelo Google em abril de 2025 e hoje hospedado pela Linux Foundation. Ele resolve o problema de interoperabilidade entre agentes construídos em frameworks diferentes, permitindo que um agente LangGraph converse com um agente Google ADK sem integração customizada.
O Google descreve o protocolo como a nova camada de interoperabilidade para agentes. A motivação é simples: cada framework de agente implementava comunicação do próprio jeito, criando um problema de integração NxN — oito frameworks significam 56 pontes diferentes. O A2A reduz isso a uma única implementação por framework.
O repositório oficial do projeto no GitHub já acumula 23.4k stars e 2.4k forks, com 560 commits sob licença Apache 2.0. A especificação completa tem mais de 300 páginas e está disponível em a2a-protocol.org. Os princípios de design incluem suporte nativo a tarefas longas (horas de processamento), agnosticismo de modalidade (texto, áudio, vídeo) e segurança por padrão.
Mais de 100 empresas fazem parte do ecossistema, incluindo Salesforce, SAP, ServiceNow, LangChain, MongoDB, PayPal, AWS, Microsoft e Cisco. A IBM define o A2A como parte essencial da orquestração de múltiplos agentes especializados em um sistema unificado. Na prática, isso significa que você não precisa reescrever seus agentes para cada parceiro — uma vez que implementa o A2A, qualquer outro agente compatível consegue se comunicar.
Arquitetura e Componentes do A2A
O A2A tem 4 componentes principais: A2A Client (agente que inicia a requisição), A2A Server (agente que processa tarefas), Agent Card (JSON de descoberta de capacidades) e o objeto Task (unidade de trabalho com ciclo de vida definido). Toda comunicação usa JSON-RPC 2.0 sobre HTTPS como formato de troca de dados.
O modelo de dados é dividido em três camadas, conforme a especificação técnica v1.0.0: Data Model (define as estruturas de dados), Abstract Operations (define as 11 operações core) e Protocol Bindings (define como transportar essas operações).
No protocolo A2A, o Agent Card é um documento JSON exposto pelo agente. Ele contém nome, versão, descrição das habilidades, endpoint de comunicação e os esquemas de autenticação suportados. A IBM explica que o Agent Card funciona como um "cardápio" de capacidades — outros agentes consultam esse card para saber se aquele agente pode resolver o problema que eles têm. Se eu sou um agente de análise de dados, meu Agent Card lista "consultas SQL", "geração de relatórios" e "visualização de dados" como skills disponíveis.
O objeto Task representa uma unidade de trabalho. Cada tarefa segue um ciclo de vida: submitted → working → input-required → completed / failed / canceled. Esse lifecycle permite que agentes lidem tanto com operações síncronas rápidas quanto com tarefas longas que exigem horas de processamento. O estado input-required é particularmente útil — indica que o agente precisa de mais informações do cliente antes de prosseguir, como em um fluxo de aprovação humana.
Message é a unidade de comunicação entre agentes. Cada mensagem tem um Role (user ou agent) e pode conter múltiplas Parts — texto, arquivos ou dados estruturados. O Artifact é o output gerado pelo agente ao finalizar uma tarefa: pode ser um documento, imagem ou JSON. Parts e Artifacts são modality-agnostic, ou seja, o mesmo modelo de dados serve para texto, áudio, vídeo e dados binários.
O protocolo suporta três formas de transporte (protocol bindings): JSON-RPC (principal), gRPC e HTTP/REST. Cada binding implementa as mesmas operações abstratas, então você pode migrar entre transportes sem mexer na lógica do agente.
Como Funciona o Fluxo de Comunicação A2A?
O fluxo A2A segue 3 etapas: Discovery (cliente busca Agent Cards para encontrar o agente certo), Authentication (autenticação via OAuth 2.0, API Key ou OpenID Connect) e Communication (envio de tarefas via JSON-RPC com suporte a streaming SSE e push notifications).
O Agent Card de um agente fica acessível em uma URL padronizada: /.well-known/agent-card.json, seguindo a mesma convenção de descoberta usada por OpenID Connect e outros protocolos web. O cliente faz uma requisição GET nessa URL, recebe o JSON com as capacidades do agente e decide se aquele servidor atende à tarefa que precisa resolver.
A IBM descreve o fluxo completo em três passos. Primeiro, o agente cliente descobre outros agentes consultando seus Agent Cards. Como o card inclui o endpoint exato para comunicação, não há necessidade de um service discovery extra. Depois, a autenticação acontece usando esquemas alinhados com a OpenAPI Specification — OAuth 2.0, API Key ou OpenID Connect. Por fim, a comunicação propriamente dita ocorre com o envio de tarefas.
A especificação define 11 operações core que um A2A Server pode implementar. As principais são SendMessage (envio síncrono), SendStreamingMessage (envio com streaming), GetTask (consulta de status), ListTasks (lista de tarefas ativas) e CancelTask (cancelamento). O SendStreamingMessage usa Server-Sent Events (SSE) para enviar updates em tempo real enquanto o agente processa, sem exigir polling do cliente.
Para tarefas muito longas — imagine um agente que leva 20 minutos para processar um relatório financeiro — o protocolo suporta push notifications via webhook HTTPS. O cliente registra uma URL de callback e o servidor notifica quando a tarefa é concluída. O Google ressalta que o streaming SSE foi escolhido como padrão primário por ser um protocolo web maduro e compatível com qualquer cliente HTTP.
A2A vs MCP: Qual a Diferença e Como se Complementam?
O protocolo A2A e o MCP não são concorrentes, são complementares. MCP (Model Context Protocol, da Anthropic) padroniza comunicação entre agentes e ferramentas — é a camada agente-ferramenta. A2A padroniza comunicação entre agentes — é a camada agente-agente. Um sistema maduro usa ambos, cada um no seu lugar.
A IBM deixa isso claro na explicação técnica: MCP resolve o problema "como meu agente acessa um banco de dados ou chama uma API?", enquanto A2A resolve "como meu agente conversa com outro agente que não conheço?"
Pense em um cenário real de supply chain. Um agente de inventário usa MCP para consultar o banco de dados de estoque. Quando o nível crítico é atingido, ele usa A2A para enviar uma tarefa ao agente de compras — que é mantido por outro time, em outra stack tecnológica. Cada protocolo resolve uma parte do problema sem sobreposição.
O curso da DeepLearning.AI sobre A2A, feito em parceria com Google Cloud e IBM Research, dedica um módulo inteiro a essa relação de complementaridade entre os dois protocolos.
Na prática, a decisão de design é simples: se você precisa conectar um agente a uma fonte de dados, use MCP. Se precisa que dois agentes colaborem, use A2A.
Ambos os protocolos são endossados pelas mesmas grandes empresas — Google, IBM, Anthropic — como pilares de uma arquitetura de agentes bem construída. A documentação oficial do A2A também trata MCP como complementar, não como concorrente. Um fluxo comum: o agente A usa MCP para acessar um banco SQL, processa os dados, e usa A2A para passar o resultado para o agente B, que gera um relatório.
Implementação Prática: Como Criar um Agente A2A em Python
Para criar um agente A2A em Python, instale o SDK oficial com pip install a2a-sdk, crie um A2AServer com um AgentCard declarando skills, e implemente o executor que processa tarefas recebidas via SendMessage.
O SDK Python oficial está disponível no PyPI como pacote a2a-sdk, mantido pelo projeto A2A sob a Linux Foundation. A versão estável atual é a v1.0.2, com suporte aos três protocol bindings: JSON-RPC, HTTP/REST e gRPC.
from a2a_sdk import A2AServer, AgentCard, TaskExecutor
class ProcessadorRelatorio(TaskExecutor):
async def execute(self, task):
# task.message contém o input do agente cliente
dados = extrair_dados(task.message.parts)
resultado = gerar_relatorio(dados)
return resultado
card = AgentCard(
name="analisador-financeiro",
description="Analisa dados financeiros e gera relatorios",
skills=["analise-financeira", "geracao-relatorios",
"deteccao-anomalias"],
endpoint="https://meuagente.io/a2a",
auth_schemes=[{"type": "oauth2"}]
)
server = A2AServer(card, executor=ProcessadorRelatorio())
server.run(host="0.0.0.0", port=8080)
O fluxo do lado do cliente é igualmente simples. Você cria um A2AClient, aponta para o endpoint do servidor e chama send_message. O SDK cuida da serialização JSON-RPC, da autenticação e do parsing da resposta — incluindo o tratamento de tarefas assíncronas que mudam de estado ao longo do tempo.
O SDK tem suporte nativo a FastAPI e Starlette como servidores HTTP. Você pode integrar OpenTelemetry para tracing distribuído em produção, e há conectores opcionais para PostgreSQL, MySQL e SQLite como storage de tasks.
O repositório de samples do A2A inclui exemplos prontos para uso: um hello world funcional em Python e JavaScript, e um sistema multi-agente de saúde que coordena três agentes especializados — diagnóstico, agendamento e farmácia — todos se comunicando via A2A.
Para produção, os principais pontos de atenção são: definir bem os estados de task para evitar timeouts em operações longas, configurar autenticação no Agent Card (OAuth 2.0 é o recomendado), e habilitar tracing com OpenTelemetry desde o início para depurar fluxos multi-agente complexos. A especificação técnica cobre cada um desses cenários com exemplos práticos de payload JSON-RPC.
Ferramentas, SDKs e Ecossistema do A2A
O ecossistema A2A inclui SDKs oficiais para Python, Go, JavaScript, Java e .NET, além de integrações com LangGraph, Google ADK, CrewAI e BeeAI, permitindo que agentes de diferentes frameworks se comuniquem nativamente.
O repositório principal do GitHub lista os SDKs disponíveis. Para Python, o pacote é a2a-sdk. Para JavaScript/TypeScript, @a2a-js/sdk no npm. Para Go, o módulo está em github.com/a2aproject/a2a-go. Java e .NET têm pacotes no Maven Central e NuGet respectivamente. Todos os SDKs implementam o mesmo conjunto de operações core, garantindo interoperabilidade entre linguagens.
O Google ADK (Agent Development Kit) já tem suporte nativo a A2A — agentes criados com o ADK podem ser expostos como servidores A2A sem código adicional, pois o runtime do ADK já implementa o Agent Card e o dispatcher de tarefas. Agentes LangGraph também podem ser expostos como servidores A2A usando o adaptador disponível nos samples do repositório oficial.
A DeepLearning.AI oferece um curso gratuito de 2 horas, em parceria com Google Cloud e IBM Research, que ensina na prática como tornar agentes A2A-compliant em três frameworks diferentes. O curso inclui laboratórios práticos de criação de clientes A2A e orquestração de workflows hierárquicos entre agentes.
Se você está escolhendo um framework para começar, vale dar uma olhada no Guia Comparativo de Frameworks de Agentes de IA que mostra quais ferramentas já integram o A2A nativamente e como elas se comparam.
O protocolo A2A continua ativo no GitHub com 23.4k stars, 2.4k forks e uma comunidade que contribui com issues, ADRs (Architecture Decision Records) e novos adaptadores no GitHub Discussions. A governança pela Linux Foundation garante que o protocolo permaneça aberto e independente de qualquer fornecedor, com contribuições de Google, IBM e outras empresas do ecossistema.
Perguntas Frequentes
O que é o protocolo A2A (Agent-to-Agent) do Google?
O protocolo A2A (Agent-to-Agent) é um padrão aberto de comunicação entre agentes de IA, lançado pelo Google em abril de 2025 e hoje sob governança da Linux Foundation. Ele permite que agentes de diferentes frameworks colaborem usando JSON-RPC 2.0 sobre HTTPS, com descoberta de capacidades via Agent Cards.
Qual a diferença entre A2A e MCP?
MCP (Model Context Protocol, da Anthropic) padroniza a comunicação entre agentes e ferramentas — é a camada agente-ferramenta. A2A padroniza a comunicação entre agentes — é a camada agente-agente. Eles são complementares e devem ser usados juntos em uma arquitetura madura.
Como implementar o protocolo A2A em Python?
Instale o SDK oficial com pip install a2a-sdk. Crie um A2AServer declarando um AgentCard com as skills do seu agente e implemente um executor para processar tarefas recebidas via SendMessage. Use FastAPI ou Starlette como servidor HTTP.
O A2A substitui o MCP (Model Context Protocol)?
Não. A2A e MCP resolvem problemas diferentes e são complementares. MCP conecta agentes a ferramentas e fontes de dados. A2A conecta agentes entre si. Uma arquitetura madura de agentes de IA usa ambos os protocolos.
Quais empresas estão usando ou apoiando o protocolo A2A?
O A2A foi lançado com mais de 50 parceiros incluindo Salesforce, SAP, ServiceNow, LangChain, MongoDB e PayPal. Em junho de 2025 foi transferido para a Linux Foundation, somando mais de 100 empresas como AWS, Microsoft e Cisco.
O A2A é compatível com LangGraph e outros frameworks?
Sim. O ecossistema A2A inclui integrações nativas com LangGraph, Google ADK, CrewAI e BeeAI. Agentes construídos em LangGraph podem ser expostos como servidores A2A. O Google ADK já tem suporte nativo ao protocolo.
Quais são os componentes principais da arquitetura A2A?
São quatro: A2A Client (agente que inicia a requisição), A2A Server (agente que processa tarefas), Agent Card (JSON de descoberta de capacidades) e o objeto Task (unidade de trabalho com ciclo de vida que vai de submitted a completed, failed ou canceled).
O que é um Agent Card no protocolo A2A?
Agent Card é um documento JSON que descreve as capacidades de um agente. Inclui nome, versão, descrição das habilidades, endpoint de comunicação e esquemas de autenticação suportados. Fica acessível em /.well-known/agent-card.json no servidor do agente.
Conclusão
O protocolo A2A resolve um problema concreto: agentes de IA precisam conversar entre si sem depender de integrações manuais entre cada par de frameworks. Com suporte da Linux Foundation, SDKs para 5 linguagens e adoção de grandes players como Salesforce, SAP, LangChain e ServiceNow, ele já é um padrão viável para produção.
O ponto principal é entender que A2A não compete com MCP — eles resolvem camadas diferentes. MCP conecta agentes a ferramentas e dados. A2A conecta agentes entre si. Uma arquitetura madura usa ambos.
Para começar hoje: instale o SDK Python com pip install a2a-sdk, implemente um executor simples e exponha seu agente como servidor A2A. Depois explore os samples do repositório oficial — o sistema multi-agente de saúde é um bom ponto de partida para entender fluxos mais complexos com múltiplos agentes cooperando.
O guia de Orquestração de Agentes de IA tem mais contexto sobre onde o A2A se encaixa na arquitetura do seu sistema. Se você está comparando opções, o post sobre Frameworks de Agentes de IA mostra quais ferramentas já integram o protocolo nativamente.