Protocolo A2A do Google em 2026: Adoção, Hype e Realidade

A2A não está morto. Apenas não é universal.

Conteúdo da página

O protocolo Agent2Agent da Google, geralmente abreviado para A2A, teve um primeiro ano estranho.

Quando a Google anunciou o A2A em abril de 2025, a proposta era clara: agentes de IA construídos por diferentes fornecedores, frameworks e equipes precisavam de uma maneira padrão de se comunicar. O protocolo prometia descoberta de agentes, delegação de tarefas, troca de mensagens, atualizações em streaming e compartilhamento de artefatos. A reação, no entanto, foi consideravelmente menos limpa do que o anúncio.

Alguns desenvolvedores viam o A2A como a camada agente-para-agente faltante para a stack agêntica emergente. Outros viam-no como mais um protocolo da Google, mais uma sigla e mais um tentativa de definir um mercado antes que o mercado tivesse necessidades reais de produção. A visão cética resumia-se a uma única pergunta: “Já temos o MCP. Por que precisamos do A2A?” Esta era uma pergunta justa em 2025, e permanece uma pergunta justa em 2026 — embora a resposta tenha mudado consideravelmente.

Dois sistemas de agentes de IA conectados pela ponte do protocolo A2A

O A2A não está morto, mas também não é universalmente útil. A realidade prática é que o A2A está se tornando genuinamente valioso em um contexto específico: onde os agentes são sistemas independentes com sua própria propriedade, ferramentas e limites de confiança, em vez de apenas funções internas ou wrappers de ferramentas. Essa distinção entre integração de ferramentas e delegação de agentes é o que o protocolo realmente foi projetado para abordar, e entendê-la é a chave para avaliar o A2A sem o hype em qualquer direção.

O que é o Protocolo A2A da Google?

A2A significa Protocolo Agent2Agent, e esse nome captura precisamente seu propósito. É um padrão aberto para comunicação e interoperabilidade entre sistemas independentes de agentes de IA — especificamente, agentes que podem ser construídos usando diferentes frameworks, linguagens ou stacks de fornecedores.

O A2A não trata principalmente de conectar um agente a um banco de dados, sistema de arquivos, calendário, API ou índice de busca. Isso está mais próximo do trabalho do MCP, o Protocolo de Contexto do Modelo (Model Context Protocol). O A2A trata de algo diferente: um agente comunicando-se com outro agente, tratando o sistema par como um ator com suas próprias capacidades, em vez de uma fonte de dados passiva.

Um fluxo típico do A2A pode envolver:

Descoberta de um agente através de um Agent Card (Cartão de Agente)
Leitura das habilidades e capacidades do agente
Envio de uma tarefa
Troca de mensagens
Recebimento de atualizações de status
Manipulação de estados que exigem entrada
Recebimento de artefatos finais
Rastreamento de conclusão, falha ou cancelamento

A palavra importante nessa lista é “tarefa”. O A2A não é apenas uma chamada de função com um wrapper diferente — é um protocolo de ciclo de vida de tarefas para colaboração entre agentes, projetado para lidar com todo o arco desde a descoberta e delegação até a execução, atualizações de status e retorno de artefatos. Para uma análise técnica aprofundada de cada conceito — Agent Cards, ciclo de vida de tarefas, mensagens, partes e artefatos — consulte O que é o Protocolo A2A? Agent Cards e Tarefas Explicados. Para entender como o streaming, notificações push e pausas com humano no loop funcionam em produção, consulte Streaming e Tarefas Assíncronas do A2A para Fluxos de Trabalho Longos de Agentes.

Por que o A2A Era Fácil de Zombar

O A2A chegou a um mercado já afogado em siglas de agentes.

Em 2025, os desenvolvedores já lidavam com:

