No mesmo compasso em que a SAP libera o A2A inbound no gateway, a Salesforce resolveu colocar a interoperabilidade de agentes na vitrine. O Agent Fabric — camada governada por MuleSoft — passa a funcionar como um registro e hub onde agentes externos se conectam, são descobertos e interoperam com os agentes da Salesforce. O AgentExchange vira a prateleira de "connected agents". E o MuleSoft publicou uma A2A bridge que expõe serviços como agentes A2A e liga quem fala A2A ao que não fala. A mensagem é clara: a Salesforce está comprometida com os dois padrões — MCP e A2A — ao mesmo tempo.
Para quem opera, a tradução é direta: seu agente externo agora "aparece" para os agentes da Salesforce. Isso é descoberta. Não é governança. E a diferença entre as duas é exatamente a parte que você constrói.
O que a Salesforce anunciou: Agent Fabric, AgentExchange e a A2A bridge do MuleSoft
Em vez de barrar o agente de fora (a aposta da SAP), a Salesforce aposta em ser a plataforma mais aberta — e governar o acesso pela camada de integração. O Agent Fabric registra e torna descobríveis os agentes; o AgentExchange os organiza como um catálogo; a A2A bridge do MuleSoft conecta mundos que falam protocolos diferentes. É uma jogada coerente: a interoperabilidade deixa de ser um recurso escondido e vira argumento comercial.
O ponto que o anúncio não resolve — e nem promete resolver — é o que acontece depois do "conectado".
O que o registro resolve (descoberta) e o que ele NÃO resolve
Aparecer em um registro responde a uma pergunta: qual agente existe e pode o quê. Importante, mas é só a primeira. As que sobram são as caras:
- Escopo. Com que permissões o agente externo age dentro do seu ambiente? Registrar não limita; limitar é configuração sua.
- Identidade. Qual identidade esse agente carrega, e como você a audita a cada chamada?
- Custo por ação. A Salesforce cobra por ação do Agentforce — cerca de 20 créditos, algo como US$0,10 por ação. Multiplicado pelo volume de um agente em produção, isso é uma linha de custo que aparece só depois que tudo já está "conectado".
- Alcance ao não-Salesforce. O maior buraco. A tarefa real quase nunca termina dentro de uma plataforma só — ela precisa do seu e-commerce, do seu OMS, do seu ERP, do fiscal, do legado.
Custo por ação e context-tiering: a conta que aparece depois do "conectado"
Dois mecanismos merecem atenção na hora de desenhar a arquitetura. O primeiro é o custo por ação: ótimo para começar barato, perigoso para escalar sem medição. Sem uma visão de quantas ações cada fluxo dispara, a fatura vira surpresa. O segundo é o context-tiering — a tendência de dar mais contexto ao agente nativo do que ao externo. Não é bloqueio; é um empurrão sutil para você fazer tudo nativo e, com o tempo, ficar dependente. A Forrester já alertou sobre não deixar um único fornecedor virar o porteiro da IA da sua empresa. Registrar no Fabric não é, por si só, esse risco — mas ignorar o custo e o context-tiering é.
O buraco do não-Salesforce: por que a tarefa real transborda
Um agente de atendimento que confirma um pedido precisa falar com o OMS. Um agente de cobrança precisa do ERP e do fiscal. Um agente de pós-venda precisa do e-commerce e da logística. Nenhum desses sistemas vive dentro da Salesforce. É aí que a interoperabilidade "de vitrine" para na porta: o agente externo está registrado e visível, mas a tarefa que ele precisa cumprir atravessa a fronteira do não-nativo — e do outro lado não há Agent Fabric, há o seu encanamento de integração.
Como a CCX faz: camada API-led sobre MuleSoft que governa e estende
A CCX transforma "agente registrado" em "agente governado". Com Integrações & APIs Enterprise e MuleSoft (Anypoint, API-led connectivity, incluindo a A2A bridge), montamos a camada que controla quem entra, com que escopo, com que identidade e a que custo por ação — e, principalmente, que estende o alcance ao não-Salesforce: e-commerce, OMS, ERP, fiscal e legado, com integrações event-driven (Kafka/RabbitMQ) quando o volume pede.
Com Observabilidade 360° você mede o custo por ação antes que ele vire surpresa na fatura, e com IA para Negócios a gente garante que os agentes interoperem com propósito de negócio — não apenas conectados, mas úteis — sem que o context-tiering empurre você para o lock-in.
A Salesforce põe a interop na vitrine (Agent Fabric + AgentExchange + A2A bridge do MuleSoft). A CCX transforma "agente registrado" em "agente governado": escopo, identidade e custo por ação sob controle, e alcance ao não-Salesforce via API-led. Registro é o começo; a governança você constrói. Fale com um especialista Salesforce da CCX →
Duas apostas opostas, a mesma lição
Vale olhar o contraste do dia. A SAP abriu o A2A inbound atrás de crachá, cofre e lista (identidade, trust e ACL); a Salesforce abriu pela vitrine e cobra por ação. São estratégias opostas de abertura — fechar-e-governar contra abrir-e-monetizar — mas convergem na mesma lição para quem integra: quem desenhou a camada de integração e identidade decide se o agente externo vira produtividade ou vira risco. O protocolo é o mesmo nos dois lados; o que muda é quem assume a orquestração. Se você não assumir, o fornecedor assume por você — e cobra por isso.
"Governar" aqui tem um significado operacional concreto, não retórico: é ter um ponto único onde cada chamada de agente externo é autenticada, autorizada por escopo, roteada para o sistema certo (dentro ou fora da Salesforce), medida em custo e registrada para auditoria. Esse ponto único é a camada API-led. Sem ele, cada integração vira um caso particular, o custo se espalha e o rastro se perde — exatamente o que acontece quando se confunde "estar no catálogo" com "estar sob controle".
Perguntas frequentes
Preciso de A2A e MCP ao mesmo tempo? Na prática, sim: A2A conecta seus agentes aos agentes da Salesforce; MCP conecta agentes às ferramentas. A A2A bridge do MuleSoft ajuda quando um dos lados não fala A2A.
Como limito o escopo de um agente externo? Com uma camada de identidade e autorização entre o agente e seus sistemas — não no registro, mas na camada API-led que intermedeia as chamadas.
O AgentExchange governa o custo por ação? Ele cataloga e conecta. Medir e controlar o custo por ação é função de observabilidade e de desenho de fluxo — seu, não do catálogo.
Como integro ao que está fora da Salesforce? Via API-led sobre MuleSoft, expondo e-commerce, OMS, ERP e fiscal como serviços governados que os agentes consomem com escopo e rastro.