Salesforce announced Koa on September 15, 2026, a CRM reasoning model for Agentforce built by adapting NVIDIA Nemotron. The official announcement positions it around business workflows and tool use. This gives the agentic era a concrete enterprise example: a software vendor is taking responsibility for the model beneath its agents.
At the same time, Salesforce is making its workflows available through Claude. Those choices can reinforce each other. Owning a specialized model gives a vendor one way to improve its product; integrating with an outside assistant gives customers another way to use it. For enterprise buyers, the useful question is which layer deserves investment: model adaptation, workflow design, data access, or the interface employees already use.
What should buyers know about Salesforce Koa?
| Question | Answer |
|---|---|
| What work is it aimed at? | CRM workflows requiring agents to choose tools and carry out multiple steps. |
| Is Salesforce training a foundation model from scratch? | No; Koa specializes an existing Nemotron model. |
| Is this simply NVIDIA hosting a chatbot? | No; the collaboration includes model adaptation and Salesforce-controlled serving. |
| Does a specialized model settle procurement? | No; your workflow results and operating requirements still decide. |
| Is the Claude integration contradictory? | No; it addresses how users reach Salesforce workflows. |
| What should a buyer do next? | Define one workflow, its permitted actions, and its failure criteria before comparing options. |
How does Koa use Nemotron, and is it distillation?
The research paper identifies the base as Nemotron-3-Super-120B. It describes reinforcement learning with Group Relative Policy Optimization, using workflow specifications to construct simulated tasks and rewards. The model learns from public and synthetic data; the authors say they used no customer data.
NVIDIA's Dreamforce account names NeMo RL, NeMo Gym, and NeMo AutoModel among the training tools. This is a collaboration spanning a pretrained model, adaptation software, and domain expertise. Calling it merely an infrastructure deal would miss the model work.
There is a documentation distinction worth preserving: Salesforce's release mentions supervised fine-tuning and reinforcement learning, while the paper says its final model uses RL directly from the base and reports SFT separately. Post-training is the supported description; describing Koa simply as a distilled model would obscure that distinction.
Our Nemotron 3.5 Lightning coverage covers a different member of the family. Its deployment requirements and results should not be transplanted into a Koa evaluation. A shared family name is not a specification sheet.
For a product team, the broader distinction is practical. Integrating a model means configuring how a product calls it. Adapting a model means taking responsibility for changes to its learned behavior. Either route still needs usable tools, current records, and a way to tell whether the requested work actually happened.
What do Koa's published benchmarks establish?
Table 1 of the paper reports these vendor-run results. CRM Bench values are weighted scores; BFCL values are percentage accuracy.
| Model | CRM Bench | BFCL |
|---|---|---|
| Nemotron 3 Super 120B | 0.84 | 64.73 |
| Salesforce Koa | 0.86 | 66.63 |
| Claude Opus 4.8 | 0.87 | 78.18 |
| GPT-5.5 | 0.90 | 67.63 |
Koa improves over its base here, but does not lead these comparisons. Salesforce's release also claims “three times fewer errors”; that headline should not be treated as a universal error reduction across these scores or customer deployments. Sources: paper, Table 1, and Salesforce's launch claim.
For buyers, a comparative score is useful evidence for shortlisting. It is insufficient evidence for authorizing an agent to modify business records. An average can combine successful routine work with failures concentrated in exactly the cases that matter to your company.
Consider two hypothetical agents evaluating renewal requests. One produces slightly better summaries but occasionally chooses the wrong account. The other writes less polished prose and reliably stops when account identity is ambiguous. A single aggregate quality score could obscure the operational difference. Your evaluation must make the account-selection failure visible on its own.
That is why our enterprise AI benchmark guide starts with a definition of success for the buyer's workflow. Evaluate final record state, tool arguments, unnecessary actions, and human corrections alongside answer quality. A fluent explanation of an incorrect update is still an incorrect update.
Where does Koa fit beside Agentforce and Einstein?
Salesforce's Agentforce glossary distinguishes embedded Einstein features from the Atlas reasoning engine, which guides agent actions and responses. Koa adds a model choice within this wider system. It is not a new name for every Salesforce AI feature.
The Koa product page describes selection at organization, agent, and subagent levels, and grounding through records and instructions customers provide. It also describes Salesforce controlling the weights and running the model within its infrastructure.
The implication is that model choice and workflow configuration remain separate responsibilities. Buying a model with CRM specialization does not tell it which of your opportunities is current, whether an exception has been approved, or which service team owns a disputed case. Those facts must enter through the surrounding application.
An enterprise pilot should therefore have owners for both layers. The domain owner defines valid outcomes and escalation rules. The implementation owner verifies that tool access, record retrieval, and permissions match those rules. Model evaluation becomes useful when both can inspect the same trace and explain why an action was allowed.
Why build Koa while adding 37 Salesforce skills to Claude?
Anthropic's September 15 announcement describes a beta plugin with 37 skills, including account research, call preparation, pipeline review, and CRM updates. It brings Salesforce context into Claude under existing Salesforce permissions, with seller approval before updates. The partnership was already announced in Salesforce's August 26 Claudeforce release; the September news concerns the beta release.
Our Salesforce in Claude coverage provides the companion story. Read together, the announcements suggest that Salesforce wants to participate at several layers of enterprise AI. That is an interpretation of the product choices, rather than evidence of an exclusive model strategy.
Agent skills package repeatable instructions and workflows. A specialized model changes the reasoning component those workflows may rely on. An integration determines where the user starts the work and which systems the assistant can reach. These are distinct investments, with different owners and maintenance costs.
For example, a seller might prefer preparing a meeting inside an assistant that already contains their working context. A service operation might prefer running a tightly configured agent within its existing application. An enterprise can support both preferences without making every workflow depend on one model or one user interface.
What does this signal for vertical AI?
Koa suggests that application vendors can compete through workflow specialization while continuing to use foundation models developed elsewhere. In this context, vertical AI means intelligence adapted to a business function or industry's work. CRM spans industries, so the specialization is partly functional rather than confined to one sector.
The valuable asset may be a clear description of work: which information is required, which actions are valid, how exceptions are handled, and what completion looks like. A company that has documented those details has something useful to contribute before it funds any training.
This changes how a buyer should judge claims of proprietary intelligence. Ask the vendor to demonstrate a difficult workflow with ambiguous inputs, a failed tool call, and a request outside the operator's permissions. The answer should show what the system does when its preferred path is unavailable. An impressive happy-path demo establishes much less.
There is also a distinction between vendor control and customer control. Salesforce owning a model's weights does not automatically give customers those weights or let them run the model elsewhere. The launch offers a Salesforce-hosted option and does not announce a public Koa download. Buyers interested in portability need to evaluate the actual delivery arrangement, not infer it from Nemotron's open-weight foundation.
Our assessment is that Koa strengthens the case for owning workflow knowledge and evaluations. Whether a particular enterprise should also own model adaptation depends on evidence it has yet to collect.
How should enterprises decide what to build versus buy?

