A2A: O Protocolo Horizontal que Completa o MCP

Em junho eu escrevi aqui que MCP por default é erro, e a mensagem mais interessante que recebi depois daquele post não foi de discordância. Foi de um arquiteto de uma seguradora dizendo que ele tinha exatamente o problema oposto: não estava expondo MCP demais, estava tentando espremer dentro de servidor MCP uma coisa que claramente não era ferramenta. Era um sistema inteiro, de outro time, com seu próprio banco, sua própria política de aprovação e seu próprio ciclo de release. E ele queria que o agente do time dele pedisse trabalho para aquele sistema.

Eu conheço bem esse desconforto. Já modelei "agente de revisão de contrato" como uma tool MCP chamada review_contract, com schema de entrada bonitinho, e passei duas semanas percebendo que a abstração estava mentindo. Aquilo não era uma função. Demorava quarenta minutos, pedia informação no meio do caminho, produzia artefatos parciais e às vezes se recusava a fazer o trabalho porque o contrato estava fora do escopo dela. Nada disso cabe num tools/call.

O A2A existe para essa fronteira. Anunciado pelo Google em abril de 2025 no Cloud Next e doado à Linux Foundation ainda em 2025, o protocolo fechou o primeiro ano com um anúncio difícil de ignorar: mais de 150 organizações apoiando o padrão, integração nativa em Google Cloud, Azure AI Foundry, Copilot Studio e Amazon Bedrock AgentCore, e uso em produção em supply chain, serviços financeiros, seguros e operações de TI. Saiu de pouco mais de 50 parceiros no lançamento para 150 e poucos em doze meses, com 22 mil estrelas no repositório e SDKs em cinco linguagens.

Este post é o irmão daquele de junho. Lá eu argumentei contra adotar MCP por reflexo. Aqui quero fazer o mesmo com o A2A, que é um protocolo consideravelmente mais bonito no papel — e por isso mais perigoso. Vou cobrir o que ele resolve que o MCP não resolve, como a stack de dois níveis funciona na prática, o que nenhum dos dois consegue expressar, e quando você realmente precisa dele. Antecipando a conclusão: a maioria dos times não precisa.

O Que o A2A Resolve Que o MCP Não Resolve

A frase de efeito é "MCP conecta agente a ferramenta, A2A conecta agente a agente". Está certa e é quase inútil, porque a pergunta que importa é quando uma coisa deixa de ser ferramenta e vira agente. Um servidor MCP pode expor uma tool research_company que por dentro faz busca, recuperação, sumarização, ranking e redação de relatório. Do ponto de vista do host MCP, é uma tool. Do ponto de vista arquitetural, é um agente escondido atrás de uma fronteira de função.

O que o A2A dá de primeira classe são quatro coisas que o MCP trata de forma desajeitada ou não trata.

Descoberta de agente. Todo agente A2A publica um Agent Card em /.well-known/agent-card.json. Um cliente busca esse documento e descobre o que aquele agente faz, quais modalidades aceita, quais mecanismos de autenticação exige e onde mandar as requisições. Não existe equivalente no MCP: você configura o servidor na mão ou o encontra num registry. O MCP tem descoberta de capacidades dentro de uma conexão já estabelecida; o A2A tem descoberta de contraparte antes de existir conexão.

Delegação de tarefa com ciclo de vida. No MCP você chama uma tool e recebe uma resposta. No A2A você submete uma Task, com identificador próprio e uma máquina de estados definida pela spec: TASK_STATE_SUBMITTED, TASK_STATE_WORKING, TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED, mais dois estados interrompidos — TASK_STATE_INPUT_REQUIRED e TASK_STATE_AUTH_REQUIRED — e um TASK_STATE_REJECTED para quando o agente remoto decide que não vai fazer aquilo. Esse último é subestimado. Uma tool não recusa trabalho; um agente com política própria recusa. Modelar recusa dentro de uma chamada de função te obriga a inventar contrato de erro; no A2A é estado nativo.

Negociação de modalidade. O Agent Card declara defaultInputModes e defaultOutputModes como listas de MIME types, e cada skill pode sobrescrever com inputModes e outputModes próprios. Dois agentes acertam, antes de trocar qualquer conteúdo, que um manda application/json e o outro devolve image/png. Parece detalhe de spec, mas é o que evita a situação clássica de um agente devolver um blob que o outro não sabe interpretar.

