Agentforce trocou um modelo gigante por vários pequenos, e isso muda como você deve pensar arquitetura de agente
A Salesforce contou os bastidores de como reduziu custo de inferência quebrando o raciocínio do agente em modelos especializados. O ponto interessante não é economia, é controle arquitetural
A Salesforce publicou um relato técnico sobre como reconstruiu o stack de inferência do Agentforce, trocando dependência total de um modelo frontier por uma combinação de modelos especializados menores. O motivo real não é só custo: é evitar virar refém de roadmap e latência de terceiro.
Todo projeto de Agentforce que já passou de POC para produção esbarra numa pergunta desconfortável: quem paga a conta de token quando o volume escalar de verdade? A Salesforce escreveu um artigo assumindo que ela mesma bateu nesse muro há 18 meses, quando o Agentforce inteiro rodava em cima de um único modelo alugado e o bill crescia linear com o tráfego. Isso não é surpresa para quem acompanha o mercado (o caso da Uber estourando o budget de IA em quatro meses virou piada recorrente em call de cliente), mas o interessante aqui é o que a Salesforce decidiu fazer a respeito.
Em vez de repassar custo pro cliente ou só otimizar prompt, eles quebraram o raciocínio do agente em tarefas discretas e treinaram modelos open-source pequenos e especializados para cada uma delas. A lógica é simples de entender e difícil de admitir: um modelo generalista faz tudo, mas faz cada coisa devagar, caro e com menos precisão do que um modelo treinado especificamente para aquele job.
O que eles quebraram em pedaços
O harness do Agentforce hoje distribui o trabalho assim:
- HyperClassifier: classifica intenção e roteia para o subagente certo. Fine-tuned em cima do GPT-OSS-20B, quantizado para rodar rápido. Resultado: 26ms contra ~1.446ms de um modelo frontier genérico. Isso é 55x mais rápido, rodando em toda request.
- Prompt Injection Defense: modelo dedicado treinado nas superfícies de ataque reais (campo de CRM, corpo de email, transcript), não um prompt de defesa improvisado.
- Toxicity model: avalia cada resposta antes de chegar no usuário final, porque LLM julgando o próprio output tem viés de complacência.
- TextEval: avaliador independente de citação, grounding, aderência à instrução e resolução de tarefa. Não pode ser alterado por admin, é garantia de runtime.
- TextRerank: reranqueamento de resultados de busca antes de chegar no modelo de raciocínio.
O modelo frontier continua existindo, mas só cuida do raciocínio multi-step central, e agora governado pelo harness em volta dele. Isso é o ponto que mais importa: dá pra trocar o modelo frontier de baixo sem reconstruir o resto.
Por que isso não é só sobre economia
O texto original é honesto ao dizer que ficar obcecado com custo de token é um mínimo local. O problema real é agência arquitetural: quando um único modelo alugado faz tudo, desde detecção de intenção até checagem de segurança, ele vira um gargalo de negócio inteiro, não só da fatura. Latência depende do provedor, roadmap depende do release dele, e a lógica de segurança vive numa caixa preta que você não controla.
Isso é exatamente o tipo de dependência que a gente vê se formar em projeto quando o cliente decide colocar tudo num único LLM externo sem pensar em camada de abstração. Funciona bem na demo, escala mal na operação, e vira dor de cabeça quando o provedor muda pricing ou model version do dia pra noite.
Para quem arquiteta soluções com Agentforce, esse relato é um sinal de maturidade da plataforma: menos dependência cega de modelo frontier único, mais controle sobre latência, custo e comportamento de segurança. Isso afeta diretamente decisão de arquitetura em projetos que envolvem agente conversando com dado sensível de CRM, porque a defesa contra prompt injection e a checagem de toxicidade deixam de ser um prompt bem escrito e passam a ser modelo dedicado auditável.
Também muda a conversa com cliente que pergunta "por que Agentforce é caro" ou "por que a resposta demora". Agora existe um vocabulário técnico pra explicar que nem tudo passa pelo modelo mais caro, e que o roteamento de intenção é feito por um classificador de 26ms, não por raciocínio pesado.
Vale lembrar que esse é um artigo institucional da Salesforce contando a própria história, então tem viés natural de marketing técnico. Os números (55x mais rápido, 99% de acurácia) vêm da própria empresa, sem benchmark externo independente até onde sei. Trato como fato reportado pela fonte, não como validação de terceiros.
Se você está desenhando uma solução de Agentforce hoje, vale conversar com o cliente sobre qual template está usando (Service Agent, Employee Agent) e verificar se o HyperClassifier já está ativo como default, já que ele foi GA na Spring '26. Isso impacta diretamente estimativa de latência e comportamento de roteamento em multi-turn conversation.
Para quem lida com segurança e compliance, vale revisar o Einstein Trust Layer Audit Trail do projeto e confirmar se o prompt injection score e o toxicity score estão sendo logados, porque isso é munição concreta pra responder auditoria de segurança ou questionamento de área jurídica sobre uso de IA generativa com dado de cliente.
O rollout de features como PID (Prompt Injection Defense) ainda está em GA prevista para Summer '26 no momento da publicação da fonte, então não assuma que está ativo em todas as orgs hoje. Confirme a versão de release antes de prometer isso em proposta de projeto.
Outro ponto de atenção: a arquitetura multi-modelo aumenta a complexidade de debugging. Quando uma resposta sai errada, agora você tem que rastrear se o problema foi no classificador de intenção, no reranker, no modelo de raciocínio ou no avaliador final. Isso exige observability madura, e a Salesforce não detalha no artigo como o cliente final acessa esse nível de telemetria fora do Trust Layer.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.