MCP e A2A sob o mesmo teto: o que times de agentes devem adotar em 2026

Durante um bom tempo, a pergunta em reunião de arquitetura era “MCP ou A2A?”. Em outubro de 2026 ela ficou meio ultrapassada. Os dois protocolos estão hoje sob a mesma fundação, e resolvem problemas diferentes. Isso não significa que a escolha ficou trivial. Vou mostrar o que mudou e o que eu adotaria em um time de agentes.

Dois protocolos, duas camadas

O MCP conecta um agente às suas ferramentas e dados. O A2A conecta agentes entre si. A própria Linux Foundation descreve o A2A como complementar ao MCP: um cobre a comunicação entre agentes de organizações diferentes, o outro cobre o acesso a ferramentas e fontes internas.

Uma comparação do MarkTechPost chega à mesma divisão: MCP como interface padrão para ferramentas e dados, A2A como transporte e ciclo de vida das chamadas entre agentes. Na prática, não há disputa direta a vencer.

O que mudou na governança

Em 9 de dezembro de 2025, a Linux Foundation criou a Agentic AI Foundation (AAIF) com três projetos fundadores: o MCP, da Anthropic, o goose, da Block, e o AGENTS.md, da OpenAI. Entre os membros platinum estão AWS, Google, Microsoft, Anthropic e OpenAI. Na época, o comunicado já falava em mais de 10 mil servidores MCP publicados.

Em agosto de 2026, o Google levou o A2A para a mesma fundação. Segundo o FlowHunt, a AAIF saiu de menos de 40 membros no lançamento para mais de 250, e o Axios também noticiou a mudança. As datas exatas variam entre as fontes, então tome o mês como referência.

O A2A já tinha tração antes disso. No balanço de um ano, a Linux Foundation reportou mais de 150 organizações apoiando o padrão, a versão 1.0 como primeira especificação estável (com Signed Agent Cards para verificar identidade) e integrações na Azure AI Foundry, no Copilot Studio e no Amazon Bedrock AgentCore Runtime. São números autodeclarados, vale lembrar.

Governança comum não é segurança comum

Foi por isso que tirei “fim da guerra” do título. O FlowHunt faz a ressalva certa: fundação compartilhada não resolve interoperabilidade sozinha. Cada plataforma ainda precisa implementar a especificação direito, e o time ainda precisa cuidar de identidade, isolamento e validação de ferramentas.

Um caso recente mostra o risco. O Unite.ai publicou em 5 de outubro a pesquisa de Syed Anas Mohiuddin sobre SSRF em servidores MCP: o servidor monta requisições a partir de URLs fornecidas pelo agente, sem checar para onde elas resolvem. Entre os afetados está o mcp-toolbox do Google (CVE-2026-14540, severidade alta, corrigido na v1.5.0).

O mesmo trabalho descreve o “protocol pivoting”. Um texto no formato de tarefa A2A entra na saída de uma ferramenta MCP, o agente orquestrador repassa a um subagente, e o subagente executa porque confia no orquestrador. Cada protocolo está correto isoladamente, e o problema aparece na confiança entre eles.

O que adotar em 2026

Minha leitura, como opinião e não como regra:

1. Comece pelo MCP. Se o agente precisa de ferramentas e dados, é ele que resolve, e o ecossistema é grande.
2. Adote o A2A quando houver agentes de times ou empresas diferentes que precisam conversar. Com um único agente, ele só acrescenta complexidade.
3. Trate toda saída de ferramenta como entrada não confiável, inclusive quando ela vem de dentro do sistema.
4. Endureça seus servidores MCP: valide o IP no momento da conexão, bloqueie faixas privadas e endereços de metadata de nuvem, use allowlist de hosts e redija respostas upstream antes de gravar logs. Essas são as medidas que decorrem das correções descritas na pesquisa.
5. Exija identidade verificável entre agentes. Os Signed Agent Cards da v1.0 do A2A existem para isso.

Conclusão

A fundação comum reduz o risco de ficar preso a um padrão que morre, mas a segurança entre protocolos continua sendo trabalho seu. Qual dos dois está hoje no centro da sua arquitetura de agentes? Conte nos comentários, e acompanhe o blog para os próximos guias sobre MCP e integrações.