Tarefas longas. A2A suporta três modos de entrega: request/response síncrono sobre JSON-RPC 2.0, streaming via Server-Sent Events, e push notification via webhook para delegação fire-and-forget, declarados em capabilities.streaming e capabilities.pushNotifications. Um "consulte o cadastro deste cliente" volta em milissegundos; um "analise este contrato de duzentas páginas" sobe para SSE e entrega parciais ao longo de minutos; um "reconcilie o fechamento do mês" some por três horas e avisa por webhook. Mesmo protocolo, três perfis de latência.

Nenhuma dessas quatro coisas é impossível de construir em cima de MCP ou de uma API REST comum. Todas são chatas de construir, e todas viram contrato proprietário que só o seu time entende. É o mesmo argumento que sustentou o MCP como padrão aberto na camada de baixo, aplicado uma camada acima.

O Agent Card, e Por Que Metade do Que Você Leu Sobre Ele Está Desatualizado

Vale olhar o objeto de perto, porque ele é o coração do protocolo e mudou de forma na versão 1.0.

{
  "name": "Supplier Risk Analyst",
  "description": "Avalia risco de fornecedores combinando histórico de compliance, saúde financeira e exposição regulatória. Retorna parecer com nível de risco, evidências e ressalvas.",
  "supportedInterfaces": [
    {
      "url": "https://risk-agent.exemplo.com.br/a2a/v1",
      "protocolBinding": "JSONRPC",
      "protocolVersion": "1.0"
    },
    {
      "url": "https://risk-agent.exemplo.com.br/a2a/grpc",
      "protocolBinding": "GRPC",
      "protocolVersion": "1.0"
    }
  ],
  "provider": {
    "organization": "Risco e Compliance Corporativo",
    "url": "https://compliance.exemplo.com.br"
  },
  "version": "2.4.0",
  "documentationUrl": "https://compliance.exemplo.com.br/docs/risk-agent",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true,
    "extendedAgentCard": true
  },
  "securitySchemes": {
    "corp-idp": {
      "openIdConnectSecurityScheme": {
        "openIdConnectUrl": "https://idp.exemplo.com.br/.well-known/openid-configuration"
      }
    }
  },
  "securityRequirements": [
    { "schemes": { "corp-idp": { "list": ["openid", "risk.read", "risk.assess"] } } }
  ],
  "defaultInputModes": ["application/json", "text/plain"],
  "defaultOutputModes": ["application/json", "text/markdown"],
  "skills": [
    {
      "id": "supplier-risk-assessment",
      "name": "Avaliação de Risco de Fornecedor",
      "description": "Produz parecer de risco para um CNPJ, considerando histórico de sanções, indicadores financeiros e exposição setorial.",
      "tags": ["risco", "compliance", "fornecedor", "due-diligence"],
      "examples": [
        "Avalie o risco do fornecedor CNPJ 00.000.000/0001-00 para contrato de 24 meses.",
        "{\"cnpj\": \"00000000000100\", \"contractValueBRL\": 4200000, \"horizonMonths\": 24}"
      ],
      "inputModes": ["application/json"],
      "outputModes": ["application/json", "text/markdown"]
    }
  ],
  "signatures": [
    {
      "protected": "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpPU0UiLCJraWQiOiJrZXktMSJ9",
      "signature": "QFdkNLNszlGj3z3u0YQGt_T9LixY3qtdQpZmsTdDHDe3fXV9y9"
    }
  ]
}

Três observações, e a segunda é a que mais dá dor de cabeça em revisão de arquitetura.

Primeiro, ele é um contrato público que descreve intenção, não implementação. Quem consome esse card não sabe se do outro lado tem um LangGraph, um CrewAI, um monólito Java com um LLM pendurado ou um estagiário muito rápido. Essa opacidade é design deliberado e é o que torna colaboração entre organizações viável: você delega para um agente de terceiro sem que ele conheça seus sistemas internos. O preço é que debugar fluxo distribuído vira correlação de log na camada de aplicação, porque o protocolo não te deixa espiar dentro do outro lado.

Segundo, o formato mudou. Muito material publicado sobre A2A ainda mostra Agent Card com url e preferredTransport no topo, e task states em minúsculas com hífen — input-required, auth-required. Isso é a versão 0.x. Na spec 1.0 esses campos sumiram: transporte vive dentro do array supportedInterfaces, security virou securityRequirements, supportsAuthenticatedExtendedCard virou capabilities.extendedAgentCard, e os enums de estado seguem ProtoJSON em SCREAMING_SNAKE_CASE. Se você está avaliando A2A com base em post de meados de 2025, está avaliando um protocolo que não existe mais nessa forma.

