Pular para conteúdo principal

Salesforce Koa: o modelo de raciocínio de CRM que muda a rota

Camila Duarte
Camila Duarte22 de setembro de 202610 min. de leitura
Salesforce Koa: o modelo de raciocínio de CRM que muda a rota

O Salesforce apresentou o Koa, seu primeiro modelo de raciocínio de CRM para o Agentforce, construído sobre modelos abertos NVIDIA Nemotron e hospedado dentro da própria infraestrutura (salesforce.com/agentforce/koa, semana de 2026-09-14). A implicação direta: o roteamento deixa de perguntar só qual generalista usar e passa a incluir uma decisão de fronteira de dados.

O que aconteceu

O Koa é o primeiro modelo de raciocínio de CRM da Salesforce para o Agentforce. A empresa o construiu sobre modelos abertos NVIDIA Nemotron, com post-training próprio e um dataset sintético. Não é o lançamento de um laboratório de fronteira. É uma decisão de build versus buy tomada por uma plataforma de enterprise que, até agora, consumia modelos de terceiros e agora controla o peso do que serve às suas próprias rotinas de CRM. Esse controle é da Salesforce: o cliente não pode hospedar o Koa por conta própria nem ajustar os pesos.

O número que a Salesforce escolheu para liderar o anúncio é o erro. Segundo a página oficial, o Koa iguala ou supera modelos líderes no CRM Bench, benchmark proprietário da própria Salesforce, com 3x menos erros. A empresa reporta ainda +11% de precisão ao chamar a ação certa, 2.1x de confiabilidade ao recuperar contexto do cliente e 15% melhor desempenho em conversas longas. São métricas de fornecedor, medidas em benchmark de fornecedor, e devem ser lidas como tal até que avaliação independente apareça.

O corpus de treino é inteiramente sintético, sem dados de cliente. A Salesforce diz ter derivado esse corpus de 27 anos de workflows de CRM, cobrindo mais de 14 setores. A escolha importa para quem responde a due diligence: segundo a Salesforce, nenhum dado de cliente cruza a fronteira durante o treino nem durante a inferência. A exposição em tempo de execução não está, portanto, nos pesos do modelo, e sim no harness de serving e no dado de grounding que o cliente elege compartilhar, já dentro da infraestrutura da Salesforce.

O ponto menos comentado do anúncio é a infraestrutura. A Salesforce controla os pesos do Koa e roda a inferência inteiramente dentro da própria estrutura. O modelo não é um endpoint de terceiro chamado pela plataforma: é um ativo hospedado na fronteira de confiança da Salesforce. O que isso remove do caminho de dados não é a plataforma, e sim um fornecedor terceiro de modelo. O anúncio também descreve a postura de serving: a inferência roda com temperatura 0, para respostas consistentes e repetíveis, e um harness de serving dedicado acrescenta controles de confiança e segurança além do próprio modelo. Essa é a diferença estrutural em relação a integrar uma API de fronteira ao Agentforce.

A distribuição chega por três caminhos. O Koa aparece como managed LLM no catálogo de modelos generativos do Data Cloud, selecionável org-wide no Agentforce e no Agentforce builder, no nível de agente ou sub-agente. Com isso, a Salesforce o posiciona como a quarta opção de provedor de modelo no Setup.

O cronograma é declarado, não entregue. A GA está prevista para regiões dos EUA no inverno de 2026, com open beta na sequência. A Salesforce lista pilotos com 1-800Accountant, Baxter Credit Union, Engine, Formula 1, UChicago Medicine e Xero, sem divulgar resultados de nenhum deles. O mesmo anúncio traz o AIforce, que leva dados e permissões de CRM para ferramentas externas de IA, e o ClaudeForce em beta.

Arvore de decisao da rota por fronteira para uma tarefa de CRM: modelo generalista de fronteira ou modelo de dominio dentro do trust boundary, segundo custo por tarefa resolvida e politica por tarefa

Por que isso importa

A decisão de rota ganha uma dimensão nova, e ela não é técnica, é contratual. Até aqui, quem operava agentes no CRM comparava modelos de fronteira entre si: melhor no benchmark genérico, mais barato por token, mais rápido no p99. Esses critérios continuam válidos, mas o Koa introduz uma terceira categoria de candidato ao lado dos generalistas de fronteira e dos modelos abertos genéricos. É um modelo de domínio, com pesos controlados pelo fornecedor da plataforma, rodando dentro da fronteira de confiança da Salesforce e avaliado em benchmark proprietário. O ganho de fronteira aqui não é manter o dado na tenancy do cliente: é retirar um fornecedor terceiro de modelo do caminho, já que o registro e o grounding seguem entrando na infraestrutura da Salesforce.

