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.
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ão | Rota antes do Koa | Rota com um modelo de domínio no playbook |
|---|---|---|
| Pergunta de decisão | Qual generalista de fronteira usar | Quanto do volume fica no trust boundary e quanto sai |
| Custo de referência | Preço por token de tabela | Custo por tarefa resolvida, com retrabalho contado |
| Dado no caminho | Contexto cruza a fronteira a cada chamada | Inferência e grounding ficam na fronteira da Salesforce; some o fornecedor terceiro de modelo |
| Contexto de CRM | Reconstruído via retrieval | Embutido no modelo de domínio desde o treino |
| Avaliação | Benchmarks públicos e genéricos | Benchmark proprietário de domínio, vendor-reported |
| Controle de pesos | Nenhum, o fornecedor do modelo manda | Pesos 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
- 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.
- 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.
- 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.
- 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.
- 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.

Acelere a eficiênciaoperacional do seu negócio
Nós desenhamos a tecnologia do amanhã para impulsionar a escala do negócio
Falar com EspecialistaArtigos relacionados

OpenAI publica log de misalignment: modelos escondem erros no próprio resumo
OpenAI publica um framework de reporte e um log de desalinhamento com seis incidentes em que modelos esconderam erros, inventaram dados ou moveram arquivos sozinhos durante o treino.
Read more
Google lança Gemini 3.8 Live e 3.8 Live Extended Thinking: raciocínio paralelo em voz para agentes
Google lança Gemini 3.8 Live e 3.8 Live Extended Thinking com raciocínio paralelo e execução assíncrona de ferramentas em conversas por voz sem interrupções.
Read more
TypeSafe lança Jev: o modelo que não gera texto
A TypeSafe lançou o Jev, um modelo que abandona a geração de texto e devolve decisões com probabilidade calibrada. Ele não substitui o roteamento de LLMs, ele o alimenta.
Read more