Inside Agentforce Multi-Model Routing: Why Your Agent Doesn't Run on One LLM Anymore

Your agent answers a routing question in under a second, then takes six seconds on the follow-up that needed actual reasoning. You pull the session logs expecting a slow Action, and find something stranger: the two turns never touched the same model. That gap is not a bug. It is the architecture now.

On July 8, 2026, Jayesh Govindarajan, Salesforce's EVP of Software Engineering for AI, published a piece on the Salesforce Newsroom explaining how Agentforce inference actually works today. The short version: Agentforce no longer sends every request to one rented frontier model. It splits the work across five specialized in-house models, and keeps the frontier large language model for the one job that genuinely needs it, multi-step reasoning. If you build on Agentforce, this changes how you should think about Topics, latency, cost, testing, and what you tell your security team when they ask "which model does our agent use?"

This guide is the practitioner's read of that disclosure: what the routing layer does, which levers you control, and where the sharp edges are.

What Salesforce actually changed

For the first couple of years, the default agent architecture across the industry was one big model doing everything. Intent detection, safety checks, retrieval ranking, reasoning, response drafting: all of it went through the same frontier LLM call. Govindarajan's piece is blunt about why that stopped scaling. A single rented model running every job is a chokepoint. Your latency is whatever the provider's latency is. The safety logic is a black box you cannot tune. And you pay frontier prices for jobs a model one-hundredth the size handles fine.

Salesforce runs Agentforce across hundreds of thousands of use cases, which means every inference leaves a trace in telemetry. The engineering team mined those traces, found the repeating patterns, and carved them out into small, purpose-built models. The result is a stack of five specialists working alongside one generalist:

• HyperClassifier reads the incoming request and classifies it across as many as 200 possible labels: which Topic it belongs to, which action set applies, whether it should route to a subagent. It answers in roughly 26 milliseconds. The frontier model it replaced took about 1,446 milliseconds for the same job.
• Prompt Injection Defense (PID) screens inputs for injection attacks, trained on the real attack traffic Salesforce sees rather than a generic benchmark.
• A toxicity model scores outputs for harmful content before they reach the user.
• TextEval, a 20-billion-parameter evaluator, checks generated responses for grounding, citation quality, instruction adherence, and whether the task was actually resolved.
• TextRerank handles high-throughput reranking of retrieved documents before they land in the prompt.

The frontier model still exists in this stack. It gets the work it is uniquely good at: planning across steps, deciding which Actions to call in what order, and composing the final response. Everything around that reasoning core has been handed to a specialist.

You will recognize this pattern if you have been around Salesforce architecture long enough. It is the same move as splitting a monolith into services: pull the high-volume, low-complexity work out of the expensive general-purpose path. The difference is that this refactor happened inside a product you consume, mostly without an announcement, and it changes the behavior you observe from the outside.

The single-token trick, and why you should care

The engineering behind HyperClassifier is worth two minutes of your time, because it explains the latency profile you now see in production. Salesforce Engineering published the details in late 2025.

A general LLM asked to classify a request will generate its answer as free text, token by token. "Order_Management_Returns" is a lot of tokens, and every token is a full inference step. Worse, a generative model can hallucinate a label that does not exist, or mangle a label that contains a code. The single-token approach recasts the problem: each class is assigned one unique special token, and the model predicts exactly one token. One step, constant time, no matter how long the class name is. Combined with aggressive KV caching, that is where the 30x speedup comes from.

The accuracy story matters as much as the speed. Govindarajan reports classification accuracy on safety-relevant topics went from 95% to 99% after the swap, and topic drift (the agent wandering off the Topic it should be in) dropped from around 20% to 10%. A specialist beat the generalist at the specialist's own game, which is exactly what you would expect and exactly what the one-big-model era ignored. The same classifier also decides whether a caller has finished speaking in Agentforce Voice, a job where a 1.4-second decision is unusable and a 26-millisecond one is invisible.

Here is the practical takeaway: topic classification is no longer done by the model you selected for your agent. Your Topic names, descriptions, and scope text are being read by a small classifier optimized for label prediction, while your instructions and Action orchestration are handled by the frontier model. Two different model classes are consuming the two halves of your agent configuration.

The levers you control, and the ones you don't

The July disclosure describes the Salesforce-managed layer, which you do not configure. But there is a real configuration surface on top of it, and knowing where it starts and stops is the difference between an informed architecture decision and a cargo-cult one.

Tier 1: Salesforce-managed, no lever. HyperClassifier, PID, toxicity scoring, TextEval, TextRerank. You cannot swap them, tune them, or turn them off. This is also where the Einstein Trust Layer does its masking and audit work. The upside is that these components improve without you shipping anything. The downside is covered in the tradeoffs section below.

Tier 2: the reasoning model, three levers deep. The model that does the actual reasoning is selectable, at three levels of precedence:

• Org default. In Setup, the Select the Model for Agentforce setting picks between Salesforce Default (a managed mix of trusted models, currently including GPT-4.1 for agents built in the new builder and GPT-4o for legacy-builder agents), an AWS-hosted option running Anthropic Claude on Amazon Bedrock inside the Salesforce trust boundary, and a Google Gemini option. Salesforce recommends the default mix, because it retunes the mix as models improve.
• Agent-level override. In Agent Script, model_config on the agent overrides the org default for that agent.
• Subagent-level override. model_config on a subagent overrides both. Subagent beats agent beats org.

The documented, thoroughly-tested options for overrides are GPT-4.1, Claude Haiku 4.5, and Gemini 3.5 Flash. Other supported models can be named, with the documentation's pointed warning that some of them may not suit your agent's tools. Translation: the further you stray from the tested trio, the more of the QA burden is yours.

