Faltam cinco dias para a Dreamforce (15 a 17 de setembro, Moscone Center) e a Salesforce chega ao evento com o agente virado item de prateleira. A AgentExchange funde AppExchange, Slack Marketplace e Agentforce num catálogo único de descoberta e contratação — 10 mil+ apps Salesforce, 2.600+ apps e agentes Slack e 1.000+ agentes, sub-agentes, tools e MCP servers — e ainda lista MCP servers de 30+ parceiros (AWS, Box, Cisco, Google Cloud, IBM, Notion, PayPal, Stripe, Teradata, WRITER), com um fundo de US$ 50 milhões (AgentExchange Builders Initiative) para fomentar a chamada “economia do Funcionário Virtual”.
O apelo é real: em vez de construir, você descobre e instala um agente pronto, num marketplace governado — e isso faz a descoberta e a confiança escalarem. Mas antes de comemorar, uma leitura sóbria: instalar um “funcionário virtual” é como contratar um. O agente do catálogo não chega sabendo o seu negócio. Ele precisa ser onboardado — exatamente como um funcionário novo — no seu dado governado, sob o seu perímetro de permissão, plugado aos seus sistemas. O catálogo distribui o agente; ele não onboarda o agente na sua realidade. E isso não é uma crítica à Salesforce: ServiceNow Store, Google Agentspace, AWS e Oracle têm marketplaces equivalentes. O agente virou SKU em todo lugar; o fosso é o onboarding.
O que é a AgentExchange
A AgentExchange é o marketplace de agentes da Salesforce — a convergência de três mundos que antes viviam separados: o AppExchange (o marketplace histórico de apps Salesforce), o Slack Marketplace e o Agentforce (a camada de agentes de IA da plataforma). O resultado é um catálogo único onde uma empresa descobre, avalia e contrata desde apps tradicionais até agentes autônomos. Os números dão a escala: 10 mil+ apps Salesforce, 2.600+ apps e agentes Slack, 1.000+ agentes, sub-agentes, tools e MCP servers, além de MCP servers de mais de 30 parceiros. Para incentivar a construção, a Salesforce criou a AgentExchange Builders Initiative, um fundo de US$ 50 milhões.
Traduzindo o jargão: o marketplace resolve o problema de encontrar e de confiar. Catálogo curado, avaliações, procurement unificado, o selo do fornecedor. Isso tem valor concreto. Mas guarde a distinção — resolver descoberta e confiança não é a mesma coisa que resolver integração e supervisão.
A “economia do funcionário virtual”: o agente virou SKU
A expressão que a Salesforce usa — “economia do Funcionário Virtual” — é reveladora. Ela enquadra o agente não como software, mas como força de trabalho: algo que você contrata para executar um papel. É uma metáfora poderosa e, curiosamente, mais honesta do que o marketing costuma ser. Porque se o agente é um funcionário, então tudo o que vale para contratar gente vale para “instalar” um agente.
Você não coloca um funcionário recém-contratado para mexer na sua receita no primeiro dia sem acesso, sem contexto e sem supervisor. Você o onboarda: dá acesso aos sistemas certos, explica o negócio, define o que ele pode e não pode fazer, e coloca alguém para acompanhar. O agente de catálogo exige exatamente o mesmo — e é aí que o clique de “instalar” esconde o trabalho real.
O que um marketplace resolve — e o que ele não resolve
Vale separar com precisão. Um marketplace de agentes resolve a descoberta (“que agente existe para este problema?”) e boa parte da confiança (“ele é curado, avaliado, tem procurement?”). O que ele não resolve: a integração (“ele fala com os meus sistemas de registro?”) e a supervisão (“quem responde quando ele age errado sobre a minha receita?”).
“Contratar” o agente no catálogo é o passo fácil e rápido. Integrá-lo ao seu dado e supervisioná-lo é o trabalho — e continua sendo seu. Essa é a mesma lição que percorreu este blog nos últimos dias: um assistente de terceiros só age “sem integrações custosas” quando a integração já foi feita, e o agente que responde em várias superfícies ainda depende do dado governado no Data 360.
Note também o pano de fundo do evento. A cobertura da imprensa especializada resume a Dreamforce como o momento em que “a empresa agêntica vai a julgamento”: são 1.600+ sessões, mas os números de ROI ainda faltam, e o evento tem, segundo os analistas, “um único trabalho — provar que o Agentforce funciona de verdade”. O detalhe que raramente entra no keynote é que o ROI só aparece depois que o agente comprado é onboardado no dado e nos sistemas certos. Um catálogo maior acelera a descoberta; ele não antecipa o retorno. O retorno mora do outro lado da ponte — a que você constrói.
Instalar é contratar: por que o agente do catálogo precisa de onboarding
Pense no ciclo de onboarding de um funcionário: credenciais, acesso a sistemas, contexto do negócio, limites de alçada, um gestor. Agora mapeie isso para um agente comprado. Ele precisa de acesso ao dado governado (para saber sobre o que está agindo), de um perímetro de permissão (para saber o que pode disparar), e de integração com contrato (para agir fora do CRM). Nenhuma dessas três coisas vem no pacote do marketplace. O catálogo entrega o agente pronto; o onboarding é sua responsabilidade — e é onde o valor se realiza ou se perde.
O agente age sobre o Data 360 que existir: dado governado como onboarding
Aqui está o ponto mais delicado. Um agente Agentforce age sobre o Data 360 — a camada de dados unificada da Salesforce. Se o seu Data 360 está unificado e governado, o agente age sobre uma imagem fiel da sua receita. Se está desunificado, com o cliente em um silo, o pedido em outro e o histórico em um terceiro, o agente age sobre uma imagem distorcida — e age com convicção, porque agentes não hesitam. Preparar o dado governado que o agente lê não é um pré-requisito técnico opcional: é o onboarding do funcionário virtual. Sem ele, você não contratou um funcionário; soltou um estranho no seu pipeline.
Um exemplo torna isso concreto. Imagine um agente de atendimento comprado no catálogo, encarregado de resolver pedidos de reembolso. Ele parece simples de “instalar”. Mas para agir corretamente, esse agente precisa saber: quem é o cliente (perfil unificado), qual foi a compra (registro do pedido), qual a política aplicável (regra de negócio), qual o status do pagamento (sistema financeiro) e qual o histórico de contato (atendimento). Se essas cinco fontes vivem em silos diferentes, o agente ou trava por falta de contexto, ou — pior — decide reembolsar sobre uma imagem incompleta. A unificação no Data 360 é o que transforma esse agente de uma demo bonita num funcionário confiável. É trabalho de fundação, não de configuração.
O perímetro de permissão: quais skills, sobre qual registro, com qual trilha
Todo funcionário tem alçada. Todo agente também precisa ter. O perímetro de permissão responde a três perguntas: quais skills o agente pode disparar, sobre qual registro ele pode agir, e com qual trilha de auditoria. Sob o princípio de menor privilégio, o agente recebe apenas o necessário para o papel que exerce. Isso protege contra o cenário em que um agente curado por um terceiro tem, na prática, mais poder sobre a sua operação do que qualquer pessoa do seu time teria no primeiro mês. Desenhar esse perímetro é parte do onboarding — e é engenharia de segurança, não configuração de tela.
Agir fora do CRM: por que o “funcionário virtual” precisa de integração com contrato
Um agente que só lê e responde dentro do Salesforce é útil, mas limitado. O valor real aparece quando ele age — e agir quase sempre significa sair do CRM: atualizar o ERP, checar o estoque, disparar um pagamento, escrever num canal. Para isso, não basta o agente existir no catálogo; é preciso uma integração com contrato de API entre o CRM e os seus outros sistemas de registro, com garantia de entrega e idempotência. O marketplace não costura essa ponte. Ela é sua — e é o que separa um agente que “conversa” de um agente que “opera”.
Repare que a própria AgentExchange sinaliza isso ao listar MCP servers de 30+ parceiros. O Model Context Protocol padroniza a forma como um agente pede acesso a uma ferramenta — o que é ótimo — mas não elimina o trabalho de expor os seus sistemas de registro por trás dele, com autenticação, mapeamento de dados e política de acesso. Ter o protocolo é ter o encaixe da tomada; você ainda precisa passar a fiação até ela. Por isso, quanto mais “plug-and-play” o catálogo promete ser, mais importa quem cuidou da fiação do seu lado. O plugue é padronizado; a instalação elétrica, não.
Como a CCX faz o onboarding que o catálogo não faz
A AgentExchange deixa você instalar agentes como quem contrata. Mas instalar é o passo fácil. A CCX faz o onboarding que o catálogo não faz. Em Salesforce Data Cloud (Data 360), preparamos a fundação de dados unificada e governada — unificação, segmentação e ativação — que o agente comprado lê para agir sobre a receita real, e não sobre uma ilha. Em Integrações & APIs Enterprise, costuramos o CRM↔ERP e os canais com contrato de API idempotente e arquitetura event-driven (Kafka/RabbitMQ), para o “funcionário virtual” agir fora do Salesforce — não apenas ler. E desenhamos o perímetro de permissão do agente sob menor privilégio, com pentest, OAuth2 e Vault.
Antes da Dreamforce, o movimento inteligente não é escolher qual agente instalar — é preparar o ambiente que qualquer agente instalado vai precisar. Comece com um diagnóstico de prontidão Salesforce com a CCX: Data 360 governado, integração CRM↔ERP e perímetro de permissão, para que instalar um agente signifique, de verdade, contratar um funcionário — e não soltar um estranho no seu pipeline.
Perguntas frequentes (People Also Ask)
O que é a AgentExchange da Salesforce? É o marketplace de agentes da Salesforce, que funde AppExchange, Slack Marketplace e Agentforce num catálogo único — 10 mil+ apps, 2.600+ apps e agentes Slack, 1.000+ agentes e MCP servers de 30+ parceiros — para descobrir e contratar agentes de IA.
Instalar um agente da AgentExchange substitui a integração? Não. O marketplace faz a descoberta e a confiança escalarem, mas não onboarda o agente na sua realidade. O agente age sobre o Data 360 que existir, sob a permissão que você desenhar, e só age fora do CRM com integração de contrato.
O que é a “economia do funcionário virtual”? É a metáfora que a Salesforce usa para o agente contratável de um catálogo. E, como todo funcionário, o agente precisa de onboarding: acesso ao dado governado, perímetro de permissão e integração.
Isso é só da Salesforce? Não. ServiceNow Store, Google Agentspace, AWS e Oracle têm marketplaces equivalentes. O agente virou SKU no mercado todo; o diferencial é o onboarding — dado, permissão e integração.