APIs de LLM
Chamada de funções (Function calling)
Chamada de ferramentas (Tool calling)
Frameworks de agentes
Servidores MCP
Pipelines RAG
Motores de fluxo de trabalho (Workflow engines)
Bibliotecas de orquestração multi-agente
Protocolos JSON personalizados
Sistemas de plugins internos

Então, quando a Google anunciou o A2A, uma reação comum foi previsível:

“Realmente precisamos de mais um padrão?”

O ceticismo não era irracional, e veio de várias direções ao mesmo tempo. O A2A parecia sobrepor-se ao MCP. Veio da Google, o que fez alguns desenvolvedores se preocuparem com o compromisso a longo prazo. Chegou antes que a maioria das equipes tivesse resolvido o acesso básico a ferramentas, injeção de prompts, observabilidade, controle de custos e segurança para sistemas de agente único.

Nesse ambiente, a “interoperabilidade agente-para-agente” soava ambiciosa, mas também um pouco prematura.

E para ser franco, muitos demos de agentes de IA em 2025 não precisavam do A2A de forma alguma.

Eles precisavam de melhores prompts, melhores ferramentas, melhores permissões, melhor lógica de retry (tentativa novamente) e melhores logs.

A Atualização de 2026: O A2A Não Está Morto

A grande mudança em 2026 é que o A2A não é mais apenas um anúncio da Google.

Em abril de 2026, a Linux Foundation relatou que o projeto A2A havia ultrapassado 150 organizações apoiadoras, ganhado integrações com principais plataformas em nuvem e alcançado implantações em produção em várias indústrias.

Isso não significa que cada afirmação deva ser engolida sem ceticismo. “Apoiado por” não é a mesma coisa que “usado profundamente em produção pela maioria dos desenvolvedores”. Os ecossistemas de protocolos muitas vezes parecem maiores em releases de imprensa do que se sentem no trabalho de engenharia do dia a dia.

O sinal importa, no entanto, porque é mais difícil de descartar. O A2A cruzou uma linha importante: não é mais apenas um post de blog da Google. Tem uma especificação formal, impulso de governança, exemplos públicos, trabalho em SDKs, atenção de plataformas em nuvem e um ecossistema crescente em torno da interoperabilidade de agentes. Isso torna a etiqueta de “morto” difícil de defender por motivos técnicos ou de adoção.

Uma crítica mais defensável é que o A2A está vivo, mas seu escopo útil é mais estreito do que o hype sugere.

A2A vs MCP: A Confusão Que Não Morria

A maioria da confusão sobre o A2A vem de sua relação com o MCP.

O MCP, criado pela Anthropic, padroniza como aplicações de IA se conectam a ferramentas e fontes de dados externas. Os servidores MCP expõem ferramentas, recursos e prompts. Hospedeiros e clientes de IA os consomem.

Em termos simples:

O MCP conecta agentes a ferramentas.
O A2A conecta agentes a outros agentes.

Isso soa limpo, mas o mundo real é consideravelmente mais bagunçado. Um servidor MCP pode expor algo que parece muito agêntico — por exemplo, uma ferramenta MCP chamada research_company que internamente executa busca, recuperação, resumo, classificação e escrita de relatórios. Do ponto de vista do hospedeiro MCP, é uma ferramenta. Do ponto de vista da arquitetura, está escondendo um fluxo de trabalho semelhante a um agente atrás de uma fronteira de chamada de função. Essa ambiguidade é precisamente por que alguns desenvolvedores argumentaram que o A2A era desnecessário: se um agente pode ser representado como uma ferramenta MCP, por que criar um protocolo separado?

A resposta é que o A2A dá estrutura de primeira classe para coisas que o MCP trata de forma mais desajeitada:

Descoberta de agentes
Capacidades de agentes
Ciclo de vida de tarefas
Trabalho de longa duração
Estado de tarefas multi-turno
Mensagens entre agentes
Artefatos
Colaboração entre agentes opacos
Delegação através de fronteiras organizacionais