Terceiro, o campo signatures. Agent Cards podem ser assinados com JWS, o que permite verificar que o card não foi adulterado no caminho — importante quando ele chega via registry, CDN ou qualquer intermediário. Ainda não é universal na prática, mas aceitar card não assinado de terceiro é uma suposição de confiança fácil de deixar passar e cara de descobrir depois.

A Stack de Dois Níveis Na Prática

A divisão de responsabilidades consolidou-se ao longo de 2026: MCP embaixo, para integração vertical entre agente e suas ferramentas; A2A em cima, para coordenação horizontal entre agentes. Google ADK, Salesforce Agentforce e ServiceNow Now Assist implementam os dois. A própria Linux Foundation, no anúncio de aniversário do A2A, descreve os protocolos como complementares e não concorrentes — os dois estão sob a mesma fundação, o que ajuda a credibilidade da narrativa.

O exemplo mais concreto que encontrei documentado é o da PayPal, descrito pela Atlan: um agente de vendas recebe uma solicitação em linguagem natural, usa A2A para localizar e autenticar um agente de pagamento fornecido pela PayPal a partir do Agent Card dele, e delega a criação da fatura. O agente de pagamento então usa um cliente MCP para chamar as ferramentas de pagamento subjacentes. O handshake horizontal atravessa a fronteira entre as duas empresas; a integração vertical acontece inteira dentro da PayPal. Nenhum dos lados expõe ferramenta interna para o outro.

Traduzindo para um cenário mais comum: um assistente corporativo precisa montar um parecer de risco de fornecedor. Ele delega, via A2A, para um agente de compras, um jurídico, um financeiro e um de compliance — cada um de um time diferente, com seu próprio deploy, suas permissões e sua trilha de auditoria. Cada um deles usa MCP internamente para falar com o ERP, com o repositório de contratos, com o data warehouse. O assistente nunca recebe acesso direto ao banco de contratos jurídicos. Ele pede ao responsável.

O que faz o desenho valer a pena não é a elegância do diagrama: é o modelo de autoridade. A alternativa comum — um agente generalista com credencial para tudo — concentra risco de um jeito que quem já passou por auditoria reconhece como problema. Segmentar por agente especialista, cada um dono das próprias ferramentas e políticas, é decisão de segurança antes de ser decisão de arquitetura. É a mesma linha de raciocínio de segurança e autenticação em servidores MCP, um nível acima.

A tabela abaixo é como eu resumo a diferença quando alguém pergunta em revisão de design:

O ponto da tabela não é escolher uma coluna. É notar que quase nenhuma linha é comparável de verdade — os dois protocolos respondem perguntas distintas. Tratar isso como "guerra de protocolos" é análise preguiçosa que rende manchete e não ajuda ninguém a desenhar sistema.

O Que Nenhum Dos Protocolos Consegue Expressar

Aqui é onde o entusiasmo precisa parar, e felizmente já existe trabalho sério mapeando o buraco.

Um paper de junho de 2026, "Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express", de Richard Kang e Yudho Diponegoro, analisa cinco protocolos — MCP v1.1, A2A v1.0.1, ACP, ANP e ERC-8004 — contra uma taxonomia de seis dimensões de governança: associação (quem participa), deliberação (como argumentos são trocados e contestados), votação (como posições são resolvidas), preservação de dissenso (como a visão minoritária sobrevive), escalonamento humano (quando a autoridade humana é invocada) e auditoria/replay (como o processo é reconstruível).

O resultado é desconfortável. Votação, preservação de dissenso e escalonamento humano estão ausentes nos cinco protocolos. Deliberação é ausente ou, no máximo, parcial. O A2A pontua 1 de 12 na matriz de cobertura dos autores: Partial só em associação, porque Agent Cards aproximam uma noção de membro por capacidade declarada, e Absent em todo o resto — inclusive auditoria, já que a extensão Traceability adiciona correlation IDs para tracing distribuído mas não define log à prova de adulteração nem semântica de replay. O MCP também pontua 1 de 12.

A distinção que os autores fazem é a que mais importa para quem desenha sistema: coordenação não é governança. Os protocolos resolvem identidade, declaração de capacidade, descoberta, troca de mensagem e reputação. Eles não resolvem "como cinco agentes decidem coletivamente se esta arquitetura atende requisito de compliance". Você pode transportar mensagens de governança como payload opaco dentro de uma task A2A, mas o protocolo não consegue interpretar, validar ou impor a semântica delas. Toda aplicação reimplementa do zero.

