A Salesforce consolidou o Agentforce como plataforma multi-modelo, e isso muda a pergunta certa a duas semanas da Dreamforce (15 a 17 de setembro). Hoje você escolhe o modelo que roda por trás do agente: o padrão gerenciado pela Salesforce (família GPT), Claude rodando na Amazon Bedrock dentro da fronteira de confiança, Google Gemini, modelos GPT mais recentes — e ainda dá para trazer o seu, no modelo que a Salesforce chama de BYOM/BYOLLM. Parece a notícia. Não é. A notícia é o que isso revela: quando o modelo vira um dropdown, ele deixa de ser o seu diferencial.
Este artigo explica por que o Agentforce multi-modelo empurra o valor para a camada de baixo — o dado governado e a integração CRM↔ERP sobre os quais o agente raciocina e age — e qual pergunta o comprador deveria levar para a Dreamforce.
O que mudou: o Agentforce virou multi-modelo
Até pouco tempo, escolher a plataforma de agentes implicava aceitar o modelo que vinha embutido. O Agentforce quebrou esse acoplamento. A documentação da Salesforce hoje lista opções gerenciadas (o padrão Salesforce, com a família GPT), modelos hospedados na AWS (Claude via Amazon Bedrock, dentro do Trust Boundary), e Google Gemini — com recomendações testadas para uso com agentes e a possibilidade de BYOLLM, em que o cliente pluga o próprio modelo com as próprias credenciais.
Traduzindo: o LLM virou configuração, não arquitetura. E configuração se troca num painel. Essa é a mudança de fundo que a maioria das análises ignora ao focar em "qual modelo é melhor".
Como o motor de raciocínio usa o modelo para agir
No Agentforce, o modelo não age sozinho. Ele é o componente de linguagem de um motor de raciocínio que recebe uma intenção, consulta dados, planeja passos e chama ações. O modelo interpreta e redige; quem determina o resultado é o contexto que chega até ele — os dados que o agente enxerga e as ações (integrações) que ele pode executar. É a diferença entre um bom redator e um bom operador: o redator escreve bem sobre o que você lhe der; se você der a informação errada, ele escreve com fluência a resposta errada.
A virada: quando o modelo é um dropdown, ele para de ser o diferencial
Aqui está o ponto estratégico. Se qualquer concorrente pode plugar o mesmo LLM de fronteira que você — e agora pode —, então o modelo deixou de ser vantagem competitiva. Ele virou insumo comoditizado, disponível a todos com poucos cliques. E ninguém constrói diferenciação sobre um insumo que o vizinho também tem.
O que sobra para decidir se o seu agente funciona em produção não é qual modelo você marcou no dropdown. É sobre qual dado ele raciocina e por qual integração ele age. Essa é a camada que a sua empresa constrói e o concorrente não copia com um clique.
Sobre o que o agente realmente raciocina: o dado
Um agente de atendimento, de vendas ou de operação só é útil se enxerga a verdade do cliente. E a verdade do cliente, na maioria das empresas, está espalhada: cadastro no CRM, pedido no ERP, entrega no OMS, disponibilidade no sistema de estoque, histórico no service. Quando esses sistemas não conversam, o agente raciocina sobre fragmentos — e fragmentos geram respostas confiantes e erradas.
Plataformas como o Data Cloud existem exatamente para unificar e ativar esse dado. Mas unificar dado não é um toggle: exige reconciliação (qual sistema é a verdade), qualidade (deduplicar, normalizar) e contexto de negócio. É trabalho de fundação, e é ele que decide a qualidade da resposta — independentemente do modelo.
Por que trocar de modelo não conserta dado espalhado
Imagine que o agente errou: prometeu um prazo que o estoque não sustenta. A reação instintiva é "vamos trocar por um modelo mais esperto". Mas o erro não veio da inteligência do modelo — veio de ele ter enxergado um estoque desatualizado, porque a integração entre a plataforma de venda e o ERP era frágil ou inexistente.
Trocar de GPT para Gemini, ou de Gemini para Claude, não muda a foto que o agente vê. Só muda o sotaque de quem devolve a resposta errada. O que conserta é reconciliar o dado e governar a integração pela qual o agente age. Modelo melhor sobre fundação ruim continua sendo resposta ruim.
A fundação que decide: dado governado + integração CRM↔ERP + governança
Se o modelo virou commodity, a diferenciação desce para três camadas concretas. Primeiro, dado governado: uma fonte reconciliada e contextualizada sobre a qual o agente raciocina. Segundo, integração CRM↔ERP↔OMS↔estoque: a malha pela qual o agente não só lê, mas age — criar pedido, ajustar caso, disparar processo — com uma API contratada como porta de escrita segura e arquitetura orientada a eventos que absorve falha. Terceiro, governança: fronteiras claras do que o agente pode fazer, trilha de auditoria e observabilidade do que ele leu e escreveu.
Nenhuma dessas três é resolvida escolhendo o modelo. Todas são projeto de arquitetura — e é nelas que mora a vantagem que o concorrente não pluga.
A pergunta certa para levar à Dreamforce (15 a 17 de setembro)
O comprador que entra na keynote perguntando "qual modelo o Agentforce vai usar?" está otimizando a camada errada. A pergunta que separa quem escala de quem coleciona pilotos é outra: "sobre qual dado e por qual integração o meu agente vai raciocinar e agir — e quem governa isso?"
Se a resposta for "o dado está espalhado e a integração ainda não existe", nenhum modelo do dropdown salva o projeto. Se a resposta for "o dado está reconciliado e a integração é governada", qualquer modelo competente entrega — e você fica livre para trocar de LLM quando quiser, sem refazer a fundação.
Como a CCX monta a fundação sob o Agentforce (agnóstico de modelo)
É aqui que a CCX atua. Nossa Consultoria em Tecnologia desenha a arquitetura-alvo do dado e da integração sobre a qual o Agentforce raciocina — o diagnóstico do que reconciliar e integrar antes de dar autonomia ao agente. Sobre isso, a prática de Integrações & APIs Enterprise constrói a malha CRM↔ERP↔OMS↔estoque com API contratada e arquitetura orientada a eventos (Kafka, RabbitMQ, MuleSoft), e Data & BI reconcilia e contextualiza o dado — inclusive alimentando o Data Cloud — que o motor precisa para raciocinar certo. Quando falta capacidade sênior de Salesforce para montar isso antes da Dreamforce, as Squads On-Demand entram com onboarding em 48h.
Tudo agnóstico de modelo: você escolhe GPT, Claude, Gemini ou o seu — a CCX garante a fundação embaixo. O Agentforce virou multi-modelo, e por isso o modelo parou de ser o diferencial. O que decide é o dado governado e a integração CRM↔ERP sobre os quais o agente age. Falar com especialista Salesforce → — para a sua escolha de LLM finalmente importar menos que o encanamento embaixo.
Perguntas frequentes
Quais modelos o Agentforce suporta?
O Agentforce opera como plataforma multi-modelo: modelos gerenciados pela Salesforce (família GPT como padrão), Claude rodando na Amazon Bedrock dentro da fronteira de confiança, Google Gemini, e versões GPT mais recentes — além de BYOM/BYOLLM, em que você traz o próprio modelo. As opções e recomendações mudam com frequência; consulte a documentação oficial da Salesforce para a lista vigente.
Se o Agentforce é multi-modelo, qual devo escolher?
Para a maioria dos casos empresariais, a escolha entre modelos de fronteira competentes não decide o resultado — decide a fundação. Escolha um modelo testado para agentes e invista o esforço no dado governado e na integração. É lá que está o diferencial.
Trocar de modelo melhora o resultado do agente?
Raramente, se o problema é dado espalhado ou integração ausente. Modelo melhor sobre fundação ruim continua entregando resposta ruim — com mais fluência. Reconcilie o dado e governe a integração primeiro.
Por onde começar antes da Dreamforce?
Pelo diagnóstico da arquitetura-alvo: mapear onde o dado do cliente está, o que reconciliar, e qual integração o agente precisa para agir. Assim você chega à Dreamforce perguntando "sobre qual dado meu agente age", e não "qual modelo ele usa".