MCP e A2A conectam agentes — mas não resolvem a operação

Fato confirmado — dois protocolos ocupam camadas diferentes

O Model Context Protocol, MCP, organiza a ligação entre agentes e recursos externos. Ele permite que uma aplicação descubra ferramentas, dados e capacidades por uma interface comum. O Agent2Agent, A2A, atua em outra direção: descreve como agentes independentes se apresentam, negociam capacidades, delegam tarefas e acompanham resultados.

A Linux Foundation define os padrões como complementares. MCP conecta agentes a ferramentas e fontes de dados; A2A coordena agentes entre plataformas e organizações. A distinção é importante porque uma empresa pode adotar um sem precisar transformar toda integração em uma conversa entre agentes.

Fato confirmado — o MCP foi redesenhado para a escala empresarial

A especificação MCP publicada em 28 de julho de 2026 substituiu o núcleo bidirecional e orientado a sessões por um desenho sem estado. Cada solicitação pode ser autodescritiva e chegar a qualquer instância atrás de um balanceador comum. Nome do método e da ferramenta também podem viajar em cabeçalhos, permitindo que gateways roteiem e apliquem políticas sem interpretar todo o conteúdo.

A versão também introduziu resultados de listas armazenáveis em cache, requisições com múltiplas idas e voltas e uma estrutura formal de extensões. São mudanças de infraestrutura: melhoram disponibilidade, elasticidade e operação distribuída, mas não garantem que uma ferramenta seja legítima ou que a ação pedida seja apropriada.

Fato confirmado — A2A saiu do laboratório e entrou nas plataformas

Em abril de 2026, a Linux Foundation informou que o A2A havia ultrapassado 150 organizações apoiadoras, alcançado a versão estável 1.0 e sido integrado a plataformas da Microsoft e da AWS. A especificação inclui cartões de agente, negociação de versões, comunicação estruturada e mecanismos para verificar identidade declarada.

SAP, Microsoft e AWS documentam arquiteturas nas quais A2A coordena agentes enquanto MCP expõe ferramentas. A adoção por fornecedores diferentes reduz a necessidade de integrações proprietárias para cada combinação, mas não comprova que todos os produtos sejam equivalentes nem que a interoperabilidade funcione sem testes entre implementações.

Análise — compatibilidade não é governança

Um protocolo define como uma mensagem viaja e como uma capacidade é descrita. Ele não decide se o agente deveria acessar aquele cliente, alterar aquele registro ou enviar aquela proposta. Também não define sozinho quem assume responsabilidade por uma tarefa delegada entre fornecedores.

A consequência operacional é direta: conectar ficou mais fácil; controlar ficou mais importante. Cada conexão precisa de identidade, política de autorização, escopo de dados, limite de ação, tratamento de erro, registro de evidência e responsável humano ou institucional.

Interoperabilidade remove o atrito da conexão. Governança impede que a conexão remova o controle.

Análise — a empresa precisa de contratos acima do protocolo

Dois agentes podem trocar mensagens válidas e ainda discordar sobre o que significa cliente ativo, receita reconhecida, prioridade alta ou tarefa concluída. A sintaxe comum não substitui definições empresariais, regras de qualidade e critérios de aceite.

A arquitetura precisa de contratos operacionais acima do protocolo: esquema de entrada e saída, vocabulário compartilhado, responsável pelo dado, prazo, idempotência, condições de repetição e evidência mínima para considerar uma ação concluída. Sem isso, a rede apenas distribui ambiguidade com mais velocidade.

Fato confirmado — as próprias especificações tratam ferramentas como risco

A especificação MCP afirma que o protocolo pode abrir caminhos para acesso arbitrário a dados e execução de código. Entre seus princípios estão consentimento explícito, controle do usuário, proteção de dados e cautela com descrições de ferramentas, que devem ser tratadas como não confiáveis quando a origem não é segura.

A NSA e a Coalition for Secure AI publicaram orientações específicas para MCP em 2026. Os documentos descrevem riscos de credenciais, injeção, ferramentas maliciosas, vazamento de dados, excesso de escopo e implementações inseguras. O protocolo fornece uma linguagem comum; segurança depende da forma como hosts, servidores, gateways e políticas são construídos.

Uma arquitetura operacional em sete controles

O primeiro controle é inventário: quais agentes, servidores MCP, ferramentas e proprietários existem. O segundo é identidade verificável para cada agente e serviço. O terceiro é autorização por tarefa, recurso e usuário. O quarto é validação de esquema e significado. O quinto é limite de tempo, custo, volume e efeito externo. O sexto é aprovação determinística para ações críticas. O sétimo é observabilidade ponta a ponta.

Uma execução relevante deveria produzir um recibo: quem solicitou, qual agente recebeu, qual capacidade foi descoberta, quais ferramentas foram usadas, quais políticas autorizaram a ação, qual resultado foi aceito e como reverter o efeito. O protocolo transporta partes desse fluxo; a empresa precisa preservar a cadeia inteira.

Análise — gateways podem se tornar o novo plano de controle

O desenho sem estado do MCP facilita que gateways leiam cabeçalhos, distribuam tráfego e apliquem políticas. Na prática, isso cria um ponto possível para autenticação, autorização, limitação de taxa, inspeção de esquema, bloqueio de ferramentas e geração de logs.

Concentrar controle também cria dependência e risco sistêmico. Um gateway mal configurado pode conceder acesso excessivo a muitos agentes de uma vez. Por isso, políticas precisam ser versionadas, testadas e separadas por ambiente, domínio e criticidade.

Inferência — o mercado caminha para uma rede de capacidades

A inferência editorial da Fluxia Intelligence é que aplicações empresariais serão cada vez menos avaliadas apenas pela interface e cada vez mais pela qualidade das capacidades que conseguem expor a agentes de forma segura. Produtos com APIs bem definidas, dados governados e ações reversíveis estarão em posição melhor para participar dessa rede.

Isso não significa que agentes substituirão integrações tradicionais. APIs, filas, eventos e automações determinísticas continuarão sendo a base de muitos processos. MCP e A2A adicionam uma camada de descoberta e coordenação quando a tarefa exige interpretação, negociação ou escolha dinâmica.

O que líderes devem decidir agora

Antes de adotar um catálogo de conectores, a empresa deve classificar ferramentas por leitura, preparação, execução reversível e ação crítica. Também precisa definir onde credenciais são armazenadas, como consentimento é registrado, quem aprova novas capacidades e como um agente é desativado sem interromper a operação.

A métrica útil não é quantidade de agentes conectados. É proporção de tarefas concluídas com política respeitada, evidência preservada, custo controlado e resultado aceito. Interoperabilidade cria alcance; maturidade aparece quando o alcance não destrói responsabilidade.

Limites e metodologia

As mudanças do MCP foram verificadas na especificação e no anúncio dos mantenedores. A função e a adoção declarada do A2A foram verificadas pela Linux Foundation e por documentações de fornecedores. As orientações de segurança foram confrontadas com documentos da NSA, da CoSAI e com cobertura independente da SecurityWeek.

Os números de adoção e downloads são informados pelas organizações responsáveis pelos projetos; não constituem auditoria independente de uso ativo. O modelo de sete controles e a tese sobre uma rede de capacidades são sínteses editoriais, não exigências oficiais dos protocolos.