O MCP pode encapsular muito, mas encapsular tudo como uma ferramenta eventualmente se torna uma má abstração. Em algum ponto, um sistema especialista tem estado, política, ciclo de vida e autoridade de tomada de decisão próprios suficientes que modelá-lo como uma ferramenta obscurece a arquitetura em vez de simplificá-la. Esse é o ponto de inflexão onde tratar um agente par como um agente par — em vez de como uma chamada de ferramenta — começa a pagar dividendos. Para uma comparação detalhada de onde a fronteira cai na prática, consulte A2A vs MCP: Agentes de IA Realmente Precisam de Ambos os Protocolos?

O Melhor Modelo Mental: MCP Abaixo, A2A Acima

A arquitetura mais limpa não é “A2A vs MCP”.

A arquitetura mais limpa é em camadas:

flowchart TD U["Usuário ou aplicação"] O["Assistente principal / orquestrador"] S1["Agente especialista A"] S2["Agente especialista B"] T1["Ferramentas, APIs, arquivos, bancos de dados"] T2["Mais ferramentas e fontes de dados"] U --> O O -->|A2A| S1 O -->|A2A| S2 S1 -->|MCP| T1 S2 -->|MCP| T2

Neste modelo:

O A2A é a camada de colaboração entre agentes.
O MCP é a camada de integração de ferramentas.

Este é o padrão que faz mais sentido em 2026, e é a estrutura que a maioria dos arquitetos de agentes sérios estão convergindo. O A2A não deve substituir o MCP, e o MCP não deve ser forçado a representar cada fronteira de agente — eles resolvem problemas diferentes em camadas diferentes da stack. A estrutura de “guerra de protocolos” é principalmente uma análise preguiçosa que faz bons manchetes enquanto não ajuda engenheiros a projetar sistemas melhores.

Onde o A2A é Realmente Útil

O A2A se torna útil quando um agente não é mais apenas uma chamada de biblioteca dentro da sua aplicação.

É útil quando os agentes são:

Implantados independentemente
Propriedade de diferentes equipes
Construídos com diferentes frameworks
Expostos por fornecedores
Executando com suas próprias ferramentas e permissões
Responsáveis por tarefas de longa duração
Retornando artefatos em vez de valores simples
Parte de um fluxo de trabalho multi-agente mais amplo

Por exemplo, imagine um assistente empresarial que precisa preparar um relatório de risco de fornecedores.

Pode delegar trabalho para:

Um agente de compras
Um agente de revisão legal
Um agente financeiro
Um agente de conformidade
Um agente de pesquisa de mercado
Um agente de escrita de relatórios

Cada agente tem seu próprio domínio, ferramentas, regras, permissões e requisitos de auditoria.

Para esse tipo de sistema, o A2A não é absurdo. É uma fronteira razoável.

O assistente principal não precisa ter acesso direto a cada banco de dados de compras, repositório de políticas legais, planilha financeira e fluxo de trabalho de conformidade. Ele deve pedir ao agente responsável para realizar a tarefa.

Essa é a distinção essencial: o acesso a ferramentas é uma conexão vertical entre um agente e seus recursos, enquanto a delegação de domínio é uma passagem horizontal entre agentes autônomos, cada um com sua própria fronteira de autoridade e responsabilidade. O modelo em camadas de como esses componentes se combinam — LLM, memória, ferramentas, roteamento e observabilidade — é coberto em Arquitetura de Assistente de IA: LLM, Memória, Ferramentas, Roteamento, Observabilidade.

Onde o A2A Ainda Está Superestimado

O A2A está superestimado quando as pessoas o apresentam como infraestrutura obrigatória para todos os projetos de IA.

A maioria dos projetos não precisa disso.

Se você está construindo um assistente de código local, um chatbot para seus documentos, um pequeno agente de automação interna ou um único fluxo de trabalho que chama algumas ferramentas, o A2A provavelmente é desnecessário.

Você pode precisar de:

MCP
Esquemas de ferramentas bons
Guardrails (Barreiras de segurança)
Avaliação
Logging (Registro de logs)
Controle de custos
Lógica de retry (Tentativa novamente)
Melhores prompts
Melhor recuperação (Retrieval)

Provavelmente, você não precisa de um protocolo completo de agente-para-agente.

O A2A pode ser um erro quando:

Há apenas um agente
Todos os componentes vivem em um único código-fonte
Os fluxos de trabalho são curtos e síncronos
Os agentes não precisam de descoberta
Os agentes não precisam de estado de tarefa independente
Não há provedores de agentes externos
Uma API ou fila seria mais simples
A equipe não consegue operar a complexidade extra

Um protocolo não é gratuito. Ele adiciona conceitos, modos de falha, sobrecarga de depuração, preocupações de segurança e trabalho operacional.

Em muitos sistemas pequenos, adotar o A2A é cosplay de arquitetura — emprestando o vocabulário de sistemas de agentes distribuídos sem nenhum dos problemas reais de fronteira que tornam o protocolo valioso.

O A2A e o Problema da Google

Parte do ceticismo do A2A vem da própria Google.

Os desenvolvedores têm memórias longas. Quando a Google lança uma plataforma, protocolo, produto ou ecossistema, muitos engenheiros imediatamente perguntam:

“Isso ainda existirá em três anos?”

Essa reação não é totalmente justa ao design técnico do A2A, mas é um fator real de adoção.

A história de hospedagem pela Linux Foundation ajuda aqui. O A2A se tornando parte de um ambiente de governança aberto mais amplo o torna menos dependente das prioridades internas da Google.

Isso não garante o sucesso. A governança aberta não cria magicamente adoção de desenvolvedores. Mas reduz uma das maiores preocupações: que o A2A é apenas uma jogada estratégica controlada pela Google.

Em 2026, o A2A deve ser julgado menos como “o protocolo da Google” e mais como um padrão emergente de interoperabilidade de agentes que a Google ajudou a iniciar.

Esta é uma lente mais saudável, e é a que torna os méritos técnicos do A2A mais fáceis de avaliar por conta própria, em vez de através do filtro do relacionamento histórico da Google com ecossistemas de desenvolvedores.

Adoção: Sinal Forte, Mas Não Toda a História

As 150+ organizações apoiadoras relatadas são significativas, mas não devem ser confundidas com adoção universal pelos desenvolvedores. “Apoiado por” é um espectro, não binário, e ajuda ler afirmações de adoção com isso em mente.

No extremo mais fraco está a adoção de logotipo: uma empresa diz que apoia o padrão, o que pode refletir implementação genuína, posicionamento estratégico, um protótipo ou simplesmente apoio planejado que não se materializou. Um pouco mais forte é a adoção de SDK, onde os desenvolvedores realmente podem construir com bibliotecas, exemplos e documentação disponíveis — isso significa que o protocolo saiu dos slides para uma implementação funcional, e engenheiros reais acharam que valia seu tempo. Ainda mais forte é a adoção de plataforma, onde nuvens, frameworks de agentes e sistemas empresariais expõem suporte nativo real, tornando o A2A uma escolha arquitetural padrão plausível em vez de algo que as equipes tenham que conectar manualmente.

A única camada de adoção que realmente importa para a saúde a longo prazo do ecossistema é a retenção em produção. Para ter uma ideia de como as curvas de adoção real parecem no espaço de agentes de IA — medida em estrelas do GitHub, tokens do OpenRouter e tendências de downloads — os dados de popularidade do OpenClaw vs Hermes Agent mostram como rapidamente o impulso se constrói e se estabiliza uma vez que a energia dos primeiros adotadores diminui.: equipes que dependem do protocolo para fluxos de trabalho ao vivo além do período inicial de 90 dias de lua de mel. A atualização de 2026 da Linux Foundation afirma uso em produção em várias indústrias, o que é uma evidência significativa. Mas a pergunta mais útil não é “quem apoia o A2A?” — é “quem mantém o A2A em produção após o primeiro incidente operacional real?”. A retenção a longo prazo sob pressão é o sinal que separa a infraestrutura genuína do teatro de protocolos.