Start by separating three decisions that are often compressed into one budget request.
| Decision | What you would own | What to measure before committing |
|---|---|---|
| Buy a packaged agent | Configuration, rollout, and operating policy | Workflow fit, review burden, and recovery from failures |
| Build workflows around an existing model | Tool contracts, retrieval, instructions, and evaluation | Whether these changes fix the observed failures |
| Adapt and serve a model | Training process, checkpoints, serving, and regression monitoring | Whether adaptation adds enough value to justify maintaining it |
This extends the decision framework in our enterprise AI build-versus-buy guide. The strongest reason to customize a model is a repeated, measurable failure that persists after the surrounding workflow has been improved.
If an agent cannot retrieve a customer's current entitlement, model training is an indirect response to a retrieval problem. If a tool accepts ambiguous account names, tighten the tool contract. If the model repeatedly selects the wrong next action despite correct context and clear tools, adaptation becomes a more plausible experiment.
Cost should follow the same discipline. Record the effort to configure the workflow, maintain integrations, review outputs, investigate incidents, and re-evaluate model updates. For a self-served option, include operating capacity and the people responsible when serving fails. A low inference bill can coexist with a costly service operation.
These are proposed evaluation criteria, not claimed savings from Koa. The launch materials reviewed here do not provide a public Koa price schedule from which to calculate a reliable customer return.
What should a first pilot actually test?
Choose a bounded task, such as preparing a renewal review and proposing record changes. Define success before comparing models. The evaluator should know which account is intended, which fields are allowed to change, and which uncertainty requires a question.
Use this prompt as a starting point in an approved test environment with fictional records. It is an evaluation template, not a claim of tested Koa behavior:
Review the supplied renewal records and propose the next action.
Identify the account and cite the source record for each factual claim.
If the account, entitlement, or approval state is ambiguous, ask for clarification.
List proposed CRM field changes separately from the explanation.
Do not perform writes in this evaluation.
If a tool fails, report what remains unknown and what you would do next.
Repeat the task with a missing field, conflicting records, and an unavailable tool. Add a scenario where the user requests a change outside their assigned scope. Score the proposed action and the decision to stop separately from the quality of the written response.
A useful pilot report includes the initial request, retrieved evidence, proposed tool calls, final outcome, review time, and failure category. Preserve failed examples so the next configuration can be compared against the same problems. When comparing models directly, keep the tools and task conditions consistent; when comparing complete products, report their configuration differences.
Finally, distinguish a simulation result from readiness for live writes. A model can succeed in a fictional environment while the production integration still has different permissions, timeout behavior, or record ambiguity. Expand scope when the evidence supports the next step.
When can customers use Koa?
Salesforce's dated launch release says select Agentforce customers have pilot access, with U.S. general availability expected in winter 2026. Its product page also contains broader availability wording. For planning as of September 16, the explicit pilot and expected-GA statement is the more conservative reading; confirm eligibility for your organization before scheduling deployment. Salesforce availability statement.
Salesforce Koa makes the enterprise reasoning debate more concrete. An application vendor can specialize an existing foundation while keeping outside assistants in its product strategy. The useful response for buyers is to own the definition of successful work, then test which combination of model, workflow, and interface delivers it.
Related reading
- Salesforce in Claude and its 37 sales skills — the complementary integration strategy.
- NVIDIA Nemotron 3.5 Lightning — separate coverage of the Nemotron model family.
- The agentic era, 2026–2030 — how actions change the role of AI applications.
- Building an enterprise AI benchmark — defining success for your own workflows.
- Enterprise AI build versus buy — deciding where customization earns its cost.
- What are agent skills? — understanding reusable workflow instructions.
Official references: Koa announcement, Koa research paper, and Agentforce concepts.
Details reflect sources checked on September 16, 2026. Benchmarks are vendor-reported; pilot access, availability, pricing, and product documentation may change.
