Which model should your Agentforce agent run on? The model menu, the per-subagent override, and how to actually choose

For most of Agentforce’s life, “which model does it use?” was a question with a boring answer: whatever Salesforce picked. You built topics and actions, the reasoning engine ran on a managed model behind the Einstein Trust Layer, and the model was somebody else’s decision. That was fine, right up until you had two agents with genuinely different needs — one doing high-volume, latency-sensitive case triage, another doing careful multi-step reasoning over a gnarly sales process — and no way to give them different engines.

That’s changed. Agentforce now lets you choose your foundation model from a menu of providers, and — the more interesting shift — as of 2026 you can set a different model per subagent, so one agent can run a fast cheap model on its simple topics and a stronger model on its hard ones. This is real power, and it’s also a new and inviting way to break something that worked. The temptation is to treat model selection like buying a graphics card: pick the newest, highest-benchmark option and call it an upgrade. That instinct is wrong often enough to be expensive. This post is what’s actually on the menu, the catch that bites when you leave the default, and a way to choose that isn’t vibes.

What’s actually on the menu

Agentforce’s model selection is organized by provider, with a Salesforce-managed default sitting on top. The important thing to understand before any version numbers is the shape of the menu, because the shape is stable even though the exact models refresh constantly.

• Salesforce Default. Not a single model — a managed mix of trusted models that Salesforce selects and tunes for accuracy, trust, and performance, and swaps under you as better options ship. Historically this has been anchored on OpenAI’s GPT-4o. If you do nothing, this is what runs, and for a large share of agents it’s the correct answer precisely because you’re outsourcing the “keep it current” problem to Salesforce.
• OpenAI. The original and default provider. The relevant fact for architects isn’t the version — it’s that the OpenAI path is the one validated against all of Agentforce’s standard actions (more on why that matters in a moment).
• Anthropic (Claude). A family of Claude models spanning fast/cheap through high-reasoning tiers, available directly and — for teams that want it in their own cloud — as an AWS-hosted option running Claude on Amazon Bedrock.
• Google (Gemini). The Gemini family, again spanning a fast/lightweight tier and a stronger reasoning tier.

I’m deliberately not printing a version table. Salesforce updates the Supported Models list often enough — new Claude, Gemini, and GPT versions land on a cadence measured in weeks, not releases — that any exact list I write here is stale by the time you read it. That volatility is itself a design input: if you pin a specific named model, you own keeping it current; if you use the Salesforce Default, Salesforce owns it. Check the official Supported Models doc for the exact versions available in your org today, and treat the provider-level shape above as the durable part.

This is a different question from bringing your own LLM — a self-hosted or third-party model wired in through Model Builder or the Open Connector. That’s about a model Salesforce doesn’t host. This post is about choosing among the foundation models Salesforce does host, plus the new ability to mix them within one agent.

The catch: standard actions and the non-default model

Here’s the sentence in the docs that deserves a highlighter, because it’s the thing that turns a “quick model swap” into a support case. OpenAI is the default provider and it supports all of Agentforce’s standard actions. The implication, stated plainly: when you move an agent off the default onto another provider’s model, you cannot assume every standard action behaves identically. Some are validated and optimized against the default path; a different model may handle a standard action differently, or a specific standard action may not be supported on it at all.

The nuance that keeps this from being a blanket “don’t switch”:

• Custom actions are model-portable. Actions that execute a prompt template, run Apex, or call the Models API can use any Salesforce-managed or bring-your-own model. If your agent’s real work lives in custom actions — as it does in most serious builds — you have a lot of freedom to pick the model, because your logic isn’t riding on standard-action behavior.
• The reasoning engine and the standard actions are where you tread carefully. The Atlas reasoning engine uses the selected model to plan and pick actions, and the standard action library is what Salesforce ships and validates. Change the model under those and you’ve changed the substrate your agent’s decisions are made on — sometimes for the better, sometimes in ways only a regression test catches.

The practical rule: the more your agent leans on standard actions and out-of-the-box behavior, the more a model swap needs testing; the more it leans on your own custom actions and prompts, the more freedom you have. Know which kind of agent you’re changing before you change it.

The genuinely new part: a different model per subagent

The 2026 addition worth building around is Model Override — the ability to specify a different model for an individual subagent rather than being stuck with one model for the whole agent. (Recall that what used to be called Topics are now subagents, routed by the Agent Router; the override operates at that grain.) You set an agent-level default and then override specific subagents that have different needs. You can configure it in the builder, and you can express it in code through Agent Script with its “specify different models” construct, which is the better path when you want the choice reviewed, versioned, and deployed like the rest of your metadata rather than clicked in a UI.

Why this matters more than a global model picker: real agents are not uniform. One agent frequently spans a trivial subagent (classify this case, look up an order status) and a hard one (reason across a customer’s history and entitlement to decide a remedy). Forcing both onto the same model means either overpaying for a strong model on the trivial path or under-serving the hard path with a cheap one. Per-subagent override lets you match the engine to the job:

• Fast, cheap model on the high-volume, low-judgment subagents — the classification, the lookups, the “route this correctly” work where a lightweight model is both sufficient and dramatically cheaper at volume.
• Stronger reasoning model on the low-volume, high-judgment subagents — the multi-step, ambiguous, consequential paths where a better model changes the outcome and the volume is low enough that the cost per run barely registers.