O Teste Real: Retenção em Produção

O hype de desenvolvedores é barato, e a retenção em produção é cara. Os dois raramente são proporcionais, o que é por que a pergunta sobre retenção de 90 dias importa mais do que o entusiasmo da semana de lançamento.

O A2A se provará se as equipes continuarem a usá-lo após encontrarem:

Problemas de autenticação
Problemas de autorização
Problemas de identidade de agente
Problemas de depuração
Casos de borda do ciclo de vida de tarefas
Falhas de streaming
Compatibilidade de versão
Diferenças entre fornecedores
Surpresas de custos
Revisões de segurança
Requisitos de auditoria
Fluxos de trabalho de aprovação humana

É aqui que muitos frameworks e protocolos de agentes falham. Eles parecem elegantes em diagramas, então se tornam dolorosos em produção.

O A2A tem uma boa razão para existir, mas boas razões não se traduzem automaticamente em resiliência de produção. O protocolo tem que sobreviver à realidade operacional que encontra no caminho do demo para a implantação.

O melhor sinal para o A2A em 2026 não é que as pessoas estão escrevendo posts de blog sobre ele. O melhor sinal é que empresas estão começando a usá-lo para fronteiras reais multi-agente.

O pior sinal seria se os desenvolvedores só o usassem em demos enquanto os sistemas de produção voltassem a APIs e filas personalizadas.

Segurança é a Maior Questão Não Resolvida

Os problemas mais difíceis do A2A não são problemas de sintaxe ou especificação. São problemas de confiança que emergem quando você realmente implanta agentes autônomos através de fronteiras organizacionais ou de sistema.

Quando um agente fala com outro agente, várias perguntas se tornam urgentes:

Quem é este agente?
Quem é o proprietário dele?
O que ele tem permissão para saber?
O que ele tem permissão para fazer?
Ele pode delegar trabalho ainda mais?
Ele pode chamar ferramentas em nome de um usuário?
Ele pode preservar a intenção do usuário?
Ele pode provar o que aconteceu?
Ele pode ser auditado após a conclusão da tarefa?

Essas perguntas não são opcionais em ambientes empresariais.

O A2A facilita a colaboração entre agentes. Ele também cria novos lugares onde a confiança pode quebrar.

Por exemplo:

Um agente malicioso poderia distorcer suas capacidades.
Um agente comprometido poderia solicitar contexto sensível.
Uma tarefa delegada poderia exceder a autoridade do usuário.
Um agente poderia retornar artefatos envenenados.
Uma cadeia de agentes poderia tornar a responsabilidade clara.
Dados sensíveis poderiam fluir através de fronteiras sem registro adequado.

É por isso que sistemas sérios de A2A precisam de mais do que conformidade com o protocolo.

Eles precisam de:

Identidade de agente forte
Autorização escopada
Logs de auditoria em nível de tarefa
Rastreamento de delegação
Aprovação humana para ações arriscadas
Proveniência de artefatos
Limites de taxa (Rate limits)
Aplicação de políticas
Observabilidade através de fronteiras de agentes

O A2A não é uma arquitetura de segurança por si só — é um protocolo de comunicação que deve ser implantado dentro de uma, com decisões explícitas feitas sobre identidade, autorização, auditoria e aplicação de política em cada fronteira que cruza. Segurança de Agentes A2A e MCP: Identidade, Delegação e Rastros de Auditoria descreve essa arquitetura circundante em detalhes.

O A2A e a Ideia de Marketplace de Agentes

Um dos casos de uso de longo prazo mais interessantes do A2A são os marketplaces de agentes.

