Salesforce’s Koa Moves the Model Contest Into the CRM Workflow
Koa brings domain post-training to Agentforce, making workflow execution and governed model routing the tests that matter.
Updating an opportunity, routing a service case, and scheduling a follow-up are the tasks Salesforce names in its benchmark for Koa, the CRM reasoning model it announced with NVIDIA on September 15. These actions make the release consequential: a model must choose a useful next step and invoke the appropriate business tool, with consequences beyond the wording of an answer. Salesforce says Koa was built by post-training NVIDIA Nemotron 3 Super on synthetic enterprise scenarios. It is available to select Agentforce pilot customers, with general availability expected in U.S. regions in winter 2026, according to the announcement.
Koa moves the model contest into that workflow because Salesforce is attempting to make knowledge of business processes part of the reasoning model itself. Its significance lies in a possible change in how enterprise reasoning is supplied and selected: a specialized model controlled by the application vendor can compete for requests that previously went to general-purpose providers. That is a strategic interpretation, not an established cost advantage. The release materials do not provide an independently reproduced evaluation or enough comparable methodology to establish one. What they do describe is a concrete combination of domain post-training, Salesforce-hosted inference, and an additional model option inside Agentforce.
The training target is a sequence of business actions
Salesforce’s account of Koa’s construction is more specific than the familiar promise that an enterprise model understands business. The company says it generated scenarios covering more than 14 industries, including manufacturing, financial services, healthcare, and travel. Each scenario paired a persona with tasks and mapped the actions and tool calls needed to complete them. The intended teaching material therefore represents a process: a customer situation, an objective, and a sequence of interventions. Salesforce identifies lead generation, opportunity qualification, and service-case resolution among the activities represented in the synthetic corpus.
That design gives the specialization claim a practical meaning. As an illustration, a service agent facing a disputed booking might need to find the relevant account, inspect the booking, establish which policy applies, and then decide whether it can make a change or must escalate. A training example that maps the action sequence can teach a model something different from an example containing only a polished customer-facing answer. Salesforce’s announced objective is precisely this distinction: it says the scenarios train reasoning, tool use, and decision-making, rather than relying on generic content. The announcement does not establish how completely those scenarios cover the variations in any particular customer’s workflow.
The company names supervised fine-tuning and reinforcement learning with Group Relative Policy Optimization as its post-training methods, using NVIDIA NeMo RL, NeMo Gym, and NeMo AutoModel. Those details locate the intervention after the foundation model has already been built. Koa is an adaptation of Nemotron 3 Super, with Salesforce concentrating training on prioritized enterprise tasks. The disclosure does not specify the reward design, scenario distribution, or treatment of unsuccessful tool sequences. Those missing details limit how far an outside reader can reconstruct why the model would prefer one action path over another, even though the training approach is identified.
The base model matters because it supplies the capabilities that this specialization attempts to shape. NVIDIA describes Nemotron as an open model family and positions its Super models for reasoning and tool calling in complex agent systems. It also says it publishes model weights, training datasets, and techniques. Those are NVIDIA’s descriptions of the foundation and its openness, not an independent assessment of Koa. In particular, the breadth of the Nemotron family should not be read as a list of capabilities verified in Salesforce’s derivative.
Salesforce’s control over the derivative is also distinct from customer access to it. The announcement says Salesforce controls Koa’s weights and runs inference within its infrastructure. The product page presents Koa as a managed model selectable through Salesforce configuration surfaces. Neither page announces downloadable Koa weights or a generally available customer-operated Koa deployment. An open foundation can enable a vendor to build and host a specialized service without making that service an openly distributed model. That distinction follows directly from the release description and the managed-model offering.
Synthetic training leaves runtime data questions intact
The most important evidence boundary concerns what Salesforce means when it says no customer data was used to train Koa. Its release describes a proprietary synthetic corpus modeled on enterprise knowledge accumulated through CRM deployments. That supports an attributed statement about the data used for Salesforce’s specialization work. It does not, by itself, provide a complete account of the foundation model’s pretraining history or prove that a deployed agent cannot expose information. The announcement discusses the synthetic scenarios and Salesforce’s hosting boundary, while the product page separately explains how Koa receives customer context during use.
These are separate layers with separate questions. Base-model provenance concerns the materials and processes behind Nemotron. Post-training concerns the scenarios Salesforce used to shape CRM behavior. Runtime grounding concerns the records, instructions, and other context supplied for a particular request. NVIDIA’s Nemotron page describes its transparency practices; Salesforce’s Koa announcement identifies its synthetic post-training approach; Salesforce’s product FAQ says the managed model draws on grounding data, records, and instructions customers make available. Combining those statements into a blanket assertion that customer information never reaches the model would erase the runtime layer that makes the product useful.
TechCrunch’s September 15 report goes further, describing Koa as a model that has not ingested actual customer data and therefore cannot leak it to others. That causal claim is not established by the training account. The same report quotes Salesforce AI executive Jayesh Govindarajan describing simulated customer-service and sales environments, which supports the explanation of synthetic post-training. But a model can be given sensitive information in a live request regardless of whether that information appeared in training. The stronger privacy conclusion in TechCrunch’s coverage should therefore remain distinct from the mechanism Salesforce actually discloses.
Salesforce makes an additional hosting claim: it says post-training and inference occur within its own trust boundary, and that customer data does not cross that boundary during inference. This is a statement about where processing occurs. Whether a specific response reaches an authorized recipient is a different question involving permissions, context selection, and downstream actions. Salesforce’s broader architecture explicitly assigns identity, permissions, privacy, and runtime security to a security layer. The company’s own Enterprise AI Harness description thus supplies a reason to assess data protection at the system level rather than infer it solely from synthetic training.
The Koa product page says the model is served at temperature zero for consistency and is surrounded by a dedicated serving harness with trust and safety controls. It also claims Koa is optimized to follow instructions and remain within configured guardrails. These are useful disclosures about the intended deployment, but they are vendor assurances rather than a published security evaluation. A repeatable response can still select the wrong record or propose an inappropriate action. Our assessment is that consistency, authorization, and correctness should remain separate evaluation questions when interpreting the product’s security claims.
Domain knowledge meets the customer’s actual rules
Koa’s synthetic training is intended to teach recognizable business patterns, while Agentforce supplies the machinery through which a model encounters a particular business. Salesforce describes Agent Builder as a way to define subagents, write instructions, and create a library of available actions. Those actions can use Flows, MuleSoft APIs, and custom business logic. Its Atlas Reasoning Engine is described as breaking a request into smaller tasks and evaluating progress along the way. This is the execution environment into which the new model option fits.
That division explains both the opportunity and the limit of putting CRM knowledge into weights. A model familiar with the lifecycle of a service case may have a useful starting point for interpreting a request. It still needs the actual case, the relevant customer relationship, the current policy, and the tools enabled for that organization. Salesforce acknowledges that dependency when it says Koa draws on the grounding data and instructions made available to it. Domain post-training can shape how context is interpreted; it does not eliminate the need to supply accurate, authorized runtime context.
Consider a hypothetical renewal workflow in which a customer asks for a concession after an unresolved service problem. A specialized model might recognize that the service history matters to the commercial decision. Whether a concession is permissible, however, depends on the organization’s current rules and the agent’s authority. A convincing explanation is insufficient if the agent invokes an action outside those limits. Salesforce’s September 11 Agentforce announcement says Agent Script allows customers to combine AI reasoning with deterministic rules governing decisions and actions. That mechanism places enforceable workflow structure alongside the model’s learned behavior.
The following is a conceptual illustration of that division, not a documented Koa implementation trace. It reflects Salesforce’s descriptions of grounding, model choice, permissions, and action execution in its harness architecture.
flowchart TD
A[Business request] --> B[Authorized context and instructions]
B --> C[Model selection under policy]
C --> D[Koa or another approved model]
D --> E[Proposed action]
E --> F[Permissions and workflow controls]
F --> G[Execute or seek human input]
G --> H[Record outcome and update context]
The execution layer becomes more consequential as a task stretches across sessions. In its September 11 announcement, Salesforce described a long-horizon runtime with memory, durable execution, and dynamic steering, naming the outbound sales agent Hunter as its first user. Hunter was in pilot, with general availability planned for November 2026. These are runtime capabilities with their own release status; they should not be credited to Koa merely because both announcements discuss multistep work. Remembering progress across sessions and choosing the next tool call are connected requirements, but the published architecture assigns them different roles.
This distinction affects how a pilot should be interpreted. As analysis, a useful comparison would hold the permitted actions, grounding, and business rules steady while changing the model, then examine whether the resulting action sequences improve. Otherwise, a better outcome could reflect a revised workflow or cleaner context rather than post-training. Conversely, a failure caused by an unavailable tool should not automatically be attributed to the reasoning model. Salesforce’s descriptions of Agentforce’s configurable actions and Koa’s selectable scope make that separation relevant to evaluating the release.
Routing gives specialization an economic purpose
Salesforce is offering several levels at which administrators can select Koa. Its product page describes a managed LLM in the Data Cloud generative models catalogue, organization-wide enablement through Agentforce setup, and selection at the agent and subagent level. These controls matter because the specialization need not be adopted as a universal default. A business could evaluate it for a bounded process while retaining another approved model elsewhere. The page establishes configuration options; it does not publish a complete account of automatic fallback behavior or request-level routing rules.
TechCrunch provides additional context for the economic intent. Govindarajan told the outlet that Salesforce had previously relied on frontier providers for reasoning, despite having built smaller task-specific models. The report describes Agentforce’s AI gateway as deciding which model handles a request, and presents Koa as intended to perform relevant work with fewer tokens. NVIDIA executive Kari Ann Briski told TechCrunch that Nemotron’s inference architecture supports token efficiency. These are attributed explanations of the companies’ strategy, not measured evidence of lower customer spending from the new model.
The underlying economic proposition is conditional. If a model trained on familiar CRM sequences can reach an acceptable outcome with less unnecessary reasoning or fewer wrong actions, it could reduce some work associated with a request. But actual economics also depend on hosting, latency, retries, escalation, and commercial packaging. The published Koa pages do not disclose a comparable end-to-end cost study or a Koa-specific price schedule. Salesforce’s general Agentforce page lists Flex Credits, Resolutions, and per-user licensing, illustrating why model-level efficiency and the customer’s billing arrangement cannot simply be treated as equivalent.
Salesforce’s September 10 Enterprise AI Harness announcement makes model choice part of the platform’s stated design. Its “Trusted Models” capability describes routing based on accuracy, performance, cost, and business requirements. Its proposed AI Control Plane would provide visibility into behavior, outcomes, and cost across Salesforce and third-party AI. This provides strategic context for Koa, but the release says new capabilities and the unified experience are planned to begin rolling out in early fiscal FY28. The existing foundation and the forthcoming unified architecture must remain separate in any reading of today’s launch.
The strongest economic interpretation is therefore about allocation. Koa gives Salesforce a specialized candidate for work whose structure it can describe through CRM scenarios, while routing offers a way to assign that work without requiring a single model to cover everything. That interpretation is supported by the managed-model selection controls and the company’s broader routing plans. It remains a hypothesis about value until comparable workloads demonstrate acceptable outcomes and commercial terms translate any efficiency into a benefit for the buyer. Neither the Koa product page nor the harness announcement closes that evidentiary gap.
Claude and Gemini keep the contest inside the platform
Koa arrives against a recent expansion of Salesforce’s relationship with Anthropic. In the August 26 Claudeforce announcement, Salesforce described Salesforce in Claude, a plugin with 37 prebuilt sales skills for working with live revenue context and taking governed actions. It also said Claude was available within Agentforce, including as a reasoning model for the Atlas Reasoning Engine. This dated background matters because it shows Salesforce building a specialized reasoning option while continuing to integrate a frontier provider into the same business environment.
The two offerings address different choices. Koa is presented as a model option inside Agentforce; Salesforce in Claude brings Salesforce capabilities into Claude’s interface. Salesforce’s Claudeforce page says the plugin exposes business data, workflows, logic, and permissions through a secure Model Context Protocol connection, and that customers control its autonomy when writing updates. Its availability wording still refers to select pilots and plans for a September open beta, while the sales panel carries a beta label. Those descriptions do not establish general availability across the broader Claudeforce portfolio.
Google provides another concrete boundary against interpreting Koa as a wholesale replacement strategy. In a separate September 15 announcement, Salesforce said the Agentforce Reasoning Engine with Gemini was generally available. The same announcement distinguished a private-preview Salesforce Federated Connector for Gemini from a beta Agentforce Sales Agent for Gemini Enterprise. These different statuses show why the availability of a reasoning model should not be extended automatically to every connector, agent, or interface associated with it. They also establish that Gemini remains part of Agentforce’s model choices.
| Offering | Relevant role | Published availability boundary |
|---|---|---|
| Koa | Specialized CRM reasoning in Agentforce | Select pilots now; U.S. GA expected winter 2026 |
| Salesforce in Claude | Salesforce context and governed actions inside Claude | August announcement specified pilots and a planned September open beta |
| Agentforce Reasoning Engine with Gemini | Gemini reasoning within Agentforce | GA now |
| Enterprise AI Harness expansion | Composable controls and model-routing architecture | New capabilities and unified experience planned from early fiscal FY28 |
The strategic implication is that Salesforce can compete at the model layer while preserving the workflow layer as a common point of control. Its Anthropic materials emphasize routing actions through Salesforce business rules, while the Google announcement describes exposing Salesforce capabilities through its headless architecture. Koa adds a Salesforce-controlled reasoning option to that arrangement. As analysis, the durable commercial position being pursued is the ability to supply context and govern execution across changing models, with specialization giving Salesforce another way to serve work inside that shared platform structure.
The launch evidence stops short of proven savings
Salesforce reports favorable CRM benchmark results and publishes additional claims about action selection and conversational context on Koa’s product page. The published materials do not include the detailed methodology, named comparable baseline configurations, or independently reproduced evaluation needed to interpret those figures as established advantages. Accordingly, the numerical comparisons do not substantiate this article’s economic argument. The relevant disclosed fact is that Salesforce is evaluating Koa on actions such as opportunity updates, case routing, and follow-up scheduling, rather than providing a reproducible public account of customer-level savings.
An action benchmark could be highly relevant, but its meaning depends on what success captures. As an evaluation recommendation, a buyer should distinguish choosing the appropriate tool from supplying valid arguments, receiving a successful tool response, and leaving the business process in the intended state. A workflow could pass an early step and still fail its overall objective. Salesforce’s announcement identifies the task categories but does not provide enough scoring detail to resolve those distinctions. That limits what can be inferred from its reported CRM performance.
The customer evidence is similarly preliminary. Salesforce says Koa is already used internally, including by an agent in Slack, and is moving into pilots with organizations including 1-800Accountant, Baxter Credit Union, Engine, and UChicago Medicine. The accompanying customer statements describe why multistep reasoning could matter in accounting, financial services, travel, and healthcare administration. They do not supply independent before-and-after measurements demonstrating Koa’s effects. These are meaningful indicators of intended use and pilot participation, with a narrower evidentiary role than validated deployment results.
The pilot stage is therefore central to the story rather than a footnote. The clearest release commitment is select-customer availability now and expected U.S. general availability in winter 2026. The product page additionally mentions plans for an open beta starting “shortly after,” without a clear standalone date in that wording. It should not be converted into a firm beta schedule. The responsible reading preserves the dated announcement’s availability boundary while recognizing that the product page contains an additional, imprecisely timed plan.
A CRM model needs examples of when not to advance the case
The synthetic-training approach makes an unanswered question unusually important: how does the training reward stopping? Salesforce says its scenarios map task sequences and that reinforcement learning helps the model learn the right action. It does not disclose how it scores an unresolved request, a justified escalation, or a case where the customer's desired outcome conflicts with policy. Those are not peripheral situations for service software. A model that has learned the usual path through a case needs a way to distinguish an incomplete task from a task that should remain incomplete until someone with different authority intervenes. The training announcement identifies the method but leaves that reward-design question open.
An illustrative travel case shows the difference. A customer might request a booking change that is technically possible through an enabled tool but requires an exception to the employer's travel policy. The desirable result is not necessarily a completed booking change. It may be a clearly documented exception request, with the existing reservation preserved until an authorized decision arrives. Training examples that reward completion without preserving that distinction could teach an inappropriate preference for progress. There is no evidence here that Koa has that defect; the example explains why Salesforce's synthetic scenario design needs scrutiny beyond whether its dialogues resemble realistic customer conversations.
Agent Script's deterministic rules and the model's learned preferences address different parts of this problem. Rules can constrain the action boundary; a well-adapted model could recognize the exception earlier and avoid unnecessary tool calls or misleading assurances to the customer. A useful pilot would evaluate both the final disposition and the route taken to reach it, including appropriate escalation. That is a concrete test of CRM specialization rather than a demand that Koa win an unrelated reasoning contest. Salesforce's description of configurable rules alongside AI reasoning provides the system context for such an evaluation, without proving the outcome in advance.
Mission-specific control is a separate deployment promise
The September 15 announcement also brings NVIDIA models and accelerated computing into Missionforce, but this is a distinct deployment track. Salesforce says Missionforce Operations is generally available in U.S. regions, while post-trained NVIDIA models will be available to select customers in October 2026. The company describes support for private clouds, air-gapped networks, and specialized environments. Those statements should not be used to imply that the managed Koa pilot already includes a generally available air-gapped Koa product. The announcement separates the offerings and their dates.
The training distinction is equally important. For Koa, Salesforce emphasizes a synthetic corpus and says no customer data was used in training. For Missionforce, the same release describes mission-specific models trained on an organization’s operational data and terminology, supporting processes such as procurement, supplier management, and logistics. Those are different approaches serving different deployment requirements. A privacy description valid for the announced Koa training process should not be transferred to every NVIDIA-based model in Salesforce’s broader collaboration.
Across these tracks, Koa’s most concrete contribution is the introduction of domain post-training as another option in enterprise model selection. Salesforce has named the foundation, the training methods, the kinds of scenarios, the hosting arrangement, and the initial release boundary. It has not yet supplied the evidence needed to establish the claimed performance and economic advantages independently. The next consequential result would be a comparable demonstration that this specialization improves completed CRM workflows under the same operational constraints. Until then, the pilot announcement supports a precise shift in strategy: Salesforce is bringing its own adapted reasoning model to the place where customer context becomes an authorized business action.
Sudeep Devkota writes about AI systems, enterprise software, and the practical limits of automation.