O Employee Agent da Salesforce provou uma coisa: o gargalo do Agentforce nunca é o modelo, é o dado
Um ano e 300 mil conversas depois, a maior lição do caso interno da Salesforce não foi sobre prompt nem sobre LLM: foi sobre arrumar a base de conhecimento antes de soltar o agente
A Salesforce usou o próprio Employee Agent internamente por um ano, com mais de 300 mil conversas e 97,7% de autoatendimento. O aprendizado mais valioso não foi de IA: foi de governança de dado e conteúdo.
Todo projeto de Agentforce que eu já vi começar torto, começou torto pelo mesmo motivo: o cliente quer resolver o agente antes de resolver o dado. Depois de acompanhar o case interno da Salesforce com o Employee Agent, fico ainda mais convencido de que essa é a ordem errada, e que existe agora um exemplo público e detalhado provando isso na prática.
O contexto é simples de entender. A Salesforce rodou o Employee Agent internamente por um ano, como Customer Zero, para resolver dúvidas de RH: política de PTO, prazos de benefícios, processo de performance review, reserva de sala. Hoje é o agente mais usado dentro da empresa, com 97,7% de taxa de autoatendimento e mais de 300 mil conversas no primeiro ano. Adoção orgânica passou de 80%. Redução de 20% no volume de casos tier 1 em 103 mil chamados. Durante o período de open enrollment, queda de 58% nos casos de suporte. Números bons, sem dúvida. Mas o que interessa para quem está em projeto não é o resultado, é o caminho até ele.
O agente ficou burro porque a base de conhecimento era uma bagunça
Esse é o ponto que eu destacaria em qualquer apresentação de arquitetura para cliente. A equipe interna tinha mais de mil artigos de conhecimento, com política duplicada, texto desatualizado, sobreposição de conteúdo. Um humano lendo aquilo filtra o ruído sem nem perceber. O agente não filtra nada: ele leva tudo ao pé da letra, e o resultado foi resposta confusa e, em alguns casos, errada.
A saída não foi ajustar prompt nem trocar modelo. Foi arquivar centenas de páginas obsoletas e reescrever política complexa em linguagem declarativa, clara, que o agente conseguisse interpretar e agir sobre. E aqui vem a virada que eu acho mais interessante: o time parou de escrever artigo curto e direto (pensado para humano escanear rápido) e passou a escrever artigo robusto e completo, pensado para dar contexto total ao agente. É uma inversão de prática editorial que a maioria dos times de conhecimento ainda não fez, porque ainda escreve para pessoa, não para agente consumir.
Isso conversa direto com o que eu já bati o martelo em projeto de Agentforce Revenue Management: antes de configurar tópico e ação, tem que auditar Data 360, tem que auditar o repositório de conhecimento, tem que definir quem é o dono daquele conteúdo e com que frequência ele é revisado. Sem isso, você não tem um agente, tem um gerador de resposta incerta com boa interface.
Distribuição importa tanto quanto o dado
O segundo ponto de arquitetura que vale registrar: o Employee Agent foi colocado dentro do Slack, onde o funcionário já estava trabalhando, em vez de virar mais um destino isolado. Isso reduz fricção de adoção de um jeito que nenhuma feature nova resolve. E a Salesforce já sinaliza que a evolução natural é dissolver esse agente dentro do Slackbot, junto com outros agentes, reforçando o Slack como porta de entrada da experiência do funcionário. Para quem projeta arquitetura de Agentforce hoje, isso é um sinal claro de para onde a integração está indo: menos app dedicado, mais agente embutido no canal de comunicação que a pessoa já usa.
Confiança e compliance não são feature, são pré-requisito
O terceiro bloco relevante é sobre dado sensível. O Employee Agent hoje resolve cerca de 18 mil casos de verificação de vínculo empregatício por ano, sem retenção de dado, com detecção de toxicidade e log de auditoria. E o agente só mostra ao funcionário o que a permissão dele já permitiria ver, porque a governança de acesso já existe na plataforma. Isso é o argumento mais forte contra quem trata Agentforce como camada de IA solta por cima do CRM: se a modelagem de permissão, papel e compartilhamento estiver malfeita, o agente vai herdar essa bagunça, só que mais rápido e em escala.
O case prova, com número e não com promessa de fornecedor, que o fator limitante de qualquer implantação de Agentforce é a qualidade e a estrutura do conteúdo que alimenta o agente, não a capacidade do modelo. Isso muda a conversa de escopo com o cliente: antes de falar de tópico, ação e orquestração, tem que colocar auditoria de conhecimento e de dado na frente do cronograma.
Para quem trabalha com Revenue Cloud, Data 360 ou qualquer camada de agente, o recado é o mesmo: agente ruim quase sempre é sintoma de dado mal cuidado, não de limitação de IA generativa.
Vale registrar que este é um relato de Customer Zero, ou seja, a própria Salesforce usando o próprio produto internamente antes de vender para fora. Os números de adoção e redução de caso são reais e vieram direto da empresa, mas não substituem benchmark independente de terceiros. Trate como estudo de caso qualificado, não como garantia de resultado replicável em qualquer org.
Antes de configurar qualquer Topic ou Action de Agentforce, faça o exercício que a Salesforce fez internamente: audite o repositório de conhecimento, elimine duplicidade e artigo desatualizado, e reescreva o conteúdo em linguagem declarativa e completa, pensando que quem vai ler primeiro é o agente, não o funcionário. Depois disso, revise a estrutura de Permission Set e Role Hierarchy que vai governar o que o agente pode mostrar, porque essa camada de segurança não se resolve na configuração do agente, se resolve na modelagem de acesso que já existe (ou deveria existir) na org.
Se o cliente já usa Slack, priorize colocar o agente dentro do fluxo de trabalho existente em vez de criar mais um destino isolado. Adoção orgânica nasce de fricção baixa, não de funcionalidade nova.
O maior risco de projeto aqui é o cliente querer pular a etapa de faxina de dado e conteúdo porque acha que isso é "trabalho manual sem valor" e não faz parte da entrega técnica. Só que o Data 360 amplifica exatamente o que existe na org: se o dado tá duplicado, mal padronizado ou incompleto, o agente vai tomar decisão ruim em escala, e aí a culpa cai no projeto, não na base suja.
Eu sempre bloqueio essa etapa no cronograma como marco formal, com critério de saída claro e dono definido do lado do cliente. Não é sobre desconfiar da equipe, é sobre não deixar a Agentforce Revenue Management herdar um problema que já existia antes do primeiro fluxo ser desenhado.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.