Se os agentes podem anunciar capacidades através de Agent Cards, então outros agentes ou plataformas podem descobri-los, avaliá-los e enviar tarefas.

Isso cria um futuro possível onde as capacidades dos agentes se tornam mais modulares:

Um agente de impostos
Um agente legal
Um agente de revisão de código
Um agente de planejamento de viagens
Um agente de análise de segurança
Um agente de compras
Um agente de qualidade de dados

Cada um poderia expor uma interface padrão para colaboração baseada em tarefas.

Isso soa emocionante, mas também é onde o hype fica perigoso.

Um marketplace de agentes aberto precisa de mais do que Agent Cards. Precisa de identidade, reputação, faturamento, conformidade, sandboxing, responsabilidade, versionamento e resolução de disputas.

Sem esses, um marketplace de agentes se torna um incidente de segurança esperando para acontecer.

O A2A é um bloco de construção útil para esse tipo de futuro, mas é uma peça de um quebra-cabeça muito maior que também requer sistemas de identidade, mecanismos de reputação, infraestrutura de faturamento, controles de conformidade e resolução de disputas antes de se tornar um mercado seguro para operar.

O A2A para Agentes Empresariais Internos

O caso de uso de curto prazo mais realista não são marketplaces de agentes públicos.

São redes internas de agentes empresariais.

Grandes organizações já têm muitas fronteiras:

Equipes
Departamentos
Sistemas
Fornecedores
Domínios de dados
Zonas de conformidade
Políticas de segurança
Processos de aprovação

O A2A mapeia naturalmente nessas fronteiras, porque o protocolo é projetado em torno da mesma necessidade fundamental: comunicação estruturada entre sistemas que têm sua própria propriedade e não compartilham um código-fonte. O cluster mais amplo de Sistemas de IA cobre como agentes especialistas como Hermes e OpenClaw se encaixam nesse tipo de arquitetura em camadas na prática.

Em vez de construir um assistente gigante com acesso direto a tudo, uma empresa pode construir agentes especialistas com responsabilidade limitada:

Agente de RH
Agente financeiro
Agente de suporte
Agente de DevOps
Agente de segurança
Agente de gestão de conhecimento
Agente de plataforma de dados

Cada agente pode possuir suas ferramentas e políticas internamente. Outros agentes podem interagir com ele através do A2A.

Este é um modelo muito melhor do que dar a um único agente de propósito geral acesso direto a cada sistema na organização, tanto do ponto de vista de segurança quanto operacional. Cada agente especialista pode ser proprietário, operado, auditado e seguro independentemente, o que também torna o sistema geral mais fácil de raciocinar quando algo dá errado.

O A2A para Pequenas Equipes e Indie Hackers

Para pequenas equipes construindo produtos com um ou dois agentes, o A2A é genuinamente menos urgente — e muitas vezes uma distração de problemas mais imediatos. Provavelmente, você não precisa de um protocolo de agente-para-agente ainda.

Use código normal. Use APIs HTTP. Use filas. Use o MCP onde a integração de ferramentas importa.

Adicione o A2A quando você realmente tiver:

Múltiplos agentes independentes
Fronteiras de agentes de terceiros
Tarefas delegadas de longa duração
Requisitos de descoberta de agentes
Requisitos de troca de artefatos
Necessidades de interoperabilidade entre frameworks

A sequência importa mais do que a ambição. Comece com a arquitetura mais simples que expõe os pontos de pressão reais, e deixe esses pontos de pressão dizerem se você realmente precisa do A2A antes de se comprometer com a complexidade que ele traz. Para a maioria dos pequenos construtores, MCP primeiro e A2A depois é o caminho certo.

Um Framework de Decisão Prático

Use este framework ao decidir se o A2A pertence ao seu sistema.

Sem A2A quando o fluxo de trabalho é local. Evite o A2A quando tudo roda dentro de uma aplicação e os componentes não são implantáveis independentemente. Uma função Python, classe, serviço, fila ou motor de fluxo de trabalho provavelmente é suficiente.

