convicção não é precisão

O caso é simples de contar e incômodo de digerir: mesma pergunta, mesmo bot, três respostas diferentes sobre MQL, todas ditas com a mesma confiança de quem não tem dúvida nenhuma. Não teve exception, não teve warning, não teve nada que acionasse um alarme. Só números errados, entregues com aplomb.

Esse é o tipo de falha que projeto de Agentforce mal desenhado adora esconder até explodir na frente do board. Quando o agente erra feio e visivelmente, todo mundo desconfia e vai checar. Quando ele erra com convicção, ninguém questiona, porque a resposta parece certa. É a categoria de risco mais cara que existe: aquela que passa despacho.

A raiz do problema quase nunca é o modelo. É a camada de dados que alimenta o agente sem contrato claro de qual fonte é a verdade para qual métrica. Se você tem duas definições de MQL circulando (uma no relatório de marketing, outra num campo customizado esquecido), o agente vai escolher uma delas de forma aparentemente aleatória, dependendo de qual contexto ele resgatou naquela sessão.

Governança de dados não é mais pré-requisito bonito de documento de arquitetura. É a diferença entre um agente que ajuda e um que sabota decisão de negócio com aparência de autoridade.

Todo arquiteto já viu essa cena: alguém chega perguntando

Essa é a comparação que todo projeto de Agentforce deveria fazer antes de ir pra produção: mesmo modelo, mesmo caso de uso, dois times diferentes. Três meses depois, uma implementação ficou mais barata e mais precisa. A outra ainda vive de ticket manual toda vez que o prompt precisa de ajuste fino.

A tentação de tratar Agentforce como projeto de software tradicional (entrega, homologação, vai pra produção, ponto final) é enorme, porque é o modelo mental que a gente já domina. Mas agente de IA não se comporta como Apex trigger. Ele degrada, desvia, aprende coisa errada com dado ruim, e sem um loop de feedback estruturado, ninguém percebe até o usuário reclamar.

O que separou as duas implementações não foi sofisticação técnica. Foi decisão de projeto: uma delas reservou tempo e responsabilidade explícita para revisar output, recalibrar instrução e failar rápido em ambiente controlado. A outra tratou o go-live como linha de chegada.

Se seu plano de projeto de Agentforce não tem uma linha de orçamento e um dono para

Toda vez que um caso desses viraliza, dois campos se formam na hora: quem diz

O número chama atenção, mas o número não é a notícia. A notícia é a arquitetura por trás dele: um contrato desse tamanho só se sustenta quando você consegue empilhar Agentforce, Slack, MuleSoft, Data 360 e Tableau como camadas coerentes sobre um legado gigantesco e desconectado, que é exatamente o tipo de ambiente que qualquer órgão de governo carrega há décadas.

O que interessa pra quem desenha arquitetura em escala corporativa (não precisa ser bilhão de dólares, pode ser um cliente de porte médio com dez sistemas legados) é o padrão: MuleSoft entra como camada de integração que expõe dado confiável, Data 360 organiza esse dado numa visão única, Agentforce consome essa visão pra agir, Slack vira a superfície onde humano e agente colaboram, e Tableau fecha o loop com visibilidade de resultado.

Nenhuma dessas peças sozinha resolve o problema de sistemas desconectados. A confiança que o VA está comprando não é confiança em um produto, é confiança em uma orquestração de produtos desenhada com disciplina de arquitetura.

Vale guardar esse case como referência mental na próxima vez que um cliente perguntar se