A2A
Por que isso importa
Em profundidade
O problema que A2A enfrenta é simples de enunciar: conforme as organizações implantam mais agentes, esses agentes precisam passar trabalho uns aos outros, e hoje cada par exige uma integração sob medida. A2A define um padrão comum para essa transferência. Um agente atua como cliente, formulando uma tarefa; outro atua como agente remoto, executando-a. Os dois trocam contexto, instruções e resultados por infraestrutura web comum — HTTP com JSON-RPC 2.0 como formato de transmissão e Server-Sent Events para atualizações ao vivo —, portanto a adoção não exige uma nova camada de transporte nem um runtime compartilhado. Crucialmente, os agentes continuam opacos entre si: coordenam-se por capacidades declaradas e pelo estado da tarefa, não pelo compartilhamento de memória, pesos ou raciocínio interno.
Cartões de Agente e Descoberta de Capacidades
A descoberta no A2A funciona por meio do cartão de agente: um pequeno documento JSON, normalmente publicado em um caminho conhecido como /.well-known/agent.json no domínio do agente, que descreve quem opera o agente, quais habilidades ele oferece, quais formatos de entrada e saída aceita e qual autenticação exige. Um agente cliente busca o cartão antes de enviar qualquer trabalho real, para poder decidir — programaticamente ou por um planejador LLM — se esse agente remoto sequer é candidato à tarefa. Na prática, os cartões aparecem de duas formas: diretamente, quando um workflow já conhece a URL de um agente parceiro, ou por registros curados que uma empresa mantém para cada Agente aprovado. O modelo de cartões é o que transforma A2A de uma convenção de mensagens em uma verdadeira camada de descoberta, e espelha como um Agente Autônomo raciocina sobre qualquer outro recurso: leia uma descrição, compare-a ao objetivo e então aja.
Tarefas, Mensagens e Artefatos
A unidade de trabalho no A2A é a tarefa, e ela tem um ciclo de vida explícito: enviada, em andamento, aguardando entrada, concluída, com falha ou cancelada. Dentro de uma tarefa, os dois agentes trocam mensagens, e cada mensagem é formada por partes, não por texto bruto — uma parte de texto para linguagem natural, uma parte de arquivo para conteúdo binário ou uma parte de dados para payloads JSON estruturados, como formulários e cotações. Esse modelo de partes importa porque workflows empresariais reais operam sobre dados estruturados, e A2A permite que agentes negociem por Saída Estruturada, em vez de forçar tudo pela prosa de um chat. Quando uma tarefa termina, seus resultados são entregues como artefatos: saídas nomeadas, novamente construídas com partes, que o agente cliente pode consumir ou passar para a próxima etapa de um Workflow Agêntico maior.
Os estados do ciclo de vida provam seu valor em trabalhos longos. Uma tarefa que leva minutos ou horas pode transmitir eventos de progresso ao cliente por Server-Sent Events ou entregar atualizações por notificações push a um webhook quando o cliente não pode manter uma conexão aberta, mantendo o Streaming viável até para consumidores desconectados. O estado de aguardo de entrada é o sutil: permite que o agente remoto pause e faça uma pergunta de esclarecimento no meio da tarefa, que é como a negociação em várias rodadas entre agentes acontece sem romper a abstração da tarefa.
A2A Não Substitui MCP
O equívoco mais comum sobre A2A é que ele compete com MCP. Não compete — os dois protocolos operam em camadas diferentes. MCP padroniza como um único agente se conecta a ferramentas e fontes de dados: chamar uma função, ler um recurso, executar uma consulta. A2A padroniza como dois agentes independentes se coordenam, com um delegando uma tarefa a um par que pode pertencer a outra equipe, outro fornecedor ou até outro domínio de confiança. O resumo que você ouvirá é que MCP é a interface vertical (agente para ferramenta), enquanto A2A é a horizontal (agente para agente).
Uma configuração realista de produção usa ambos na mesma cadeia de chamadas. Um agente orquestrador pode usar MCP para Uso de ferramentas — acessando um CRM, um índice de busca ou um repositório de código — e depois usar A2A para subcontratar um agente especialista, como um agente de revisão de contratos operado pelo departamento jurídico, que por sua vez depende internamente de MCP e Chamada de Função. Nenhum protocolo determina o que acontece dentro do outro agente, e essa opacidade é uma escolha deliberada de projeto: permite que organizações colaborem sem expor prompts, memória ou raciocínio proprietário.
Governança, Ecossistema e Perguntas em Aberto
O Google lançou A2A como especificação aberta com SDKs de referência em 2025, apoiada na estreia por mais de 50 parceiros de tecnologia, de fornecedores de software empresarial e frameworks como LangChain a consultorias. Depois, doou o projeto à Linux Foundation para que nenhum fornecedor isolado controle sua evolução. Esse movimento de governança importa para a adoção: protocolos só viram encanamento quando concorrentes podem implementá-los sem temer que as regras mudem sob seus pés. A especificação, os SDKs e os agentes de exemplo são todos públicos, e o projeto reutiliza deliberadamente padrões web existentes, em vez de inventar novos.
Os problemas difíceis à frente dizem menos respeito a formatos de mensagem e mais à confiança. Um cartão de agente declara qual autenticação um agente exige, mas nada no protocolo diz se você deve acreditar no cartão, o que torna o tráfego A2A entre organizações uma questão de Segurança da IA tanto quanto de integração. Injeção de Prompt é um risco concreto: um agente remoto malicioso ou comprometido pode incorporar instruções hostis aos resultados de uma tarefa, que o modelo do agente cliente lerá obedientemente. Equipes que hoje constroem Sistemas Multi-Agentes sobre A2A normalmente enfrentam isso restringindo a descoberta a registros curados, validando artefatos antes de chegarem a um modelo e tratando todo agente remoto como não confiável por padrão.