This is the same instinct as matching batch versus streaming to real freshness needs in Data 360: stop paying premium rates on the paths that don’t need them. Except here the meter is Flex Credits, and the lever is which model reasons on which topic.

What model choice does not change: the Trust Layer

A recurring fear when teams first see the model menu: “if we switch to a third-party model, does our data leave the safe zone?” No — and understanding why is load-bearing for the whole decision.

Every model in the menu, whatever the provider, is called through the Einstein Trust Layer. Salesforce has negotiated zero-data-retention terms with the providers — OpenAI, Azure OpenAI, Anthropic, Google, and others — under which your prompts and completions are not stored on the provider side, not logged for human moderation, and not used to train their models. The Trust Layer’s grounding, masking, and toxicity checks wrap the call regardless of which model sits behind it. So switching from the default to Claude or Gemini is a decision about capability, cost, and latency — it is not a decision that trades away the data-protection posture. That posture is architectural, and it holds across the menu.

The one place to stay alert: the AWS-hosted / Bedrock and bring-your-own options change where the model runs, and if you deliberately route to a model in your own cloud you own that environment’s controls. That’s a feature for regulated teams who want the inference in their own tenancy — just be clear-eyed that “in my cloud” means “my responsibility” for that leg.

How to actually choose

Resist “use the newest, highest-benchmark model.” Benchmarks are a leaderboard; your agent is a workload. Salesforce’s own selection criteria are the right four axes, and they trade off against each other:

1. Capabilities — can the model do the kind of thing this subagent needs? Long-context reasoning, tool use, structured output, multilingual. A model that tops a general leaderboard but handles tool-calling worse is a downgrade for an agent whose whole job is calling actions.
2. Quality — how good are the responses on your tasks? Use a public signal like the LMSYS Chatbot Arena as a starting point, never the finish line. The only quality measure that counts is your own eval set run against your own agent.
3. Cost — every run bills Flex Credits, and a stronger model on a high-volume subagent multiplies straight into the invoice. This is exactly why per-subagent override exists: pay for capability only where capability changes the outcome.
4. Speed — latency is part of the product. On a customer-facing service agent, a model that’s marginally smarter but noticeably slower can be a worse experience than a faster one that’s good enough. On an async, event-triggered back-office agent, nobody’s watching a spinner, so you can spend latency on quality freely.

Then — and this is the step people skip — test the change before it’s live. A model swap is a behavior change to a production system, and it deserves the same rigor you’d give any agent change: run your utterance batches and full-conversation simulations on the new model in a sandbox, diff the outcomes against the current model, and look specifically at the standard-action paths and the hard subagents. “It’s a newer model, it must be better” is a hypothesis, not a result. The eval is how you find out that the smarter model got chattier, or started picking the wrong action, or quietly regressed on the one topic that mattered.

The takeaway

Model selection went from a decision Salesforce made for you to a lever you can pull per subagent — and like most new levers, it’s as easy to hurt yourself with as to help. Three things keep it useful. Default is a real answer: if you don’t have a specific reason to move, the Salesforce-managed default keeps you current for free and supports every standard action. Override with intent, not novelty: put cheap fast models on the trivial high-volume subagents and strong models on the rare hard ones, and let the credit math justify each choice. And test every swap like the production change it is, with an eye on the standard-action paths that the default validates and other models might not. Do that, and per-subagent model choice becomes what it should be — a cost-and-quality dial you tune deliberately, not a shiny button that occasionally breaks a working agent. Tuning that dial against real transcripts, not benchmarks, is a normal part of how our Agentforce practice keeps agents both good and affordable — and the ROI calculator is a quick way to see how much the cost side actually moves.

Understanding the basics

What LLM does Agentforce use by default?

By default, Agentforce runs on the Salesforce Default model — a managed mix of trusted models that Salesforce selects and tunes for accuracy, trust, and performance, historically anchored on OpenAI’s GPT-4o and updated by Salesforce over time. You don’t have to choose a model at all; if you leave the default in place, Salesforce keeps it current for you and it supports the full library of standard actions. You can override it with a specific provider’s model — OpenAI, Anthropic’s Claude, Google’s Gemini, or a Claude model hosted on Amazon Bedrock — when you have a concrete capability, cost, or latency reason to.

Can you use a different model for each Agentforce agent or subagent?

Yes. As of 2026, Agentforce supports per-subagent Model Override: you set an agent-level default model and then assign a different model to individual subagents that have different needs. You can configure it in the builder or express it in Agent Script. The typical pattern is a fast, inexpensive model on high-volume, low-judgment subagents (classification, lookups) and a stronger reasoning model on the low-volume, high-judgment ones, so you pay for capability only where it changes the outcome.

Does changing the Agentforce model affect data security?

No. Every model in the menu is called through the Einstein Trust Layer, which enforces zero-data-retention agreements with the providers — prompts and completions aren’t stored provider-side, aren’t logged for moderation, and aren’t used to train their models — plus grounding, masking, and toxicity checks, regardless of which model you select. Switching models is a decision about capability, cost, and latency, not about data protection. The exception is if you deliberately route to a model in your own cloud (an AWS-hosted or bring-your-own option), where you own that environment’s controls.

---

Not sure whether a model swap is an upgrade or a regression waiting to happen? Talk to us — matching models to subagents so an agent is both good and affordable is exactly the kind of tuning we do against real transcripts.