Durante três décadas, integrar dois sistemas de fornecedores diferentes foi um exercício de tradução manual: cada API com seu formato, cada plataforma com seu jargão, cada conexão costurada à mão. Em 2026, pela primeira vez, os agentes de IA de fornecedores rivais passaram a se descobrir e delegar tarefas entre si de forma padronizada. O A2A (agent-to-agent), protocolo criado pelo Google e doado à Linux Foundation — com mais de 50 parceiros e as chamadas "Agent Cards" descrevendo capacidade, skill e endpoint de cada agente — somado ao MCP (Model Context Protocol), transformou o que era promessa em prática. Analistas chamaram o momento de "primeira interoperabilidade cross-vendor crível em três décadas".
A poucos dias da Dreamforce, com a Salesforce colocando o Claude dentro do CRM e a SAP fazendo o Joule conversar com o Microsoft 365 Copilot via A2A, o handoff entre agentes de fornecedores diferentes deixou de ser slide e virou fluxo em produção. Só que um paper acadêmico — "Governance Gaps in Agent Interoperability Protocols" — expôs o furo: MCP, A2A e ACP padronizam a comunicação, não quem-pode-chamar-quem, com qual permissão, sobre qual dado reconciliado. Este artigo é agnóstico de propósito: o fenômeno atravessa Google, Salesforce, SAP, Microsoft e Anthropic por igual — e a camada que falta, a da interoperabilidade governada, é a sua nova integração.
O que mudou: A2A na Linux Foundation, MCP e a interoperabilidade cross-vendor
Até ontem, um agente de IA vivia dentro do seu próprio jardim murado. O agente do CRM sabia do CRM; o agente do ERP, do ERP; e ligar um ao outro era projeto de integração ponto a ponto. O que mudou em 2026 foi a chegada de dois padrões complementares que quebram esse muro. O A2A define como um agente anuncia o que sabe fazer e como outro agente o encontra e delega uma tarefa — as Agent Cards funcionam como um "cartão de visita" legível por máquina: nome, capacidade, skill, endpoint. Ao ser doado à Linux Foundation, o A2A deixou de ser um projeto de um fornecedor e virou infraestrutura neutra, com mais de 50 organizações a bordo.
O MCP resolve um problema vizinho: como um agente acessa ferramentas, dados e contexto de forma padronizada. Juntos, os dois cobrem os dois lados da conversa — agente com agente (A2A) e agente com ferramenta (MCP). O efeito de rede é imediato: um agente escrito para a Salesforce pode, em tese, delegar uma etapa ao agente da SAP, que por sua vez passa o bastão a um agente da Microsoft. Não é ficção — a própria SAP demonstrou o Joule fazendo A2A com o Copilot. Pela primeira vez, a interoperabilidade não depende de cada par de fornecedores negociar uma ponte exclusiva.
Para quem opera tecnologia, isso é libertador e perigoso na mesma medida. Libertador porque derruba o custo de conectar ecossistemas que antes não se falavam. Perigoso porque a facilidade de conectar não vem acompanhada da disciplina de controlar o que cada conexão faz. E é exatamente aí que mora o mal-entendido do momento: confundir "os agentes já se falam" com "os agentes já estão sob controle".
A2A vs MCP: agente↔agente vs agente↔ferramenta, sem jargão
A confusão mais comum é tratar A2A e MCP como sinônimos ou como concorrentes. Não são. A forma mais simples de entender: o MCP é como um agente pega uma ferramenta na prateleira — ele padroniza o acesso a uma API, a um banco, a um documento. O A2A é como um agente pede ajuda a outro agente — ele padroniza a delegação de uma tarefa entre dois sistemas autônomos. Um é agente↔ferramenta; o outro é agente↔agente.
Na prática, os dois se somam. Imagine um agente de atendimento que precisa emitir uma segunda via de nota. Via MCP, ele acessa o sistema fiscal (a ferramenta). Se a emissão exige uma checagem de crédito que vive noutro ecossistema, via A2A ele delega essa checagem ao agente financeiro de um fornecedor diferente, recebe a resposta e conclui. O MCP conecta o agente às ferramentas dele; o A2A conecta o agente a outros agentes. É a combinação — não um ou outro — que cria o fluxo multi-fornecedor que o mercado celebrou nesta janela.
O ponto que quase ninguém sublinha: ambos os protocolos descrevem a mecânica da conversa — o formato da mensagem, como descobrir um endpoint, como estruturar uma tarefa. Nenhum dos dois foi desenhado para responder à pergunta que importa em produção: este agente tem permissão para pedir isto? Com qual credencial? Sobre qual versão do dado? Essa pergunta cai fora do escopo do protocolo — e cai no seu colo.
O furo que o protocolo não cobre: comunicação ≠ permissão ≠ governança
O paper "Governance Gaps in Agent Interoperability Protocols" formaliza o que engenheiros de integração já intuíam: padronizar a comunicação não é o mesmo que padronizar a autorização, e nenhum dos dois é o mesmo que governança. São três camadas distintas, e os protocolos de interoperabilidade só entregam a primeira.
Comunicação é o que A2A e MCP resolvem: dois agentes conseguem trocar mensagens estruturadas e um encontra o outro. Permissão é quem pode pedir o quê a quem — e essa decisão não vive no protocolo; vive na sua política de acesso. Governança é a camada mais ampla: rastreabilidade de cada delegação, credencial rotacionada por conexão, reconciliação do dado que trafega, trilha de auditoria de "qual agente mandou qual agente fazer o quê, e sob qual autoridade". Um Agent Card diz "eu sei emitir reembolso"; ele não diz "e só o agente X, autenticado como Y, pode me pedir isso, até o limite Z".
A consequência é direta. Quando você liga o agente do seu CRM ao agente do seu ERP via A2A, você ganhou um canal — e herdou uma pergunta de segurança que o protocolo não responde. Se a permissão não for desenhada por você, o padrão de fato vira "quem consegue falar, consegue pedir". Em um mundo de agentes que agem — movem dados, disparam APIs, aprovam transações — "quem consegue falar consegue pedir" é a receita para uma ação errada em escala, disparada por um handoff que ninguém revisou.
Por que o handoff automático vira risco quando falta escopo
Um agente só é útil quando age, e ele age através de conexões: lê um sistema, chama uma API, delega a outro agente. Enquanto tudo isso acontecia dentro de um único fornecedor, havia ao menos um perímetro comum de identidade e permissão. A interoperabilidade cross-vendor dissolve esse perímetro: agora o agente que age em nome da sua operação pode receber um pedido originado três saltos atrás, em um ecossistema que você não controla.
Pense num exemplo concreto. Um agente de compras (fornecedor A) recebe uma requisição, delega a validação de fornecedor a um agente de dados (fornecedor B) e o fechamento a um agente financeiro (fornecedor C). Se cada handoff apenas "confia" em quem chamou, basta um elo comprometido — ou um agente que leu uma instrução maliciosa embutida num documento — para que uma ordem indevida atravesse toda a cadeia com aparência de legítima. Não houve invasão de rede; houve uma delegação que ninguém restringiu. O protocolo entregou a conversa; a ausência de escopo entregou o dano.
Repare que essa lógica independe do fornecedor. Troque A2A por outro protocolo, troque a Salesforce pela SAP, troque o Copilot por qualquer agente: onde há delegação automática sem escopo, credencial e reconciliação, há risco. Endurecer um único modelo não resolve — a defesa que escala é a que trata cada conexão entre agentes como potencialmente hostil e desenha o handoff para conter, não só para funcionar.
A camada governada: Agent Cards com escopo, permissão por conexão, credencial e dado reconciliado
A boa notícia é que a camada que o A2A e o MCP não entregam é conhecida — é engenharia de integração madura, aplicada agora ao tráfego entre agentes. Quatro controles cobrem a maior parte do risco:
1. Agent Cards com escopo explícito. Não basta o cartão dizer "eu sei fazer X". Ele precisa carregar — e a sua camada precisa impor — quem pode pedir X, em qual contexto e até qual limite. O Agent Card descreve a capacidade; a política de escopo transforma capacidade em permissão condicionada.
2. Permissão por conexão (menor privilégio). Cada par agente↔agente recebe só o escopo mínimo necessário. Se o agente de atendimento só precisa consultar pedidos, ele não deveria conseguir aprovar reembolsos via delegação. Escopo estreito transforma um handoff comprometido em incidente pequeno, não em ação em cascata.
3. Credencial rotacionada por conexão. Cada delegação viaja com uma credencial de vida curta, girada com frequência e guardada cifrada — nunca um token eterno que, uma vez vazado, abre todas as portas entre ecossistemas. A rotação encurta a janela de qualquer chave capturada em trânsito entre fornecedores.
4. Dado reconciliado e contrato de API entre ecossistemas. Quando um agente delega a outro, os dois precisam concordar sobre qual dado — a versão, o significado, a fonte de verdade. Sem um contrato de API explícito e reconciliação, o agente A pede sobre um pedido que o agente C entende de outro jeito, e a automação amplifica a divergência. A camada de integração API-led (no estilo MuleSoft) é o que dá esse contrato e essa reconciliação.
Os quatro controles se reforçam: o escopo limita o que uma delegação sequestrada consegue tocar; a permissão por conexão isola cada par; a credencial curta encurta a vida de qualquer chave capturada; e o dado reconciliado impede que a automação propague uma divergência. Nenhum é bala de prata isolado — juntos, convertem "os agentes já se falam" em "os agentes só fazem o combinado, com quem tem autoridade, sobre o dado certo, e tudo fica registrado".
Como a CCX integra e governa a interoperabilidade entre agentes
Na CCX, a interoperabilidade entre agentes é tratada como um problema de integração enterprise — porque é. Pela frente de Integrações & APIs Enterprise, montamos a camada governada que o A2A e o MCP não entregam: arquitetura event-driven (Kafka/RabbitMQ), idempotência, acesso por conexão, webhooks assinados com HMAC-SHA256 e contratos de API explícitos entre ecossistemas — o mesmo padrão de engenharia que roda em produtos próprios da CCX, como o CCX Message (outbox pattern, idempotência de 24h, rotação de segredo). Pela frente de MuleSoft / API-led connectivity, damos a cada delegação entre agentes um contrato de API e uma fonte de verdade reconciliada, em vez de conexões ponto a ponto que ninguém audita.
Sobre essa base, a frente de Security Engineering & Cybersecurity aplica permissão por conexão e menor privilégio entre agentes (identity management, OAuth2, cofre de segredos, criptografia, pentest), e a frente de IA para Negócios coloca guardrail no próprio agente (RAG e orquestração com escopo), tudo com compliance LGPD/SOC 2. Uma squad dedicada (onboarding em 48h, engenheiros com 10+ anos) integra e opera o conjunto. O resultado é a interoperabilidade governada: seus agentes se descobrem e delegam via A2A/MCP, mas cada handoff carrega escopo, credencial rotacionada e dado reconciliado — a camada que o protocolo não entrega sozinho.
Quer governar a interoperabilidade dos seus agentes? Conheça as soluções da CCX — Agent Cards com escopo, permissão por conexão, credencial rotacionada e contrato de API entre ecossistemas. A integração API-led entre ecossistemas vive em Consultoria MuleSoft; o dado reconciliado que os agentes trocam, em Data & BI; e a IA aplicada com guardrail, em IA para Negócios.
Perguntas frequentes (FAQ)
O que é o protocolo A2A?
O A2A (agent-to-agent) é um protocolo aberto que padroniza como agentes de IA de fornecedores diferentes se descobrem e delegam tarefas entre si. Criado pelo Google e doado à Linux Foundation (com 50+ parceiros), usa "Agent Cards" para que cada agente anuncie capacidade, skill e endpoint de forma legível por máquina.
A2A é a mesma coisa que MCP?
Não. O MCP (Model Context Protocol) padroniza como um agente acessa ferramentas, dados e contexto — é agente↔ferramenta. O A2A padroniza como um agente delega uma tarefa a outro agente — é agente↔agente. Eles são complementares: juntos cobrem os dois lados da conversa em fluxos multi-fornecedor.
Como integrar agentes de IA de plataformas diferentes?
Adotar A2A/MCP resolve a comunicação, mas não a permissão nem a governança. Uma integração segura entre agentes exige uma camada própria: Agent Cards com escopo explícito, permissão por conexão (menor privilégio), credencial rotacionada por conexão e contrato de API com dado reconciliado entre os ecossistemas. É integração enterprise clássica aplicada ao tráfego entre agentes.
Quem controla a permissão de um agente que chama outro?
O protocolo não controla — ele só padroniza a mensagem. A permissão é decidida pela sua camada de governança: quem pode pedir o quê, com qual credencial, até qual limite e sobre qual versão do dado. Sem essa camada, o padrão de fato vira "quem consegue falar consegue pedir", o que é perigoso quando os agentes agem em escala.
Os agentes de fornecedores diferentes já se falam. A pergunta deixou de ser "eles conseguem conversar?" e virou "quem define o que cada um pode fazer, com qual credencial e sobre qual dado?". Governar a interoperabilidade dos meus agentes →