Agentforce responde qualquer pergunta. O problema é quando responde errado com convicção
Um case interno da própria Salesforce mostra por que grounding, dados certificados e AI Skills não são luxo arquitetural, são pré-requisito
A Salesforce publicou um case interno onde o mesmo Slackbot deu três respostas diferentes para a mesma métrica de MQL. Nenhum erro, nenhum warning, só números diferentes com a mesma confiança. Isso é o retrato exato do risco que todo projeto de Agentforce carrega quando pula a etapa de governança de dados.
Tem uma cena que todo arquiteto de Agentforce vai reconhecer: o cliente pergunta uma métrica simples pro agente, recebe uma resposta redonda, bonita, com número exato, e comemora. Aí alguém do time de BI olha pro dashboard oficial e o número é outro. Ninguém teve erro de sistema. Ninguém recebeu mensagem de falha. O agente simplesmente respondeu errado com a mesma cara de quem respondeu certo.
A própria Salesforce documentou um caso assim internamente, e o exemplo é bom justamente por ser banal. O time de Marketing perguntou ao Slackbot quantos MQLs foram gerados no último trimestre. Perguntaram duas vezes, de formas ligeiramente diferentes, e receberam dois números distintos: 50.000 e 75.000. O dashboard oficial de Leads, fonte de verdade certificada, dizia 100.000. Três respostas, uma pergunta, zero coincidência entre elas.
Por que isso aconteceu (e por que vai acontecer com você)
O Slackbot nas duas tentativas errou por caminhos parecidos: foi direto no objeto Lead da org, aplicou lógica "parecida" com a definição oficial de MQL mas não idêntica, e ainda por cima consultou dado transacional em tempo real, que muda retroativamente conforme leads entram e saem de status. Nenhuma das duas consultas usou a definição de MQL governada pelo Chief Data Office, que vive num dataset certificado no Marketing Data Warehouse com regras explícitas: tipo de snapshot trimestral, nome de estágio de funil correto, período fiscal ancorado.
Se você já implementou CPQ ou Revenue Cloud sabe exatamente essa sensação: existe o dado bruto, e existe a definição de negócio que transforma aquele dado bruto em algo que a empresa efetivamente usa para decisão. Um LLM sem contexto vai direto no dado bruto e improvisa a regra de negócio no meio do caminho. E como a resposta é probabilística, cada pergunta, cada usuário, cada histórico de conversa anterior no Slack pode levar a uma interpretação diferente da mesma lógica.
A correção que a Salesforce aplicou (e que serve de referência de arquitetura)
A solução não foi trocar de modelo nem ajustar prompt. Foi construir três camadas de grounding:
- AI Skill dedicada: um arquivo estruturado (Markdown mesmo, nada de mágica) dizendo explicitamente qual fonte de dado usar, quais filtros aplicar e qual regra de negócio governa a métrica. Sem isso, o agente improvisa. Com isso, ele segue um caminho repetível.
- Tableau MCP conectando o agente ao modelo semântico: em vez de o Slackbot adivinhar a lógica de negócio, ele passa a ler a lógica certificada que já existe por trás do dashboard oficial, incluindo definições de métrica, regras de filtro e mapas de relacionamento.
- Dataset certificado como única fonte de verdade: o mesmo dataset que alimenta o dashboard oficial de Leads passa a alimentar também o agente. Resultado: pergunta em linguagem natural, resposta idêntica ao dashboard, sempre.
Depois de implementado, a pergunta sobre MQLs do trimestre passou a retornar 100.000 de forma consistente, batendo com o dashboard oficial independente de quem perguntasse ou como perguntasse.
O ponto que muita implementação de Agentforce ignora
Existe uma tentação enorme em projeto de IA generativa de tratar governança de dado como etapa opcional, algo pra resolver "depois que o agente estiver funcionando". O case inverte essa lógica: o agente só funciona de verdade quando a governança já está pronta. Isso significa dataset certificado, definição de negócio documentada e camada semântica machine-readable antes de qualquer Topic ou Action no Agentforce Builder.
Na prática de projeto brasileiro isso se traduz em uma pergunta simples que eu faço em quase todo kickoff de Agentforce: "essa métrica que o agente vai responder, ela já tem dono, definição escrita e fonte única hoje, sem IA no meio?" Se a resposta for não, o problema não é do agente. É anterior a ele.
Esse tipo de erro não aparece em ambiente de demonstração, aparece em produção, com stakeholder de negócio confiando no número porque o agente respondeu com fluência e sem hesitação. Diferente de um relatório errado que alguém audita antes de apresentar, a resposta de um agente conversacional tende a ser aceita de forma direta, o que multiplica o risco de decisão tomada em cima de dado incorreto.
Para quem lidera arquitetura de Agentforce, Data Cloud ou qualquer camada de IA generativa em Salesforce, o recado é claro: a confiabilidade do agente é proporcional à qualidade e à governança do dado por trás dele, não ao tamanho do modelo ou à sofisticação do prompt.
Vale registrar que esse é um case interno da própria Salesforce, usando Slack, Tableau e o Chief Data Office deles como laboratório. Isso dá credibilidade prática, mas também significa que a solução descrita pressupõe maturidade de dados (dataset certificado, camada semântica, governança formal) que a maioria dos clientes brasileiros ainda não tem pronta. O padrão arquitetural é sólido, a facilidade de replicar em semanas não é garantida.
Antes de habilitar qualquer Topic no Agentforce que responda métricas de negócio, mapeie explicitamente qual é a fonte de verdade certificada daquela métrica hoje, mesmo sem IA. Se a métrica só existe em relatório manual ou planilha, resolva isso primeiro, porque o agente vai herdar a mesma inconsistência que já existe no processo.
Depois, construa a AI Skill como documentação viva: qual objeto, quais filtros, qual regra de negócio, escrito em linguagem simples e versionado. Se você já usa Tableau, avalie o MCP Server como camada de tradução entre pergunta em linguagem natural e modelo semântico certificado, em vez de deixar o agente consultar objeto bruto do Salesforce diretamente para métricas sensíveis.
O maior risco não é o agente errar, é o agente errar de forma consistente o suficiente para parecer confiável. Times de negócio tendem a validar a primeira resposta que recebem e repetir aquele número em apresentações, o que espalha o erro antes de alguém notar a divergência com o dashboard oficial.
Outro ponto de atenção: dado transacional em tempo real (como o objeto Lead) não é substituto de snapshot histórico para métricas de período fechado. Se sua métrica depende de "como estava no fim do trimestre", consultar a tabela viva vai produzir números que mudam retroativamente, e isso é comportamento esperado do dado, não bug do agente.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.