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

O 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 tempo real (streaming) e compartilhamento de artefatos. A reação, no entanto, foi consideravelmente menos limpa do que o anúncio.

Alguns desenvolvedores viram o A2A como a camada faltante de agente-para-agente para a emergente pilha agêntica. Outros o viram como mais um protocolo da Google, mais uma sigla e mais uma 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?” Essa era uma pergunta justa em 2025, e continua sendo 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 compreendê-la é a chave para avaliar o A2A sem o hype em nenhuma das direções.

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 pilhas 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 é mais próximo do trabalho do MCP, o Model Context Protocol (Protocolo de Contexto do Modelo). O A2A trata de algo diferente: um agente se comunicando 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 de agentes, projetado para lidar com o arco completo, 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.

Por que o A2A era Fácil de Zombar

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

Em 2025, os desenvolvedores já lidavam com:

APIs de LLM
Function calling (chamadas de função)
Tool calling (chamadas de ferramentas)
Frameworks de agentes
Servidores MCP
Pipelines RAG
Motores de fluxo de trabalho
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 vinha de várias direções ao mesmo tempo. O A2A parecia se sobrepor 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 prompt, observabilidade, controle de custos e segurança para sistemas de agente único.

Nesse ambiente, “interoperabilidade agente-para-agente” soava ambicioso, mas também um pouco prematuro.

E para ser direto, muitos demos de agentes de IA em 2025 não precisavam do A2A de todo.

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

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, conquistado integrações em grandes plataformas de nuvem e atingido implantações em produção em várias indústrias.

Isso não significa que todas as alegações devam ser engolidas sem ceticismo. “Apoiado por” não é a mesma coisa que “usado profundamente em produção pela maioria dos desenvolvedores”. 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 de nuvem e um ecossistema crescente em torno da interoperabilidade de agentes. Isso torna o rótulo de “morto” difícil de defender em termos 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 maior parte da confusão sobre o A2A vem de seu relacionamento 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. Hospedes 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, sumarização, classificação e escrita de relatórios. Do ponto de vista do host do 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 o motivo pelo qual 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 desconfortável:

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 limites organizacionais

O MCP pode envolver muito, mas envolver 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 valer a pena. Para uma comparação detalhada de onde a fronteira cai na prática, consulte A2A vs MCP: Agentes de IA Realmente Precisam dos Dois 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 de agentes.
O MCP é a camada de integração de ferramentas.

Esse é o padrão que faz mais sentido em 2026, e é a estrutura que a maioria dos arquitetos de agentes sérios está 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 pilha. O enquadramento de “guerra de protocolos” é majoritariamente uma análise preguiçosa que faz bons manchetes enquanto não ajuda os engenheiros a projetar sistemas melhores.

Onde o A2A é Realmente Útil

O A2A torna-se ú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 fornecedor.

Ele 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 deve precisar de 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 que execute 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 transferência 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 é 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
Logs
Controle de custos
Lógica de retry
Prompts melhores
Recuperação melhor

Você provavelmente não precisa de um protocolo completo de agente-para-agente.

O A2A pode ser um erro quando:

Existe apenas um agente
Todos os componentes vivem em uma única base de código
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 sobre o A2A vem da própria Google.

Os desenvolvedores têm memória longa. 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 é inteiramente 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 tornar parte de um ambiente de governança aberta mais amplo o torna menos dependente das prioridades internas da Google.

Isso não garante sucesso. A governança aberta não cria magicamente adoção por desenvolvedores. Mas reduz uma das maiores preocupações: que o A2A seja 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.

Essa é uma lente mais saudável, e é a que torna mais fácil avaliar os méritos técnicos do A2A em seus próprios termos, em vez de através do filtro do relacionamento histórico da Google com ecossistemas de desenvolvedores.

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

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

Na ponta mais fraca 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 o tempo deles. 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 precisam 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 reais parecem no espaço de agentes de IA — medidas em estrelas do GitHub, tokens do OpenRouter e tendências de download — os dados de popularidade do OpenClaw vs Hermes Agent mostram como o impulso se constrói e se estabiliza rapidamente após a energia dos primeiros adotadores diminuir: equipes que dependem do protocolo para fluxos de trabalho ao vivo além da lua de mel inicial de 90 dias. A atualização de 2026 da Linux Foundation alega 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

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

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

Problemas de autenticação
Problemas de autorização
Problemas de identidade do 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 em 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 verdadeiras fronteiras multi-agentes.

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

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

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

Quando um agente fala com outro agente, várias questões se tornam urgentes:

Quem é este agente?
Quem o possui?
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 de agentes. Ele também cria novos lugares onde a confiança pode quebrar.

Por exemplo:

Um agente malicioso poderia falsificar 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
Execuçã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 tomadas sobre identidade, autorização, auditoria e execução de política em cada fronteira que cruza.

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 empolgante, mas também é onde o hype fica perigoso.

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

Sem isso, 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 para essas 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 uma base de código. 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 gerenciamento 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 todos os sistemas da organização, tanto do ponto de vista de segurança quanto operacional. Cada agente especialista pode ser possuído, operado, auditado e protegido independentemente, o que também torna o sistema geral mais fácil de raciocinar quando algo dá errado.

O A2A para Equipes Pequenas e Indie Hackers

Para equipes pequenas construindo produtos com um ou dois agentes, o A2A é genuinamente menos urgente — e muitas vezes uma distração de problemas mais imediatos. Você provavelmente 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 que esses pontos de pressão lhe digam se você realmente precisa do A2A antes de se comprometer com a complexidade que ele traz. Para a maioria dos construtores pequenos, 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.

Nenhum 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 uns com os outros e cada especialista também precisa de ferramentas. O padrão de produção é A2A entre agentes e MCP entre agentes e ferramentas. Essa é a versão mais sensata da pilha de protocolos de agentes de 2026, e a arquitetura que mapeia mais limpa para como os sistemas multi-agentes 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 de arquitetura empresarial. O A2A deve resolver um problema de fronteira real 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, nenhum perímetro de segurança distinto — provavelmente não há necessidade de A2A.

Tratar o MCP e o 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 de clima não precisa ser um agente. Uma consulta de banco de dados não precisa ser um agente. Muitas coisas são ferramentas straightforward (simples/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óprio.

Esconder um agente completo atrás de uma 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 espremida atrás de uma fronteira de chamada de função.

Ignorar a observabilidade. Sistemas multi-agentes sem traces (rastreamentos) 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 pilha completa de observabilidade para sistemas alimentados por IA e LLM, incluindo métricas, traces distribuídos e SLOs que atravessam fronteiras de agentes, é coberta em Observabilidade para Sistemas LLM: Métricas, Traces, Logs e Testes em Produção.

Então o A2A Está Superestimado?

Sim, parcialmente. O A2A é 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 seja maduro o suficiente para suportá-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 interesses reais.

Então o A2A Está Morto?

Não.

O argumento de que “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 do ecossistema, impulso da Linux Foundation, atenção de grandes nuvens e implantações em produção reportadas.

Nenhum 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 de 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 opacas
Interoperabilidade entre fornecedores

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

Minha Opinião

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 equipes pequenas.

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 possuídos por diferentes equipes, a necessidade de uma fronteira padrão de 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” (sensação/estilo). Adote-o quando a arquitetura exigir.

Veredito Final

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

Ele também não é o futuro universal de todos os projetos de agentes de IA.

É um protocolo útil, ainda em maturação, 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 em relação ao fornecedor ou um conjunto de agentes especialistas implantados independentemente, o A2A merece atenção séria.

O melhor enquadramento de 2026 não é:

A2A vs MCP

É:

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

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 arquiteturais reais.