Dreamforce week produced roughly ten thousand photos of the same keynote slide. Benioff and Jensen Huang on stage, the Koa announcement behind them, phones up across Moscone. Fair enough. Salesforce building its own reasoning model is a big deal.

Meanwhile, in your org, there is a screen almost nobody has opened. Setup, Quick Find, type “Audit, Analytics, and Monitoring,” then Einstein Audit, Analytics, and Monitoring Setup. Inside it sits a section called Select the Model for Agentforce. Whatever is selected there right now is reasoning over your accounts, your cases, and your opportunities, on every agent you have deployed.

Most teams have never changed it. For two years that was a reasonable position, because the choice was thin and the differences were marginal. That is no longer true. Gemini went generally available in the Agentforce Reasoning Engine at Dreamforce, Anthropic and NVIDIA models are live through Amazon Bedrock, OpenAI models on Bedrock were announced as coming, and Koa joins the list when pilots open in October.

How Agentforce Got Here

Read that timeline as a single trend and it is obvious where this went. Agentforce started as one model you could not see. It is now a menu you are expected to manage.

Salesforce and NVIDIA announced Koa on September 15. The build approach matters more than the branding: Salesforce took NVIDIA’s Nemotron 3 Super, an open model, and post-trained it on a proprietary synthetic dataset modeled on enterprise knowledge from close to three decades of CRM deployments. Not customer records. Synthetic data shaped by how businesses actually run their processes, workflows, and operational policies.

The benchmark claim is specific, which I appreciate. Salesforce ran a suite of real CRM tasks, things like updating an opportunity, routing a case, scheduling a follow-up, and reports that Koa matches or beats leading models on those actions with three times fewer errors. That is a narrow claim about a narrow job. It is also exactly the job your agents do all day.

Why Build Rather Than Rent

There is a strategic read here too. Salesforce picked an open-weight base specifically so it could own what happens after training. When the weights are yours, the deployment story, the residency story, and the regulated-industry story all become yours to control. Ask anyone who has tried to get a public sector security review past a third party inference endpoint how much that is worth.

Forget Koa for a minute. Open the Setup screen from section one and look at what is already selectable, because this is the surface you will be managing for the next several years.

That Setup selection is org-wide. Every Agentforce agent you own inherits it. If that were the whole story, model choice would be a one-time debate in an architecture review and then nobody would think about it again.

It is not the whole story. Since the May 2026 release, Agent Script supports a model_config block that overrides the default for a specific agent or a specific subagent, and Agentforce Builder now exposes that as a Model Override picker so you are not hand-typing model API names into a script anymore.

The Precedence Stack

AGENT SCRIPT// Model API names come from the Model Override picker in Agentforce Builder.
agent service_operations:
  model_config:
    model = "model://<agent_level_model_api_name>"

  subagent resolve_billing_dispute:
    // Harder reasoning, more tool hops, higher cost of a wrong write.
    model_config:
      model = "model://<stronger_model_api_name>"

  subagent check_order_status:
    // Inherits the agent-level model. One hop, low blast radius.

Here is the part that turns model selection from an engineering preference into a budget conversation.

Under Flex Credits, you buy credits at $500 per 100,000 and a standard Agentforce action consumes 20 of them, so roughly ten cents per action. A voice action runs 30 credits. An action is metered up to a token ceiling, and when a single action pushes past that ceiling it bills as more than one action. Published guidance puts the standard ceiling around 10,000 tokens, which sounds generous until you count system instructions, user input, prompt template text, retrieved grounding chunks, and the response, all in the same bucket.

Now think about what an error costs. The agent picks the wrong tool. That call is an action. It gets a result it cannot use, reasons again, and calls the right tool. Another action. If the first write went through before anyone noticed, you also get a correction action and an unhappy record owner. A model that errs three times less often produces shorter action chains. Shorter chains cost less and break less.

Those three numbers are illustrative, not a rate card. Your own action counts come out of the Digital Wallet and your usage reports, and you should pull them before you argue for anything. The pattern holds regardless of the exact figures: accuracy compounds downward through the bill, and it compounds hardest on the agents with the longest tool chains.

Model selection is a new discipline for most Salesforce teams, and there is no established practice to copy yet. Here is the approach I would run, structured around the three things you actually control.

None of this requires Koa. Run it now against the three options you already have, and when pilots open in October you will have a test harness ready instead of a hunch.

Koa is in pilot, not in your org, and a few things are still open. None of them are reasons to sit still. They are just the items that belong on your plan rather than in your assumptions.

The router deserves a specific mention. If your agent uses EinsteinHyperClassifier for subagent classification, that piece stays on a Salesforce-owned model and comes with real constraints, no before_reasoning or after_reasoning hooks and only the @utils.transition tool. That is a deliberate trade for classification speed and accuracy. Know it is there so you are not debugging a routing behavior you assumed was coming from your chosen model.

Terms You Will Hear This Quarter

For most of the last two years, the honest answer to “which model is Agentforce using?” was a shrug and a link to the docs. That era closed on September 15. Salesforce now ships a model trained on how CRM work behaves, alongside three others you can select per subagent, with a billing model that quietly rewards whichever one gets the tool call right the first time.

So the interesting question is not whether Koa beats Claude or Gemini on somebody’s benchmark. It is narrower and more useful than that. Which of your subagents is doing work hard enough to deserve a different model, and can you prove it with your own data before somebody asks?