Tem um detalhe no paper que achei especialmente honesto. O A2A tem um mecanismo de extensão que explicitamente suporta "novos dados, requisitos, métodos RPC e máquinas de estado" — ou seja, primitivas de governança poderiam ser definidas como extensão. A observação seguinte é a que pesa: depois de mais de seis meses de A2A publicamente disponível, com ecossistema de extensão ativo, zero extensões de governança foram propostas ou implementadas. As quatro oficiais existentes (Secure Passport, Timestamp, Traceability, Agent Gateway Protocol) não tocam no assunto. A lacuna não é técnica. É de prioridade.

Na prática isso vira uma lista de perguntas que todo time enfrenta ao colocar agentes atravessando fronteira: quem é este agente, quem é dono dele, o que ele pode saber e fazer, ele pode subdelegar, ele pode chamar ferramenta em nome de um usuário, dá para provar o que aconteceu depois. O A2A responde parcialmente a duas. As outras são trabalho seu.

Autorização fina é o caso mais óbvio. Todos os protocolos tratam autenticação — quem é você — e nenhum trata autorização com a granularidade que compliance corporativo exige. Acesso a ferramenta por papel, concessão de capacidade com prazo, cadeia de delegação com restrição: tudo camada de aplicação. Quando o agente A delega para o B, os tokens de B deveriam codificar "B agindo em nome de A agindo em nome do usuário U"; a extensão on-behalf-of do OAuth é o padrão emergente e ainda não é universalmente implementada. O mesmo vale para observabilidade: nenhum protocolo exige log estruturado ou OpenTelemetry, e sistema multi-agente sem trace transforma debugging em arqueologia.

Quando Você Precisa Mesmo de A2A — E Quando é Arquitetura de Vitrine

Vou ser direto: a maioria dos times que está discutindo A2A hoje não precisa dele.

Se você tem um assistente de código local, um chatbot sobre a sua documentação, uma automação interna que chama meia dúzia de ferramentas ou um único fluxo síncrono, você não precisa de protocolo agente-a-agente. Precisa de MCP bem feito, schemas de ferramenta decentes, guardrails, avaliação, logging, controle de custo e retry. Nada disso melhora porque você adicionou uma máquina de estados de task no meio.

O sinal de que A2A não cabe é consistente: existe só um agente; todos os componentes vivem no mesmo repositório; os workflows são curtos e síncronos; não há necessidade de descoberta; não existe provedor externo de agente; uma fila ou uma API resolveria; o time não tem fôlego para operar a complexidade extra. Nesses casos, adotar A2A é arquitetura de vitrine — pegar emprestado o vocabulário de sistemas distribuídos sem ter nenhum dos problemas de fronteira que tornam o protocolo valioso.

O sinal inverso é sobre fronteira real, não sobre quantidade de prompts. A2A começa a pagar quando os agentes são deployados de forma independente, pertencem a times diferentes, foram construídos com frameworks diferentes, rodam com ferramentas e permissões próprias, são responsáveis por tarefas longas, devolvem artefatos em vez de valores simples, ou vêm de fornecedor externo. Se três ou mais desses itens são verdade, a conversa deixa de ser hype.

O caso realista no curto prazo não é marketplace público de agentes — isso precisa de identidade, reputação, billing, compliance, sandbox, responsabilidade civil e resolução de disputa muito antes de precisar de Agent Card. É rede interna de agentes corporativos, porque a empresa grande já tem as fronteiras prontas: times, departamentos, sistemas, fornecedores, domínios de dado, zonas de compliance, processos de aprovação.

Duas armadilhas simétricas valem menção. A primeira é expor tudo como agente: uma calculadora não é agente, uma API de clima não é agente, uma query de banco não é agente. A segunda é o erro do meu conhecido da seguradora — esconder um agente inteiro atrás de uma tool. Se a sua "ferramenta" tem ciclo de vida de tarefa, memória, política própria, artefatos e comportamento de delegação, ela provavelmente merece ser modelada como agente.

Do lado dos frameworks, LangGraph e CrewAI já têm suporte a A2A, o que permite que agentes de plataformas diferentes trabalhem juntos e deleguem subtarefas sem compartilhar memória interna. Se você está escolhendo entre LangGraph e CrewAI para agentes em produção, a decisão de framework não te tranca fora do A2A — mas suporte no framework não é razão para adotar. É só remoção de atrito.

Protocolos Concorrentes e a Tese de Convergência

O A2A não está sozinho, e vale entender o mapa antes de apostar.