O que muda na prática é a pergunta. Ela deixa de ser "qual é o melhor modelo para atender o cliente?" e passa a ser uma pergunta em duas partes: quanto do meu volume pode sair do trust boundary, e quanto precisa ficar dentro dele? Para o CTO, isso vira arquitetura. Para o CFO, vira custo por tarefa resolvida. Para o head de produto, vira escolha de quais etapas do fluxo toleram generalista e quais exigem contexto proprietário.

A tese do Koa é que o contexto é o ativo, não o parâmetro. Um modelo treinado em 27 anos de workflows de CRM já viu a forma de um registro de conta, de uma objeção de renovação, de um handoff entre pré-venda e suporte. Um generalista de fronteira é mais forte em raciocínio amplo, mas chega ao CRM sem essa familiaridade estrutural e depende de retrieval para reconstruí-la a cada chamada. É exatamente aí que os 2.1x de recuperação de contexto viram um argumento econômico, e não apenas um número de marketing.

Vale rotular a assimetria. O CRM Bench é da Salesforce, o Koa é da Salesforce, e não foi publicada avaliação independente até o momento desta publicação. A Salesforce é a customer zero avaliando o próprio modelo no próprio benchmark, e o salto reportado é medido contra "os modelos de inteligência geral padrão de hoje" sem nomear quais, em que versão ou de que data. É uma exposição dupla a task-mismatch e distribution shift: o benchmark é do domínio do fornecedor, e a linha de base contra a qual o ganho é calculado não é auditável. A página oficial não informa preço por token do Koa, nem se ele será cobrado à parte dos modelos que já compõem o Agentforce. Sem essas duas informações, o custo por tarefa segue sendo uma conta em aberto, e não um número pronto para o orçamento.

A leitura corrente é que plataformas de enterprise vão continuar consumindo modelos de fronteira. O Koa aponta para o oposto em pelo menos uma camada: quando o domínio é proprietário e o volume é alto, treinar sobre base aberta e hospedar em casa pode sair mais barato do que pagar por token de generalista em cada interação de CRM. A decisão de build versus buy reabre onde o contexto é espesso.

Quem lê o anúncio como "mais um modelo" perde o movimento. O que a Salesforce monta é uma política de roteamento em que o critério já não é a inteligência bruta, e sim onde o dado pode transitar. Esse critério vale para qualquer empresa que roteia agentes sobre dados de cliente, inclusive quem não usa o Agentforce.

O que muda na prática

Antes, a pergunta de rota tinha um eixo só. Agora tem dois. O comparativo abaixo resume o deslocamento para times que operam agentes sobre CRM, com o custo por tarefa no lugar do preço por token como unidade de decisão.

DimensãoRota antes do KoaRota com um modelo de domínio no playbook
Pergunta de decisãoQual generalista de fronteira usarQuanto do volume fica no trust boundary e quanto sai
Custo de referênciaPreço por token de tabelaCusto por tarefa resolvida, com retrabalho contado
Dado no caminhoContexto cruza a fronteira a cada chamadaInferência e grounding ficam na fronteira da Salesforce; some o fornecedor terceiro de modelo
Contexto de CRMReconstruído via retrievalEmbutido no modelo de domínio desde o treino
AvaliaçãoBenchmarks públicos e genéricosBenchmark proprietário de domínio, vendor-reported
Controle de pesosNenhum, o fornecedor do modelo mandaPesos sob o fornecedor da plataforma; cliente não auto-hospeda nem ajusta

A consequência operacional é que a política de rota passa a ser por tarefa, não por modelo. Uma tarefa de qualificação de lead que só lê campos estruturados e devolve um score suporta generalista sem cerimônia. Uma tarefa que lê histórico de conversa, objeção e condição contratual para recomendar uma ação merece o modelo de domínio, porque é ali que o contexto proprietário e a fronteira de dados pesam mais. O erro caro é aplicar a mesma rota a tudo, que é o que a maioria dos times ainda faz por padrão.

Há um segundo efeito, menos óbvio. Fronteira de confiança deixa de ser um tema só de segurança e entra na planilha. Se metade do volume de CRM resolve dentro da fronteira, metade deixa de pagar a tarifa de um generalista externo por interação, e o cálculo de custo por tarefa muda de sinal. O custo por tarefa decide a rota monta essa conta; o que o Koa acrescenta é a coluna "onde o dado trafega" e qual fornecedor de modelo fica no caminho, o que pode inverter o resultado mesmo quando o preço por token favorece o generalista.

Para quem já migrou preços em produção, este é o mesmo tipo de evento tratado no guia de o que fazer quando o preço do token muda: uma mudança que reclassifica candidatos de rota e obriga a repensar defaults. A diferença é que agora a reclassificação não vem só do preço, vem da origem do modelo e do controle de pesos.

