O gap de confiança do Agentforce não se fecha no keynote. Se fecha na sua org.

Três manchetes, uma ferida só

Numa mesma semana, o ecossistema produziu três manchetes que parecem assuntos diferentes e são o mesmo assunto. Que a Dreamforce 2026 tem um único trabalho: provar que o Agentforce funciona de verdade. Que profissionais Salesforce desconfiam de IA, com motivos listados. E, vinda do próprio blog de engenharia da Salesforce, a admissão mais honesta do ano: gerar código com IA é fácil, difícil é confiar nele.

Quando o fabricante, a imprensa do ecossistema e os profissionais de campo apontam para o mesmo lugar, não é coincidência. É o fim de uma fase. A pergunta de 2025 era o que a IA consegue fazer. A pergunta de 2026 é outra, e é muito mais difícil: por que eu deixaria ela fazer?

A desconfiança é racional, e isso é bom

Quem administra um sistema de registro desconfia de qualquer coisa não determinística por profissão, não por teimosia. O CRM é onde mora o pipeline, a comissão, o contrato, o faturamento. Um relatório errado constrange; um desconto errado aplicado por um agente autônomo vira passivo.

E o padrão que eu vejo em projeto é sempre o mesmo: o agente brilha na demo e tropeça no dado real. Não porque o modelo seja ruim, mas porque a demo roda sobre um catálogo limpo, meia dúzia de produtos bem descritos e permissões de administrador. A produção roda sobre dez anos de campos duplicados, descrições vazias, sharing rules que ninguém audita desde 2019 e processo comercial que só existe na cabeça de duas pessoas. IA não conserta esse ambiente. IA amplifica esse ambiente, agora com autoridade e em escala.

Confiança não é sentimento, é uma pilha

A boa notícia: confiança em agente não se conquista com keynote, se constrói com arquitetura. E a pilha tem andares bem conhecidos de quem faz projeto:

• Dados com semântica. O agente responde com a qualidade do que encontra. Catálogo modelado, atributos padronizados e descrições reais valem mais que qualquer prompt engineering. Foi o argumento do meu post sobre Product Catalog Management: fonte única da verdade não é luxo, é pré-requisito de IA.
• Permissão mínima. Agente herda o acesso que você dá, e acesso demais é a falha mais comum que encontro em POC. FLS, sharing e permission sets valem para agente como valem para usuário, com uma diferença: o agente não tem bom senso para não usar o que não devia.
• Determinismo nas bordas. O agente pode decidir; a plataforma limita. Validation rules, Flows e approval process viram guardrails: a IA propõe o desconto, o processo determinístico decide se ele passa. Quem inverte essa ordem está terceirizando governança para um modelo probabilístico.
• Auditabilidade por passo. O modelo mental certo já existe dentro do próprio Revenue Cloud: o Pricing Waterfall registra cada degrau do preço justamente para o resultado ser auditável. Agente precisa do mesmo: cada ação logada, cada decisão reconstituível. Se você não consegue explicar por que o agente fez algo, você não tem um agente, tem um risco com crachá.
• Escopo pequeno e métrica definida. Um agente com um trabalho claro e uma métrica de resolução acordada antes de ligar o botão supera qualquer copiloto genérico. Não por acaso a própria Salesforce migrou o modelo comercial para pay-per-resolution: quando se cobra por resolução, alguém precisou definir o que é resolver.

O pivô silencioso: adoção antes de feature

Tem um segundo sinal na mesma semana que passou mais despercebido: a leitura de que a Salesforce finalmente estaria priorizando adoção de IA em vez de lançamento de feature. Se for verdade, é o movimento mais maduro do ciclo. Feature nova gera manchete; adoção gera renovação de contrato. E adoção, de novo, é um problema de confiança, não de capacidade. Ninguém adota em produção o que não consegue auditar, explicar e limitar.

O que a Dreamforce precisa mostrar (e o que eu vou procurar)

Concordo com a tese de que a Dreamforce 2026 tem um trabalho só. Mas discordo do critério implícito. Provar que o Agentforce funciona não é subir no palco um demo perfeito; demo perfeito existe desde 2024. É mostrar cliente de verdade, em produção, com número auditado: taxa de resolução, custo por resolução, taxa de intervenção humana, e o que aconteceu no mês em que o agente errou. O dia em que a Salesforce mostrar o erro e o mecanismo que o conteve, a conversa de confiança muda de patamar.

É isso que eu vou procurar em outubro, e é isso que recomendo a qualquer arquiteto avaliar num case: não pergunte o que o agente faz. Pergunte o que o impede de fazer o que não deve, e quem percebe quando ele tenta.

Roteiro para quem implementa agora

• Comece pelo processo que já é limpo e medido. Agente em cima de processo quebrado só quebra mais rápido.
• Dê ao agente a menor permissão que resolve o caso de uso. Amplie depois, com evidência.
• Ligue os logs antes de ligar o agente. Auditabilidade se desenha no dia zero, não depois do incidente.
• Defina a métrica de resolução com o dono do processo antes do primeiro deploy. Sem métrica, todo resultado vira opinião.
• Trate o agente como um estagiário brilhante: capacidade alta, supervisão alta, autonomia crescendo com histórico.

Minha leitura

O gap de confiança do Agentforce não vai se fechar de cima para baixo, do keynote para a org. Vai se fechar de baixo para cima: catálogo limpo, permissão mínima, guardrail determinístico, log de cada passo, métrica acordada. Nada disso rende manchete, e é exatamente por isso que separa quem tem case de quem tem demo. A pergunta de 2026 não é se o agente consegue. É se a sua org está pronta para merecer a confiança que você quer que o seu cliente tenha nele.

Leituras da semana que puxaram este ensaio: a tese do trabalho único da Dreamforce, as cinco razões da desconfiança e a admissão da engenharia da Salesforce sobre confiança.