Salesforce Koa: CRM reasoning model for Agentforce

Salesforce introduced Koa, its first CRM reasoning model for Agentforce, built on open NVIDIA Nemotron models and hosted inside its own infrastructure (salesforce.com/agentforce/koa, week of 2026-09-14). The direct implication: model routing stops asking only which generalist to use and starts including a data-boundary decision.

What happened

Koa is Salesforce's first CRM reasoning model for Agentforce. The company built it on open NVIDIA Nemotron models, with its own post-training and a synthetic dataset. This is not a frontier-lab release. It is a build-versus-buy decision made by an enterprise platform that, until now, consumed third-party models and now controls the weights of what serves its own CRM routines. That control belongs to Salesforce: the customer cannot self-host Koa or fine-tune the weights.

The number Salesforce chose to lead the announcement is error rate. According to the official page, Koa matches or beats leading models on the CRM Bench, Salesforce's own proprietary benchmark, with 3x fewer errors. The company also reports +11% accuracy in calling the right action, 2.1x reliability in retrieving customer context, and 15% better performance in long conversations. These are vendor metrics, measured on a vendor benchmark, and should be read as such until independent evaluation appears.

The training corpus is entirely synthetic, with no customer data. Salesforce says it derived that corpus from 27 years of CRM workflows, covering more than 14 industries. The choice matters to anyone answering due diligence: according to Salesforce, no customer data crosses the boundary during training or inference. Runtime exposure therefore does not sit in the model weights, but in the serving harness and the grounding data the customer elects to share, already inside Salesforce infrastructure.

The least discussed point of the announcement is the infrastructure. Salesforce controls Koa's weights and runs inference entirely inside its own structure. The model is not a third-party endpoint called by the platform: it is an asset hosted on Salesforce's trust boundary. What that removes from the data path is not the platform, but a third-party model provider. The announcement also describes the serving posture: inference runs at temperature 0, for consistent and repeatable answers, and a dedicated serving harness adds trust and safety controls beyond the model itself. That is the structural difference from integrating a frontier API into Agentforce.

Distribution arrives through three paths. Koa appears as a managed LLM in the Data Cloud generative model catalog, selectable org-wide in Agentforce and in Agentforce builder, at the agent or sub-agent level. With that, Salesforce positions it as the fourth model-provider option in Setup.

The timeline is declared, not delivered. GA is expected for US regions in winter 2026, with open beta following. Salesforce lists pilots with 1-800Accountant, Baxter Credit Union, Engine, Formula 1, UChicago Medicine, and Xero, without disclosing results from any of them. The same announcement brings AIforce, which carries CRM data and permissions into external AI tools, and ClaudeForce in beta.

Why this matters

The routing decision gains a new dimension, and it is not technical, it is contractual. Until now, whoever ran agents on the CRM compared frontier models against each other: better on a generic benchmark, cheaper per token, faster at p99. Those criteria remain valid, but Koa introduces a third category of routing candidate next to frontier generalists and generic open models. It is a domain model, with weights controlled by the platform vendor, running inside Salesforce's trust boundary and evaluated on a proprietary benchmark. The boundary gain here is not keeping data in the customer tenancy: it is removing a third-party model provider from the path, since the record and the grounding still enter Salesforce infrastructure.

What changes in practice is the question. It stops being "which is the best model to serve the customer?" and becomes a two-part question: how much of my volume can leave the trust boundary, and how much needs to stay inside it? For the CTO, that becomes architecture. For the CFO, it becomes cost per resolved task. For the head of product, it becomes a choice of which steps in the flow tolerate a generalist and which require proprietary context.

Koa's thesis is that context is the asset, not the parameter. A model trained on 27 years of CRM workflows has already seen the shape of an account record, a renewal objection, a handoff between pre-sales and support. A frontier generalist is stronger at broad reasoning, but arrives at the CRM without that structural familiarity and depends on retrieval to rebuild it on every call. That is exactly where the 2.1x context retrieval turns into an economic argument, not just a marketing number.

The asymmetry deserves a label. The CRM Bench belongs to Salesforce, Koa belongs to Salesforce, and no independent evaluation had been published at the time of this article. Salesforce is customer zero evaluating its own model on its own benchmark, and the reported jump is measured against "today's standard general intelligence models" without naming which, at what version, or from what date. It is a double exposure to task mismatch and distribution shift: the benchmark belongs to the vendor's domain, and the baseline against which the gain is calculated is not auditable. The official page does not disclose Koa's price per token, nor whether it will be billed separately from the models that already compose Agentforce. Without those two pieces of information, cost per task remains an open account, not a number ready for the budget.

The current reading is that enterprise platforms will keep consuming frontier models. Koa points to the opposite in at least one layer: when the domain is proprietary and the volume is high, training on an open base and hosting in-house can cost less than paying per token for a generalist on every CRM interaction. The build-versus-buy decision reopens where the context is thick.