O que fazer agora

  1. Mapear tarefas de CRM por sensibilidade do dado antes de escolher modelo. Liste cada etapa do fluxo e marque quais tocam dado de cliente, condição contratual ou histórico de conversa. O mapa define o que pode sair da fronteira de confiança.
  2. Medir custo por tarefa resolvida, não preço por token. Inclua retrabalho, escalonamento humano e a chamada extra de retrieval que um generalista exige para recuperar contexto que um modelo de domínio já traz. A unidade de decisão é a tarefa que termina, não o token que entra.
  3. Tratar o CRM Bench como reportado pelo fornecedor até haver avaliação independente. Quando a Salesforce publicar números de avaliação externa, refaça a conta. Até lá, o 3x menos erros é ponto de partida, não veredito.
  4. Desenhar a política de rota por tarefa, com um modelo de domínio como um dos candidatos. A decisão é entre generalista de fronteira, modelo de domínio e abertos genéricos, e a alocação muda por tarefa, não por preferência de fornecedor.
  5. Colocar a governança de custo acima da escolha de modelo. Roteamento sem teto por chave, por agente ou por projeto devolve a economia para o fornecedor na virada do mês. É o que sustenta a decisão quando o volume cresce.

O Nexforce Router opera exatamente nesse ponto: uma API para 500+ modelos, com política de rota configurável por chave e teto de gasto por agente ou projeto. A pergunta que o Koa torna inevitável, quanto do volume fica dentro da fronteira e quanto sai, é a mesma que qualquer política de rota precisa responder. Quem decide a rota com evidência de tráfego real responde com dado em vez de intuição.

Perguntas frequentes sobre o Salesforce Koa

O Koa está disponível hoje? Ainda não em GA. A Salesforce prevê disponibilidade geral para regiões dos EUA no inverno de 2026, com open beta na sequência. A data é declaração da empresa, não fato consumado, e não houve confirmação de preço ou de empacotamento até a publicação.

O que é o CRM Bench e por que ele merece cautela? É o benchmark de CRM da própria Salesforce, usado como base das métricas do anúncio. Como benchmark e modelo têm o mesmo dono, os números são vendor-reported. Sem avaliação externa, o 3x menos erros e o +11% de precisão devem ser lidos como resultado de fornecedor.

O Koa usa dados de clientes no treino? Segundo a Salesforce, não. O corpus é inteiramente sintético, sem dados de cliente, derivado de 27 anos de workflows de CRM em mais de 14 setores. A empresa afirma que nenhum dado de cliente cruza a fronteira no treino nem na inferência: o Koa só vê o que o cliente escolhe compartilhar, e essa exposição em tempo de execução fica no harness de serving e no dado de grounding eleito, dentro da infraestrutura da Salesforce.

O Koa substitui um modelo generalista de fronteira? Não por padrão. Ele se soma como um terceiro tipo de candidato de rota, ao lado de generalistas de fronteira e de abertos genéricos. A escolha é por tarefa: tarefas sensíveis tendem ao modelo de domínio, que roda na fronteira da Salesforce e dispensa um fornecedor terceiro de modelo, enquanto tarefas abertas seguem para o generalista.

O que isso muda para quem não usa o Agentforce? O mecanismo, não o produto. Qualquer empresa que roteia agentes sobre dados de cliente enfrenta a mesma pergunta de fronteira: quanto do volume pode sair do trust boundary. O Koa é a evidência de que um fornecedor de plataforma achou vantajoso controlar pesos e hospedagem para responder a ela.

Referências e Leitura Complementar

  • Salesforce, página oficial do anúncio do Koa: https://www.salesforce.com/agentforce/koa (semana de 2026-09-14; reverificada em 2026-09-22). Fonte primária de todos os números desta análise. Os valores de CRM Bench são reportados pelo fornecedor.
  • Salesforce AI Research, CRM Bench: https://www.salesforceairesearch.com/crm-benchmark (benchmark proprietário, sempre rotulado como reportado pelo fornecedor; no momento desta publicação o endereço não respondeu às verificações, e o dado foi mantido conforme o briefing, com a ressalva aplicada no corpo).

Para onde isso aponta

O Koa ainda é um anúncio, com GA prevista para o inverno de 2026 e pilotos sem resultados publicados. O sinal, porém, já está claro: o roteamento passa a ser uma decisão de fronteira de dados, não só de preço por token. O próximo dado que reordena essa conta é a avaliação independente do CRM Bench, e quem opera agentes sobre CRM deveria acompanhá-la. A posição da Nexforce sobre custo por tarefa está em o custo por tarefa decide a rota, e a camada prática de roteamento, no Nexforce Router.

Nexforce

Acelere a eficiênciaoperacional do seu negócio

Nós desenhamos a tecnologia do amanhã para impulsionar a escala do negócio

Falar com Especialista

Artigos relacionados