Protocolos Agent-to-Agent: como MCP e A2A estão redefinindo a interoperabilidade multi-agente

Há seis meses, 'sistema multi-agente' significava uma malha artesanal de endpoints HTTP sustentada por adaptadores, lógica de retentativa e fé. Hoje, dois protocolos estão mudando isso: Model Context Protocol (MCP) e Agent-to-Agent (A2A). Resolvem problemas diferentes, compõem-se de forma elegante e a maioria dos times já está implementando-os errado.

O problema de interoperabilidade que ninguém queria resolver

Nos últimos dois anos, todo time sério de IA redescobriu a mesma dor: os agentes não falam com nada de forma padronizada. Cada framework — LangChain, LlamaIndex, AutoGen, CrewAI — inventou sua própria convenção de invocação de ferramentas. Cada fornecedor lançou seu próprio esquema JSON de 'function calling'. Resultado: toda integração era sob medida, toda migração era uma reescrita, e todo 'sistema multi-agente' era na verdade um único framework fingindo ser muitos agentes.

A indústria já viveu isso antes. Tivemos SOAP até REST padronizar a comunicação serviço-a-serviço. Tivemos formatos proprietários de container até o OCI padronizar o runtime. Tivemos orquestração presa ao fornecedor até o Kubernetes. A camada agêntica era o próximo lugar esperando seu protocolo — e agora tem dois.

MCP: o USB-C do tooling de agentes

Model Context Protocol (MCP) responde uma pergunta específica: como um agente descobre e invoca as ferramentas, recursos e prompts disponíveis? A analogia que pegou — e pegou por uma boa razão — é USB-C. Qualquer cliente compatível com MCP pode se conectar a qualquer servidor MCP compatível sem código de cola sob medida.

Um servidor MCP expõe três primitivas: tools (funções que o agente pode chamar), resources (dados que o agente pode ler) e prompts (instruções com template que o servidor pode injetar). O transporte é JSON-RPC 2.0, normalmente sobre stdio para servidores locais ou HTTP com Server-Sent Events para remotos. Só isso. A simplicidade é o ponto.

• Um agente, muitos servidores MCP: seu agente de código baseado em Claude pode se conectar simultaneamente a um servidor MCP do GitHub, um do Postgres, um do filesystem e um interno do Jira — sem uma única linha de adapter custom.
• Controle de capacidades no lado do servidor: o servidor MCP define o que o agente pode ver e fazer. Você não entrega credenciais ao agente; roda o servidor com essas credenciais e expõe uma superfície de ferramentas restrita.
• Contexto componível: os resources do MCP permitem que um agente puxe contexto fresco (arquivos, linhas de banco de dados, respostas de API) no momento do raciocínio, em vez de carregar tudo no system prompt.
• Sem lock-in de SDK: MCP é um protocolo de rede. Você pode escrever um servidor em Python, Rust, TypeScript, Go ou qualquer linguagem que fale JSON-RPC.

Na Xcapit construímos agentes de IA onde toda capacidade externa vive atrás de um servidor MCP. Não é uma escolha estilística — é de governança. Quando uma ferramenta vive atrás de um servidor MCP, você tem um único ponto auditável para autorização, rate limiting e logging. Quando vive dentro do código do agente, você não tem nada disso.

A2A: o protocolo para quando um agente só não basta

Agent-to-Agent (A2A) resolve um problema que MCP nunca foi pensado para resolver: como dois agentes — possivelmente de fornecedores diferentes, construídos em frameworks diferentes, rodando modelos diferentes — negociam, delegam e colaboram em uma tarefa? A2A trata cada agente como um serviço peer com uma 'agent card' descobrível (capacidades, requisitos de autenticação, habilidades) e define os formatos de mensagem para o ciclo de vida de uma tarefa: submitted → working → input-required → completed → failed.

O protocolo é deliberadamente conservador no que padroniza. Não prescreve como um agente raciocina, que modelo usa ou como planeja. Padroniza apenas as bordas onde os agentes se encontram: identidade, handoff de tarefas, streaming de estado, troca de artifacts. Tudo interno ao agente continua sendo sua decisão de implementação. E está exatamente certo.