Whoever reads the announcement as "one more model" misses the movement. What Salesforce assembles is a routing policy in which the criterion is no longer raw intelligence, but where the data may travel. That criterion applies to any company that routes agents over customer data, including those that do not use Agentforce.

What changes in practice

Before, the routing question had a single axis. Now it has two. The comparison below summarizes the shift for teams running agents on the CRM, with cost per task in place of price per token as the decision unit.

The operational consequence is that the routing policy becomes per task, not per model. A lead qualification task that only reads structured fields and returns a score supports a generalist without ceremony. A task that reads conversation history, objections, and contract terms to recommend an action deserves the domain model, because that is where proprietary context and the data boundary weigh the most. The expensive error is applying the same route to everything, which is what most teams still do by default.

There is a second, less obvious effect. Trust boundary stops being a security-only topic and enters the spreadsheet. If half the CRM volume resolves inside the boundary, half stops paying the tariff of an external generalist per interaction, and the cost-per-task calculation flips sign. The cost per task decides the route lays out that account; what Koa adds is the column "where the data travels" and which model provider stays on the path, which can invert the result even when price per token favors the generalist.

For those who already moved prices in production, this is the same class of event covered in the guide on what to do when the token price changes: a change that reclassifies routing candidates and forces a rethink of defaults. The difference is that now the reclassification does not come only from price, it comes from the model's origin and weight control.

What to do now

1. Map CRM tasks by data sensitivity before choosing a model. List every step in the flow and mark which ones touch customer data, contract terms, or conversation history. The map defines what can leave the trust boundary.
2. Measure cost per resolved task, not price per token. Include rework, human escalation, and the extra retrieval call a generalist requires to rebuild context a domain model already carries. The decision unit is the task that finishes, not the token that enters.
3. Treat the CRM Bench as vendor-reported until independent evaluation exists. When Salesforce publishes external evaluation numbers, redo the math. Until then, 3x fewer errors is a starting point, not a verdict.
4. Design the routing policy per task, with a domain model as one of the candidates. The decision is between a frontier generalist, a domain model, and generic open models, and the allocation changes by task, not by vendor preference.
5. Put cost governance above model choice. Routing without a cap per key, per agent, or per project returns the savings to the vendor at the turn of the month. That is what sustains the decision when volume grows.

The Nexforce Router operates exactly at that point: one API for 500+ models, with a routing policy configurable per key and a spend cap per agent or project. The question Koa makes unavoidable, how much of the volume stays inside the boundary and how much leaves, is the same one any routing policy has to answer. Whoever decides the route with real traffic evidence answers with data instead of intuition.

Frequently asked questions about Salesforce Koa

Is Koa available today? Not yet in GA. Salesforce expects general availability for US regions in winter 2026, with open beta following. The date is a company statement, not a settled fact, and there was no confirmation of price or packaging at the time of publication.

What is the CRM Bench and why does it warrant caution? It is Salesforce's own CRM benchmark, used as the basis of the announcement's metrics. Because the benchmark and the model share the same owner, the numbers are vendor-reported. Without external evaluation, the 3x fewer errors and the +11% accuracy should be read as a vendor result.

Does Koa use customer data in training? According to Salesforce, no. The corpus is entirely synthetic, with no customer data, derived from 27 years of CRM workflows across more than 14 industries. The company states that no customer data crosses the boundary during training or inference: Koa only sees what the customer chooses to share, and that runtime exposure sits in the serving harness and the elected grounding data, inside Salesforce infrastructure.

Does Koa replace a frontier generalist? Not by default. It adds itself as a third type of routing candidate, next to frontier generalists and generic open models. The choice is per task: sensitive tasks tend toward the domain model, which runs on Salesforce's boundary and does away with a third-party model provider, while open tasks go to the generalist.

What does this change for companies that do not use Agentforce? The mechanism, not the product. Any company that routes agents over customer data faces the same boundary question: how much of the volume can leave the trust boundary. Koa is evidence that a platform vendor found it worthwhile to control weights and hosting to answer it.

References and Further Reading

• Salesforce, official Koa announcement page: https://www.salesforce.com/agentforce/koa (week of 2026-09-14; rechecked on 2026-09-22). Primary source of every number in this analysis. The CRM Bench values are vendor-reported.
• Salesforce AI Research, CRM Bench: https://www.salesforceairesearch.com/crm-benchmark (proprietary benchmark, always labeled as vendor-reported; at the time of this publication the address did not respond to checks, and the data was kept per the briefing, with the caveat applied in the body).

Where this points

Koa is still an announcement, with GA expected in winter 2026 and pilots without published results. The signal, however, is already clear: routing becomes a data-boundary decision, not only a price-per-token one. The next data point that reorders that account is the independent evaluation of the CRM Bench, and whoever runs agents on the CRM should track it. Nexforce's position on cost per task is in cost per task decides the route, and the practical routing layer is in the Nexforce Router.