MCP quando o agente precisa de ferramentas. Use o MCP quando seu agente precisar de acesso padronizado a arquivos, bancos de dados, APIs, sistemas SaaS, índices de busca, repositórios, documentação interna ou sistemas de observabilidade. O MCP dá valor prático imediato e é o ponto de partida certo para a maioria das equipes construindo agentes hoje.

A2A quando o agente precisa de pares. Use o A2A quando seu agente precisar se comunicar com outros agentes independentes — especialmente quando esses agentes têm suas próprias capacidades, políticas, estado, ferramentas, proprietários, ciclo de vida de implantação e fronteira de segurança.

Ambos quando a arquitetura tem camadas. Use ambos quando agentes especialistas colaboram entre si e cada especialista também precisa de ferramentas. O padrão de produção é A2A entre agentes e MCP entre agentes e ferramentas. Esta é a versão mais sensata da stack de protocolos de agentes de 2026, e a arquitetura que mapeia mais limpa em como os sistemas multi-agente de produção estão realmente sendo construídos.

Erros Comuns com o A2A

Usar o A2A porque soa estratégico. Esta é a armadilha clássica da arquitetura empresarial. O A2A deve resolver um problema real de fronteira que existe na arquitetura, não um inventado para justificar a escolha do protocolo. Se não há uma fronteira genuína — nenhuma implantação independente, nenhuma propriedade separada, nenhuma fronteira de segurança distinta — provavelmente não há necessidade de A2A.

Tratar MCP e A2A como concorrentes. O MCP não está obsoleto porque o A2A existe, e o A2A não é desnecessário porque o MCP existe. Eles abordam problemas estruturais diferentes e funcionam melhor como camadas complementares, não como alternativas concorrentes.

Expor cada capacidade como um agente. Uma calculadora não precisa ser um agente. Uma API do tempo não precisa ser um agente. Uma consulta de banco de dados não precisa ser um agente. Muitas coisas são ferramentas straightforward (diretas), e a abstração de agente adiciona sobrecarga sem adicionar clareza quando aplicada a componentes que não têm autonomia, estado ou ciclo de vida significativo próprios.

Esconder um agente completo atrás de uma única ferramenta. O erro oposto também é comum. Se uma “ferramenta” tem seu próprio ciclo de vida de tarefas, memória, políticas, artefatos e comportamento de delegação, ela pode merecer ser modelada como um agente em vez de ser esmagada atrás de uma fronteira de chamada de função.

Ignorar a observabilidade. Sistemas multi-agente sem rastros são dolorosos de depurar e impossíveis de auditar. Você precisa saber qual agente recebeu a tarefa, quais mensagens foram trocadas, quais ferramentas foram chamadas, quais artefatos foram produzidos, quais políticas foram aplicadas e qual agente tomou a decisão final. Sem essa visibilidade, a depuração se torna arqueologia — reconstruindo o que aconteceu por inferência em vez de observação. A stack completa de observabilidade para sistemas alimentados por IA e LLM, incluindo métricas, rastros distribuídos e SLOs que abrangem fronteiras de agentes, é coberta em Observabilidade para Sistemas LLM: Métricas, Rastros, Logs e Testes em Produção.

Então, o A2A Está Superestimado?

Sim, parcialmente. O A2A está superestimado quando é apresentado como o padrão inevitável para todos os sistemas de agentes de IA, quando as pessoas implicam que cada desenvolvedor precisa adotá-lo imediatamente, quando demos de agentes usam o A2A para coordenar o que poderia ter sido três chamadas de função, ou quando a discussão do protocolo ignora identidade, autorização, observabilidade e operações de produção. Estes são exemplos reais de hype que fazem o A2A soar mais universal do que é.