• Agent Cards: um documento JSON público em /.well-known/agent.json declarando o que um agente pode fazer, como autenticar e que habilidades expõe. A descoberta fica trivial.
• Ciclo de vida de tarefas tipado: toda troca A2A é uma Task com uma máquina de estados definida. Acabam os loops de polling ad-hoc e retries de webhook não documentados.
• Streaming por padrão: trabalho agêntico de longa duração emite atualizações de estado e artifacts parciais via SSE. Sua UI não finge que o agente é uma função síncrona.
• Cross-vendor por design: um agente construído sobre Claude pode invocar um agente construído sobre Gemini, que por sua vez invoca um construído sobre um modelo aberto — sem nenhum deles conhecer os internos dos outros.

A composição: MCP dentro, A2A fora

O modelo mental que encaixa para todo time que acompanhamos: MCP é como um agente alcança suas capacidades. A2A é como um agente alcança outros agentes. Vivem em planos diferentes da arquitetura, e um sistema maduro usa os dois.

Concretamente, em um projeto recente entregamos um sistema de revisão de documentos legais com quatro agentes: um agente de Intake (Python, Claude Sonnet), um Clause Analyzer (Rust, Claude Opus), um Compliance Checker (TypeScript, modelo aberto fine-tuned) e um Summarizer (Python, Gemini). Cada agente expõe suas habilidades via A2A. Cada agente internamente alcança suas ferramentas — busca vetorial, OCR, registros de compliance, armazenamento documental — via MCP. O orquestrador não sabe como nenhum agente funciona; apenas envia tarefas e recebe resultados por streaming. Os agentes não sabem sobre o que seus peers rodam; chamam-se entre si pelo agent card.

Esse desacoplamento é o que faz a arquitetura sobreviver aos próximos dois anos. Quando o Gemini 3 sair ou o DeepSeek R2 bater todos em extração de cláusulas, você troca os internos do Clause Analyzer. Nada mais muda. Sem reescrita de orquestrador, sem migração de banco, sem sprint do 'platform team'.

Erros que aprendemos da forma difícil

• Não coloque lógica de negócio no servidor MCP. É uma borda de protocolo, não uma camada de domínio. Regras de domínio ficam no serviço atrás do servidor MCP, não nas definições de ferramentas.
• Não pule a identidade do agente. Um caller A2A precisa se autenticar, e a autenticação precisa ser serviço-a-serviço (mTLS, OIDC client credentials, JWTs assinados), não 'uma API key no header' reaproveitada dos seus tempos de REST.
• Não logue apenas a resposta final. Para toda tarefa A2A, logue o histórico completo de transições de estado e cada chamada a ferramenta MCP com seus argumentos. Quando um agente alucina uma decisão, você precisa reconstruir o caminho do raciocínio — e só pode fazer isso se capturou.
• Não misture camadas de transporte arbitrariamente. Servidores MCP sobre stdio servem para tooling de desenvolvedor; os de produção devem ser HTTP+SSE com auth adequada. A2A deve sempre ser HTTPS com agent cards assinadas.
• Não exponha tudo. Um agente poder chamar qualquer ferramenta MCP não significa que deva. Aplique menor privilégio no servidor: um Clause Analyzer não precisa de acesso de escrita ao seu CRM.
• Não construa um 'orquestrador' custom antes de tentar A2A. O primeiro instinto é escrever um agente supervisor com lógica de delegação hardcoded. O modelo de tarefas A2A, com agent cards adequadas, normalmente substitui 80% desse código.

O que vem a seguir

Três movimentos já estão visíveis no ecossistema. Primeiro, MCP está absorvendo primitivas de governança — metadata de autorização, declarações de rate limit, estimativas de custo — que o tornam um backbone viável para setores regulados, não apenas tooling de desenvolvedor. Segundo, A2A está desenvolvendo um modelo de delegação de autoridade para que o agente B possa agir em nome do agente A com escopo limitado, que é a peça faltante para workflows agênticos cross-organização. Terceiro, a camada de verificação: agent cards assinadas, artifacts de tarefas assinados e atestações on-chain das ações de agentes — que é a ponte para agentes de IA verificáveis e a conversa sobre governança que José Trajtenberg escreve separadamente.

A verdade desconfortável é que a maioria das empresas construindo sistemas de agentes hoje está escrevendo código que vai estar obsoleto em dezoito meses. Não porque os agentes estejam errados — porque a cola entre eles é sob medida. Se você está arquitetando um sistema multi-agente em 2026, a pergunta não é mais 'qual framework?' — é 'quais protocolos, e como os governo?'.

Se seu time está avaliando MCP, A2A ou como envolver os dois em uma camada de governança production-grade, vamos conversar. Já cometemos os erros para que seu time não precise.