Tier 3: BYOLLM. You can bring your own model from Amazon Bedrock, Azure OpenAI, OpenAI, or Vertex AI on your own credentials. This is the right lever when you have a hard constraint the managed options cannot meet: data residency, a fine-tuned domain model, a contractual requirement to run inference in your own cloud account. It is the wrong lever for "I read a benchmark and want model X," because you take on model operations, version management, and regression testing that Salesforce was doing for you. The BYOLLM guide covers when that trade makes sense.

One thing BYOLLM does not do: it does not replace the routing layer. Your custom model slots into the reasoning seat. The classifiers, the injection defense, and the evaluators around it stay Salesforce's. If your compliance narrative says "all AI processing happens on our model," it is wrong, and an auditor who reads the July newsroom piece will know it is wrong.

If you run multiple agents and multiple models, the observability and policy questions (which team burned which tokens, which calls left the estate) belong to a different layer entirely. That is AI Gateway's job, and it pairs naturally with the routing architecture described here: routing decides which model runs a step, the gateway decides what every model call is allowed to do and records that it happened.

What this changes about how you build

The multi-model split has direct consequences for the parts of an agent you author.

Write Topic metadata for a classifier, not a reasoner. Your Topic classification descriptions are now consumed by a model whose entire job is picking one label out of up to 200. Vague, overlapping Topic descriptions were always a problem; now they are a measurable one, because the classifier has no frontier-model ability to reason its way around your ambiguity. Make Topic scopes mutually exclusive. Put the distinguishing nouns and verbs in the description, front-loaded. If two Topics could both plausibly claim a common utterance, decide which one wins and say so in the scope text.

Write instructions for the frontier model. Instructions and Action descriptions still land in front of the reasoning model, where nuance and multi-step guidance work. The style that helps a classifier (terse, keyword-dense) is not the style that helps a reasoner (explicit, stepwise). You are writing for two audiences in one config, and knowing which field goes to which audience tells you which register to use.

Test the seams, not just the happy path. Because classification and reasoning are separate models, they fail separately. An agent can classify perfectly and reason badly, or reason beautifully inside the wrong Topic. When you evaluate in Testing Center, look at Topic-selection accuracy as its own metric before you look at response quality. And if you set a model_config override, retest everything: the docs are explicit that you validate your agent against your chosen model, and the Atlas Reasoning Engine's planning behavior differs across models more than demo videos suggest. The same applies to the deterministic pieces: an Action backed by Flow or Apex behaves identically regardless of model, so when an override changes outcomes, you have isolated the failure to the reasoning step.

Budget latency per step class. A turn that resolves inside the classifier fast path costs milliseconds. A turn that needs the frontier model costs seconds. Chained reasoning turns with retrieval cost more. When someone asks "why is the agent sometimes slow," the honest answer is now "which step class did that turn hit?" Design conversations so high-frequency interactions (routing, confirmation, disambiguation) stay on the cheap path and the frontier model is reserved for turns that earn it.

The tradeoffs nobody puts on the slide

The routing architecture is a good trade. It is still a trade, and you should name what you gave up.

Predictability. "Salesforce Default" is a managed mix, and Salesforce reserves the right to retune it. The model behind your agent's reasoning can change without a deploy on your side. Usually that is an upgrade. Occasionally it shifts tone, verbosity, or tool-calling behavior in ways your acceptance tests never covered. If your agent output feeds anything downstream that is format-sensitive, pin the model with model_config and own the upgrade cadence yourself, or build format validation into the Action layer where it belongs.

Debuggability. When one model did everything, "the model got it wrong" was at least a single suspect. Now a bad response has five or six suspects: misclassification, an over-aggressive injection filter, a reranker that buried the right document, a reasoning failure, or an evaluator that let a bad answer through. Your session traces show the outcome, and the intermediate verdicts are Salesforce's internals. Practically, you triage by elimination: check the selected Topic first (classifier), then the retrieved context (reranker), then the reasoning trace. It is more like debugging a distributed system than debugging a prompt, because that is what it is now.

The meaning of "supported model." The Supported Models list keeps growing: GPT-5 series, Gemini 3 variants, Claude Opus and Haiku lines, Nova, Nemotron. It is tempting to read that list as "things my agent can be." Read it instead as "things the reasoning seat can hold." The other five seats are not on the menu, and they touch every request before and after your chosen model does.

Cost visibility. Right-sizing cut Salesforce's own inference spend, which is the headline of the newsroom piece. Whether it cuts yours depends on your consumption model and your conversation mix. A support agent whose traffic is 80% routing and FAQ resolves most turns on cheap specialist inference. An agent doing deep multi-step research burns frontier tokens no matter how clever the routing is. Measure your own turn distribution before assuming the economics moved in your favor.

Five questions to ask before you say "my agent uses model X"

Steal these for your next architecture review.

1. Which model option is set at the org level, and does any agent or subagent override it with model_config?
2. Which parts of each request never touch that model at all? (Classification, injection screening, toxicity, reranking, evaluation.)
3. If Salesforce retunes the default mix tomorrow, what in our stack would notice? What should?
4. Does our compliance documentation describe one model or the actual stack of six?
5. When a response goes wrong, can we tell a Topic-selection failure from a reasoning failure in under five minutes?

If you can answer all five, you understand your agent's inference path better than most teams running Agentforce in production today.

Here is the next step: open one production agent this week and read every Topic classification description in it, knowing a 200-label classifier is the audience. Rewrite the two vaguest ones so their scopes cannot overlap, rerun your Topic-selection tests, and check the drift. That is an hour of work, and it is aimed at the exact model Salesforce just told you is making the first decision on every request.

About the Author

Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.