2026 foi o ano em que os agentes de IA pararam de viver em ilhas. O "aperto de mão" entre agentes de fornecedores diferentes — que até ontem era promessa de slide — virou disponibilidade geral. Dois padrões dividiram o palco: o MCP (Model Context Protocol), criado pela Anthropic e hoje sob a Linux Foundation, com mais de 10.000 servidores públicos e cerca de 97 milhões de downloads de SDK por mês, é o canal agente→ferramenta; o A2A (Agent2Agent), doado pelo Google à Linux Foundation e com mais de 150 parceiros — Salesforce, SAP, ServiceNow, Microsoft e AWS entre eles —, é o canal agente→agente.
Na mesma semana a foto ficou concreta: a SAP liberou A2A inbound em GA (um agente de terceiro já invoca um agente SAP pelo Agent Gateway), a Salesforce posicionou o Agent Fabric e o AgentExchange como registro de "connected agents", e Atlassian e Interact soltaram seus MCP servers abrindo 700+ capacidades a qualquer agente. O padrão venceu. Mas há uma confusão cara circulando nas salas de arquitetura — e é sobre ela que este artigo é.
O que mudou: A2A e MCP viraram GA em 2026 — e quem adotou
Interoperabilidade de agentes de IA deixou de ser uma aposta e virou infraestrutura. O MCP padroniza como um agente descobre e chama uma ferramenta (uma API, um banco, um sistema) sem que você escreva um conector sob medida para cada uma. O A2A padroniza como um agente invoca outro agente — inclusive de um fornecedor diferente — passando tarefa, contexto e resultado por um envelope comum.
A adesão foi em bloco. Os grandes fornecedores de enterprise se comprometeram com os dois padrões ao mesmo tempo, porque um não substitui o outro: um é para ferramentas, o outro é para agentes. O resultado prático é que, em tese, o agente de atendimento que você construiu sobre uma plataforma já consegue "falar" com o agente de pricing de outra, e ambos conseguem puxar dados de um terceiro sistema via MCP. É um avanço real.
A2A vs MCP: o que cada protocolo resolve (e o que não resolve)
Vale fixar a divisão de trabalho, porque é aqui que mora o mal-entendido:
- MCP (agente→ferramenta): dá ao agente uma forma padronizada de listar e executar capacidades de um sistema. Resolve o "plugue" entre um agente e as ferramentas.
- A2A (agente→agente): dá a dois agentes uma forma padronizada de trocar tarefas e resultados. Resolve o "plugue" entre agentes.
Repare na palavra que se repete: plugue. Os dois protocolos padronizam o encaixe. Nenhum dos dois padroniza a operação — e é a operação, entre fornecedores diferentes, que continua sem dono. Um dado desconfortável ajuda a enxergar o tamanho do buraco: estima-se que 53% dos MCP servers ainda dependem de credencial estática em vez de OAuth, e um único CVE no utilitário mcp-remote expôs centenas de milhares de instalações. O padrão venceu; a governança não acompanhou.
Os 4 buracos que o protocolo não cobre entre fornecedores
Quando uma tarefa real cruza agentes de três ou quatro donos diferentes, quatro perguntas aparecem — e nenhuma é respondida pelo A2A ou pelo MCP:
- Descoberta. Qual agente existe lá fora, de quem é e o que ele pode fazer? Há specs nascendo (a SAP, por exemplo, usa o ARD, Agentic Resource Discovery), mas não existe um catálogo cross-vendor confiável. Você ainda decide o que registrar, onde e para quem.
- Identidade e autorização. Quem é esse agente externo que acabou de bater na porta, e com que escopo ele pode agir? "Descoberta não concede permissão de invocar" — a frase é da própria SAP, e vale para todo mundo. Identidade de agente, trust e ACL são trabalho de engenharia, não um campo do protocolo.
- Custo. Cada gateway cobra o seu — uns por ação, outros por crédito, outros por assento. Não existe visão consolidada. Uma tarefa que atravessou quatro fornecedores gera quatro faturas em quatro moedas, e ninguém te mostra o total.
- Observabilidade. Como você rastreia, ponta a ponta, uma tarefa que começou no seu agente, passou por um agente de um parceiro e terminou chamando uma ferramenta de um terceiro? O rastro se perde exatamente nas fronteiras onde o protocolo entrega e dá tchau.
Interop ≠ orquestração: por que a malha cross-vendor é engenharia, não checkbox
Aqui está a virada de chave do artigo: interoperabilidade você ganha de graça; orquestração você constrói. "Adotamos A2A e MCP" resolve o encaixe. Não resolve quem descobre o agente certo, quem autoriza o agente externo, quanto custou e como rastrear. Essa camada — que roteia, autoriza, mede e observa a malha de agentes de donos diferentes — é a orquestração vendor-neutral, e ela não vem no protocolo.
É a mesma fronteira que vimos sob outras faces nas últimas semanas: a segurança da borda, a procedência do dado, a economia do loop de inferência, e quem controla o portão (abre, fecha ou cobra pedágio). Hoje a face é o agente invocando agente através dos fornecedores. E a lição se repete: o protocolo é condição necessária, nunca suficiente.
Como a CCX constrói a camada de orquestração vendor-neutral
É exatamente aqui que a CCX atua — sem eleger plataforma. A tese é 100% transferível: não importa qual fornecedor você use, a malha entre eles é sua para orquestrar.
Com Integrações & APIs Enterprise e MuleSoft (Anypoint, API-led connectivity, incluindo a A2A bridge que liga quem fala A2A ao que não fala), a CCX monta a camada que faz a descoberta, o roteamento e a autorização dos agentes externos — e expõe suas próprias capacidades via A2A/MCP com escopo controlado. Arquiteturas event-driven com Kafka e RabbitMQ sustentam o fluxo quando a tarefa precisa cruzar CRM, ERP, e-commerce e legado.
Com Observabilidade 360° (Datadog, Grafana, Prometheus, Sentry, tracing distribuído com OpenTelemetry), você ganha o rastro e o custo cross-vendor de uma tarefa que atravessa agentes de donos diferentes — a visão consolidada que nenhum gateway de fornecedor entrega sozinho. E com Consultoria em Tecnologia a CCX desenha a arquitetura de interop: o que expor via A2A, o que via MCP, o que manter fechado, e a estratégia de identidade e autorização do agente externo.
A2A e MCP padronizaram o aperto de mão entre agentes — mas descoberta, identidade, custo e rastro cross-vendor seguem sem dono. A CCX constrói a camada de orquestração vendor-neutral (Integrações & APIs + MuleSoft) e a visão cross-vendor de custo e rastro (Observabilidade 360°). Interop você ganha de graça; orquestração você constrói. Conheça as soluções de integração da CCX →
Perguntas frequentes
A2A substitui o MCP? Não. São complementares: MCP conecta agente a ferramenta; A2A conecta agente a agente. A maioria das arquiteturas enterprise vai usar os dois.
Se todo mundo adotou os dois, a integração está resolvida? O encaixe sim. A operação não — descoberta, identidade/autorização, custo e observabilidade entre fornecedores continuam sendo engenharia sua.
Como governo um agente externo que invoca o meu? Com uma camada de identidade e autorização (quem é, com que escopo) e um ponto único de roteamento e auditoria. É o que a camada API-led sobre MuleSoft entrega.
Quanto custa uma tarefa que cruza vários fornecedores? Depende de cada gateway — e por padrão você não enxerga o total. Uma camada de observabilidade cross-vendor é o que transforma faturas dispersas em custo consolidado por tarefa.