Koa Decisions: por que nem toda decisão em agente precisa de um LLM
O novo modelo da Salesforce resolve rotear e classificar em milissegundos, deixando o raciocínio generativo só para o que realmente precisa dele
A Salesforce lançou o Koa Decisions, sucessor do HyperClassifier, um modelo de decisão que escolhe entre categorias em um único passo e chega a 26 milissegundos contra 1,4 segundo de um LLM genérico. Para quem arquiteta Agentforce, isso muda a pergunta de 'preciso de um LLM aqui' para 'preciso de decisão ou de raciocínio'.
Toda vez que eu entro numa conversa de arquitetura de Agentforce, cedo ou tarde alguém pergunta: "mas isso aqui precisa chamar um LLM?" E a resposta, boa parte das vezes, é não. Tem muita coisa dentro de um agente que não é raciocínio, é decisão. Rotear uma mensagem para o time certo, decidir se um desconto passa ou não, escolher qual artigo de conhecimento mostrar. Isso não é trabalho para um modelo generativo gigante escrevendo token por token. É trabalho para um modelo de decisão.
A Salesforce já vinha fazendo isso com o HyperClassifier, que é o motor que roteia solicitações dentro do Agentforce: quando um cliente escreve "cadê meu pedido?", é ele quem manda essa mensagem para o pedaço do agente que entende de entrega, e não para o pedaço que entende de FAQ ou de promoção. Agora chega a próxima geração dessa peça, batizada de Koa Decisions, e o salto não é cosmético.
Koa Decisions recebe uma solicitação e uma lista de categorias que você define, e devolve a escolha em uma única etapa, em milissegundos. Foi construído em cima do Gemma, modelo open-weight do Google, com técnicas de treinamento próprias da Salesforce, e ganhou suporte multimodal (imagem e áudio), o que o HyperClassifier não tinha. O plano declarado é levar esse modelo para além do roteamento interno do Agentforce: Flow, Apex, prompt templates e uma API para quem constrói integração própria.
Por que isso é relevante do ponto de vista de arquitetura: um LLM generativo escreve resposta token a token, cada token dependendo do anterior. Isso tem custo computacional e latência. Um modelo de decisão lê a solicitação inteira de uma vez e devolve a resposta em um passo só, muitas vezes um único token, com score de confiança junto. Salesforce mediu isso internamente no roteamento do Agentforce: cerca de 26 milissegundos no modelo de decisão contra aproximadamente 1,4 segundo num LLM de propósito geral. Não é diferença de nicho, é ordem de grandeza.
E tem outro ponto que interessa a quem já sofreu com projeto de machine learning clássico dentro da org: antes, classificar uma solicitação exigia modelo preditivo sob medida, com todo o ciclo de definir outcome, coletar dado, rotular, treinar, validar, repetir. Meses até produção, em muitos casos. Koa Decisions parte de um modelo de linguagem que já entende relação semântica (por exemplo, que "devolver o pedido" se relaciona com "trocas e devoluções"), então adicionar uma categoria nova pode levar o time de dias para horas, sem retreinamento completo.
O exemplo de negócio que a própria Salesforce usa é bom: um deal de vendas começa a esfriar, o modelo de decisão identifica o risco e já escolhe qual time precisa entrar, enquanto o LLM fica responsável só por resumir o que mudou no contexto. Quando alguém abre o registro, o time certo já está acionado. É a divisão de trabalho que faz sentido: decisão rápida fica com modelo de decisão, raciocínio e redação ficam com o modelo generativo.
Koa Decisions entra na família Koa de modelos da Salesforce, que também inclui um modelo de raciocínio desenvolvido com a NVIDIA. Dá para testar sem ser cliente Salesforce: criando conta gratuita no Trailhead e rodando a demo do Koa Decisions, que deixa você adicionar categorias novas (tipo "Returns") e ver o modelo escolher a opção certa sem retreinamento.
Rotear não é raciocinar, e isso muda decisão de arquitetura
A discussão que eu mais vejo em projeto de Agentforce é "qual modelo usar para quê". Com Koa Decisions ficando disponível para Flow, Apex e prompt templates, a conversa muda de "preciso de um LLM aqui" para "preciso de decisão ou preciso de raciocínio". São perguntas diferentes, e confundir as duas é um dos jeitos mais comuns de estourar custo e latência num agente mal desenhado.
Para quem desenha arquitetura de Agentforce, essa separação entre "decisão" e "raciocínio" é prática, não teórica. Cada chamada desnecessária a um LLM generativo dentro de um fluxo de agente é latência que o cliente final sente e custo que o CIO cobra depois. Ter um modelo de decisão nativo, rápido e configurável sem retreinamento completo, acessível via Flow, Apex e API, muda o ponto de decisão de "vou usar prompt template para tudo" para "isso aqui é roteamento, classificação ou score, então uso Koa Decisions e guardo o LLM para o que realmente exige geração de texto ou raciocínio complexo".
Isso também impacta diretamente o business case de automação. Times de negócio que hoje dependem de regra fixa em Apex ou de condição engessada em Flow para rotear caso, qualificar lead ou sinalizar risco de deal ganham uma alternativa mais maleável, que aprende relação semântica sem passar pelo ciclo completo de um modelo preditivo customizado. Para arquiteto e admin, é outra ferramenta na caixa, e ferramenta que resolve latência tem efeito cascata em experiência do usuário, SLA de Service Cloud e até em quanto custa manter um agente ativo em produção.
O que eu vejo de mais interessante aqui não é a métrica de milissegundos, é a mudança de mentalidade que isso empurra: parar de tratar todo problema de IA dentro do Agentforce como prego para o martelo do LLM. Todo projeto que eu peguei de agente mal performático tinha a mesma origem, usar modelo generativo para resolver pergunta que era, no fundo, uma classificação simples. Se Koa Decisions cumprir o que promete em Flow e Apex, isso vira argumento de arquitetura concreto na próxima reunião de design: "essa etapa é decisão, não reasoning, vamos resolver com o modelo certo".
- Mapeie, no seu agente ou automação atual, quais pontos são de fato "escolha entre opções conhecidas" (roteamento, triagem, score, sim/não) e quais exigem geração de texto ou raciocínio multi-etapa. Só os primeiros são candidatos a decisão model.
- Teste a demo do Koa Decisions no Trailhead antes de prometer qualquer coisa a cliente. Adicionar uma categoria nova e ver o comportamento sem retreinamento dá noção real de quão rápido isso entra em produção.
- Em projeto de Agentforce já em andamento, reavalie os tópicos e ações que hoje dependem de prompt template genérico só para decidir "qual fila/qual time/qual próximo passo". Esse é terreno fértil para trocar por decisão determinística e mais barata.
- Para quem mexe com Flow e Apex, acompanhe a disponibilização da API e dos componentes nativos: o valor prático chega quando isso vira elemento de Flow ou classe invocável, não só recurso dentro do Agentforce Builder.
Disponibilidade e pacotização ainda estão em aberto: a própria Salesforce deixa claro que preço, empacotamento e disponibilidade por região estão sujeitos a mudança e dependem do contrato do cliente. Não é algo para colocar em proposta comercial fechada ainda, principalmente fora do escopo nativo do Agentforce. Vale também lembrar que decisão model não substitui governança: confidence score baixo ainda precisa de fallback definido, seja para revisão humana, seja para escalonamento a um LLM maior. Não dá para tratar "modelo rápido" como sinônimo de "modelo sempre certo". E para quem já usa HyperClassifier em produção, vale confirmar caminho de migração e se há mudança de comportamento esperada na troca para Koa Decisions.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.
A resposta sai do que está publicado aqui. Se não estiver, ele diz que não sabe em vez de inventar.