Salesforce says a frontier model still handles the core reasoning in its agents, and five smaller models now do the surrounding work: routing, attack screening, output screening, answer checking and result ranking.

What Salesforce disclosed

In a July 8 engineering post, Jayesh Govindarajan, EVP of Software Engineering at Salesforce AI, laid out how the company restructured the model layer under Agentforce. Salesforce followed it on October 13 with a newsroom interview in which Chief Data Officer Michael Andrew described the customer-facing result: the freedom to pick a frontier, open or custom model for each use case.

Govindarajan described the starting point plainly. “Eighteen months ago, Agentforce also ran entirely on a single rented model, and our token bill grew linearly with traffic,” he wrote. Salesforce says it chose to rebuild instead of repricing. It split the work into jobs and tuned open-source models for each one, working from patterns in the telemetry of the jobs its agent framework had already processed. A frontier model still handles the core multistep reasoning, and Salesforce says the framework built around it lets customers and Salesforce swap that foundation model freely.

Advertisement

Simplified Management — Advertisement

The five models, job by job

The post lists five models and the single job each one does.

  • HyperClassifier reads the request and routes it. Salesforce fine-tuned it on OpenAI’s GPT-OSS-20B and says it classifies a topic across up to 200 labels in roughly 26 milliseconds, against about 1,446 milliseconds for a general frontier model. It became generally available in Spring ’26 and is the default routing model for Agentforce Service and Employee Agent templates.
  • The prompt injection model checks whether a request is an attack. Salesforce trained it on the surfaces it considers most likely to carry one: CRM field values, inbound email bodies, form inputs and transcript content. It covers six attack types and logs an injection score to an audit trail. It is rolling out as generally available in Summer ’26, and a blocking mode is in development.
  • The toxicity model scores every model response for violent, sexually explicit, hateful or physically harmful content before it reaches the user, and logs the score.
  • TextEval judges the answer. It is a 20-billion-parameter model that checks grounding in the customer’s data, citations, instruction adherence and whether the task was resolved. Salesforce says admins cannot modify the check.
  • TextRerank orders the results retrieval pulls back before they reach the reasoning engine, and Salesforce says it moved from third-party hosting to Amazon Bedrock with no customer-facing downtime.

Salesforce gives accuracy figures for the routing model only. Safety topic accuracy rose from 95% to 99%, and drift in multi-turn conversations, the pull toward off-topic answers, fell from about 20% to about 10%.

Why the checker is a separate model

The design choice with the most consequence for buyers is that the model that writes an answer does not grade it. Salesforce’s post says a language model can have a blind spot when judging its own work and tends to give itself the benefit of the doubt. So the toxicity screen and TextEval are separate models, and both write to the Einstein Trust Layer audit trail.

That matters to anyone reading vendor claims about agent quality. We examined the evidence behind Koa, Salesforce’s own reasoning model, in a column on its benchmark, and we described the broader move to vendor-trained models in our earlier report. A separate checker that logs a score gives an admin something to audit after the fact, which a model’s own confidence does not.

The industry pattern

Salesforce is describing a division of labor that other revenue vendors are also moving toward. The large model reasons across steps. Small, fast, narrowly tuned models handle the high-volume steps that run on every request, where latency and cost accumulate. The surrounding rules decide what the agent may do, a layer we examined in our piece on the rules layer between agent and action.

Newsletter

Get the week's best tech coverage.

Free. Read by thousands of HR, tech, and business leaders.

Andrew framed the buyer side in the October 13 interview. “We believe in giving our customers choice, that you can pick the model that’s right for your particular use case,” he said, and he named speed of resolution and cost as the criteria. The same interview says Koa is orchestrated alongside frontier models rather than in place of them.

In our reading, vendors can swap the reasoning model fairly easily, so routing, screening, checking and ranking are where sales-AI products will differ on a real account. Salesforce’s other recent moves, including the layers we mapped in its five acquisitions, point the same direction.

What it means for the sales leader

A sales leader evaluating any agent product, from Salesforce or another vendor, can turn the design above into a question set. The answers should come in writing, because the answers decide how the product behaves on a live account with real customer data in it.

  • Ask which model routes a request and how long that step takes on a typical account.
  • Ask which model screens inbound text from emails, forms and call transcripts for injected instructions, and whether it blocks or only scores.
  • Ask who grades the agent’s answer and whether the grader is the model that wrote it.
  • Ask where those scores are logged and whether your RevOps admin can export them.
  • Ask whether you can change the reasoning model without changing the checks around it.

The Salesforce post publishes latency and accuracy figures for the routing model. Buyers can ask any vendor for the same kinds of measurements, run on their own accounts and call data, before they sign.

Source: Salesforce Newsroom