Mas superestimado não significa inútil. Muitas tecnologias importantes são superestimadas antes de se tornarem infraestrutura entediante, e o hype muitas vezes chega bem antes que o ecossistema esteja maduro o suficiente para apoiá-lo. A pergunta real não é se o marketing é excessivo — claramente é às vezes. A pergunta real é se a abstração subjacente é útil, e para o A2A, a resposta é sim quando os agentes se tornam atores genuinamente independentes em um sistema com fronteiras reais, propriedade real e apostas reais.

Então, o A2A Está Morto?

Não.

O argumento de que “o A2A está morto” fazia mais sentido durante a fase inicial de ceticismo, quando o protocolo parecia uma resposta liderada pela Google ao impulso do MCP.

Em 2026, esse argumento é mais fraco.

O A2A tem uma especificação formal, suporte de ecossistema, impulso da Linux Foundation, atenção de grandes nuvens e implantações de produção relatadas.

Nada disso torna o A2A dominante, obrigatório ou universalmente amado pela comunidade de desenvolvedores — mas claramente não está morto. Uma afirmação melhor é que o A2A está vivo e ainda provando seu valor de produção além de ecossistemas empresariais e de plataforma, onde a maioria das implantações confirmadas atualmente vive.

Então, o A2A Finalmente é Útil em 2026?

Sim, mas apenas na arquitetura certa. O A2A é útil quando seu sistema tem fronteiras reais de agentes — não apenas porque seu código tem múltiplos prompts, ou porque seu sistema usa a palavra “agente” em nomes de variáveis. Ele se torna útil quando a colaboração entre agentes genuinamente precisa de estrutura padrão:

Descoberta
Capacidades
Ciclo de vida de tarefas
Mensagens
Artefatos
Trabalho de longa duração
Fronteiras de implementação opaca
Interoperabilidade entre fornecedores

É aí que o A2A ganha seu lugar, fornecendo um contrato comum para colaboração que de outra forma exigiria trabalho de protocolo personalizado em cada fronteira.

Minha Opinião Opinativa

O A2A não é o protocolo com que a maioria dos desenvolvedores deve começar — o MCP é. O MCP resolve um problema mais imediato e amplamente aplicável: conectar agentes a ferramentas e contexto úteis. O A2A resolve um problema de estágio posterior: conectar agentes independentes uns aos outros através de fronteiras reais de implantação e propriedade. Isso torna o MCP mais útil hoje para a vasta maioria dos desenvolvedores individuais e pequenas equipes.

O A2A pode se tornar mais importante à medida que os sistemas de agentes amadurecem de demos para fluxos de trabalho empresariais. Uma vez que as organizações tenham múltiplos agentes especialistas pertencentes a diferentes equipes, a necessidade de uma fronteira padrão agente-para-agente se torna óbvia e a sobrecarga do protocolo começa a pagar por si mesma.

Minha recomendação prática é começar com o MCP, projetar fronteiras de agentes limpas desde o início e adicionar o A2A apenas quando essas fronteiras se tornarem restrições reais de implantação, propriedade ou interoperabilidade. Não adote o A2A por “vibes” (impressões/sensações). Adote-o quando a arquitetura exigir.

Veredito Final

O protocolo A2A da Google não está morto.

Também não é o futuro universal de cada projeto de agente de IA.

É um protocolo útil, ainda em amadurecimento, para um problema específico: comunicação entre agentes de IA independentes.

Se você está construindo um assistente simples, o A2A provavelmente é desnecessário.

Se você está construindo um sistema empresarial multi-agente, um marketplace de agentes, uma rede de agentes neutra a fornecedores ou um conjunto de agentes especialistas implantados independentemente, o A2A merece atenção séria.

A melhor estrutura de 2026 não é:

A2A vs MCP

É:

MCP para ferramentas.
A2A para agentes.
Ambos para sistemas sérios multi-agente.

Isso é menos dramático do que uma narrativa de guerra de protocolos, mas também é mais preciso e mais útil para engenheiros que precisam tomar decisões arquitetônicas reais.