Salesforce Koa: What a CRM Reasoning Model Changes in Your Org

Salesforce announced Koa on 15 September at Dreamforce '26: its first CRM reasoning model, built by post-training NVIDIA's Nemotron 3 Super. The coverage framed it as a product launch. In your org it is something narrower and more consequential — a new entry in a dropdown you have already used, sitting in the same seat currently occupied by Salesforce Default, Claude Haiku 4.5 on Bedrock, or Gemini.

That framing matters, because it tells you what the work is. Nobody has to build anything to adopt Koa. Somebody has to retest everything.

What was actually built

Koa starts from NVIDIA Nemotron 3 Super, an open model with a specific shape worth knowing: 120 billion total parameters with roughly 12 billion active per token, using NVIDIA's LatentMoE mixture-of-experts routing over a hybrid of Mamba-2 state-space layers and standard attention, with multi-token prediction heads for speculative decoding and support for up to a million tokens of context. The short version is large-model capacity on small-model inference economics, which is the entire reason a CRM vendor can afford to run one per-turn inside its own data centres.

Salesforce then post-trained it with supervised fine-tuning followed by reinforcement learning using Group Relative Policy Optimization, on NVIDIA's NeMo RL, NeMo Gym and NeMo AutoModel stack. The training data was synthetic throughout — scenarios modelled on about 27 years of CRM deployments across 14 or more industries, covering lead generation, opportunity qualification and service case resolution. Salesforce is explicit that no customer data was involved, and that inference happens entirely within its own infrastructure with the weights under its control.

Benioff's framing in the keynote was that "the knowledge is put inside the model itself." Strip the marketing and the claim is a real architectural bet: encode deal structure and case lifecycle into weights, rather than re-teaching them through prompt instructions on every single turn.

Where it plugs in, and what it does not touch

There are three documented ways to select it, and the distinction between them is the whole risk profile of adoption:

• Org-wide, in Agentforce Setup, as the model provider. This applies to every agent in the org.
• Per agent or subagent, through model_config in Agent Script. Subagent beats agent beats org default, so the narrowest scope wins.
• As a managed model in the Data Cloud Generative Models catalogue, available to prompt templates and AI apps.

If you have already split work across Agentforce subagents, the second option is the one to use. Pinning a single subagent — one with a well-understood, high-volume, low-blast-radius job — gives you a controlled comparison against the rest of the org still running your current model. The org-wide switch gives you a changed variable across every agent simultaneously and no control group.

What a model swap does not touch is equally important. The reasoning model is one step in a chain. Topic classification runs before it and decides which instructions the model ever sees. Grounding retrieval runs alongside it and decides which records it reasons over. The Einstein Trust Layer wraps both ends. A different reasoning model is a different planner and action-selector, not a different Atlas reasoning pipeline. If your agent is picking the wrong topic, or your retriever is returning the wrong account, Koa will reason beautifully about the wrong thing.

This is the same reason data quality gates the outcome more than model choice does. A specialised model raises the ceiling on the step it owns. It does not raise the floor underneath the steps it does not.

The numbers, and what they are worth

Salesforce publishes four figures. On its CRM Bench benchmark, Koa "matches or exceeds leading model performance on CRM actions with three times fewer errors." On the product page there are three more specific deltas: 11% more accurate at calling the right action, 2.1x better at recalling customer context, and a 15% improvement at retaining conversation history across extended exchanges.

Read those carefully and note what is missing. There is no named comparison model, no published base error rate — three times fewer errors than 30% and three times fewer than 3% are very different products — no methodology paper, and no independent replication. CRM Bench is Salesforce's own instrument, measuring Salesforce's own model.

The useful calibration is Salesforce's own published research. CRMArena-Pro, the benchmark Salesforce AI Research released for exactly this class of task, runs 19 expert-validated sales, service and CPQ tasks against a sandbox org holding tens of thousands of interconnected synthetic records. On it, frontier models managed roughly 58% success on single-turn tasks, falling to about 35% once the dialogue became multi-turn. That is the honest baseline the industry is working from. A genuine 3x error reduction against a number like that is a significant engineering result and still not a model you leave unsupervised on a renewal.

So: pilot it. Do not migrate a production service agent on the strength of a vendor benchmark, and do not dismiss it either.

Temperature 0 is the part that changes your testing

The detail in the Koa documentation most likely to change your week is that it runs at temperature 0, with a dedicated serving harness, for consistent and repeatable responses.

Deterministic-by-default output is what makes an agent regression suite worth building. Against a sampling model, a test that asserts on output is flaky by construction, which is why most teams quietly gave up and tested by hand. At temperature 0, the same input and the same context should produce the same plan, and a diff in behaviour becomes a signal instead of noise.

Build the suite around what the agent did, not what it said:

• Which action was invoked, and with which argument values.
• Which subagent or topic was selected for a given utterance.
• Whether the run terminated, escalated, or looped.
• Whether a guarded action fired when its precondition was false.

Capture 20 to 40 real transcripts per high-traffic topic, pull them from session logs, and record the current model's behaviour as a baseline before you enable Koa anywhere. Without that baseline, a pilot produces opinions.

The corollary is less comfortable. Determinism also removes the accidental recovery that sampling sometimes provides on a badly phrased instruction. A vague instruction that occasionally lands correctly under sampling can land wrong every single time at temperature 0. Consistency exposes instruction debt rather than absorbing it.

The constraints that may decide this for you

General availability is Winter 2026, in U.S. regions only. No international date has been given, and no pricing has been published for Koa or for the AIforce layer announced alongside it. If your org runs on EU or APAC infrastructure, there is nothing to plan around yet beyond building the regression baseline, which is worth doing regardless of which model you end up on.

One more ceiling is easy to miss. Nemotron 3 Super supports up to a million tokens of context, and that number will get quoted at you. The Einstein Trust Layer limits every supported model to a context size of 65,536 tokens while data masking is enabled. If masking is on in your org — and for most regulated deployments it is — the base model's context window is not the constraint that governs you. Size grounding payloads and conversation retention against 65k, not against 1M.

What to watch for

• The model option applies to all Agentforce agents when set at org level, and Salesforce's own guidance is to retest every prompt, custom action and subagent after switching. Treat an org-level change as a release, with a rollback plan, not as a setup tweak.
• model_config at subagent scope beats agent scope beats org default. Use that precedence to run a real A/B rather than a vibe check.
• Inference inside Salesforce infrastructure changes your data path relative to the AWS-hosted and Google options. If a DPIA or vendor review drove your current model choice, that review needs rerunning — potentially in your favour.
• Koa being CRM-specialised is a constraint as well as a feature. Work that is not CRM-shaped — freeform drafting, code generation, document summarisation at length — has no published evidence behind it here, and external LLMs via BYOLLM remain the answer for those.
• Pilot customer lists are selection-biased by definition. Formula 1 and UChicago Medicine were chosen partly because their data was ready. Ask what shape their org was in before reading their results onto yours.
• Nothing about Koa changes what happens when an agent calls a tool that fails. Error paths, escalation and human-in-the-loop checkpoints are still yours to design, and a better planner makes a broken action fail more confidently.