O ACP (Agent Communication Protocol), do coletivo AGNTCY com Cisco, LangChain, LlamaIndex, Dell, Oracle e Red Hat, também sob a Linux Foundation, tem filosofia oposta: pega REST HTTP padrão e adiciona o mínimo. POST para criar tarefa, GET para status, DELETE para cancelar, tudo em OpenAPI, sem SDK obrigatório. A vantagem é atrito zero para quem já opera gateway de API. As desvantagens são registry centralizado como ponto único de falha, streaming na camada de aplicação e modelo de task menos expressivo. Onde ganha é conteúdo multimodal: o formato de mensagem usa multipart MIME nativamente.

O ANP (Agent Network Protocol) é a aposta descentralizada, com W3C DIDs para identidade e roteamento em grafo sem registry central. Tecnicamente é o modelo de confiança mais robusto disponível, porque resolve o bootstrap entre partes sem relacionamento prévio. Na prática, a infraestrutura de resolver DID ainda amadurece e a negociação de meta-protocolo adiciona latência em toda conexão. É aposta de dois a três anos, não de deploy este trimestre.

A tese de convergência tem base concreta e limite honesto. A base é governança: MCP, A2A e ACP estão todos sob a Linux Foundation. Grupo de trabalho conjunto e compromisso de interoperabilidade não eram possíveis quando cada protocolo era controlado por um vendor concorrente. Some a convergência de transporte (HTTP para todo mundo), de segurança (OAuth 2.1 com PKCE) e de descoberta (a convenção /.well-known/), e o desenho de dois níveis vira padrão de referência de fato.

O limite é que descoberta em escala continua sem solução — Agent Card te diz como falar com um agente que você já conhece, não como achar o agente certo entre milhares. E interoperabilidade entre protocolos ainda não existe: um agente A2A não delega nativamente para um agente ACP num ciclo de vida unificado. Existe conversa sobre uma especificação conjunta entre membros da fundação, mas até onde consegui verificar não há draft oficial publicado — trate como intenção declarada, não como roadmap com data.

Vale registrar também que "apoiado por" é um espectro. Logo em página institucional é a ponta fraca; SDK utilizável é mais forte; suporte nativo em cloud é mais forte ainda. A camada que importa de verdade é retenção em produção: times que continuam usando o protocolo depois do primeiro incidente operacional sério, do primeiro problema de identidade de agente, da primeira revisão de segurança que pede trilha de auditoria que o protocolo não fornece. A pergunta útil não é quem apoia A2A — é quem mantém A2A em produção depois de noventa dias.

O Protocolo Certo Para a Fronteira Que Você Realmente Tem

O A2A é um protocolo bem desenhado. O ciclo de vida de task é mais honesto que qualquer contrato de função que eu já escrevi para o mesmo problema, o Agent Card resolve descoberta de um jeito que dá para explicar em cinco minutos, e a opacidade por design é o que torna colaboração entre empresas plausível em vez de teórica. Nada disso é marketing.

E nada disso importa se o seu sistema não tem a fronteira que justifica o protocolo. O erro que cometi com MCP no ano passado — usar em tudo porque descobri que funciona — é o mesmo que vejo se formando com A2A agora, com a diferença de que o custo é maior, porque coordenação distribuída erra de formas que integração vertical não erra. Servidor MCP desnecessário é infraestrutura extra. Malha de agentes desnecessária é infraestrutura extra mais uma classe inteira de modos de falha que você não precisava ter.

A heurística que tenho usado não é sofisticada: comece com MCP, desenhe fronteiras de agente limpas desde o início, e adote A2A quando essas fronteiras virarem restrição real de deploy, de propriedade ou de interoperabilidade. Não porque soa estratégico numa revisão de arquitetura, nem porque o framework que você escolheu tem um checkbox de suporte. E mesmo aí, entrando com a consciência de que o que os protocolos entregam é coordenação, não governança: autorização fina, cadeia de delegação, trilha de auditoria e escalonamento para humano continuam sendo trabalho seu, independentemente de quantas organizações assinaram embaixo do padrão.

Fontes:

• Linux Foundation — A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year
• Agent2Agent (A2A) Protocol Specification — versão 1.0
• Kang & Diponegoro — Governance Gaps in Agent Interoperability Protocols: What MCP, A2A, and ACP Cannot Express (arXiv:2606.31498)
• Zylos Research — Agent Interoperability Protocols 2026: MCP, A2A, ACP and the Path to Convergence
• Rost Glukhov — Google A2A Protocol in 2026: Adoption, Hype, and Reality
• Atlan — What Is Google's A2A Protocol?
• OneReach — MCP vs. A2A: The Protocols Powering Multi-Agent Collaboration