01 Facts & context
The facts: a domain model, a hosted option and outcomes still to test
On 15 September 2026, Salesforce and NVIDIA announced Koa, a CRM reasoning model for Agentforce, built through post-training on Nemotron. Salesforce describes synthetic business scenarios without customer data in training. Salesforce controls the weights and runs inference within its infrastructure and trust boundary. The named controller is the software supplier. Adopting its hosted option does not automatically transfer weight ownership to an enterprise customer, and inference should not be described as avoiding customer business data altogether.
Salesforce’s announcement states that Koa is available to selected pilot customers, with general availability expected in U.S. regions in winter 2026. The October milestone in the same announcement concerns post-trained Missionforce models. NVIDIA’s blog uses broader wording about both data and pilot timing. This article follows the product owner’s more specific availability statement, separating current pilots from planned general availability.
The companies report improved CRM performance. The authors’ preprint gives a clearer comparative boundary: improvement over the base model and superiority to one strong proprietary baseline, while remaining below the strongest frontier models. Neither publication independently measures customer production outcomes. GSP therefore examines how a software supplier uses workflow knowledge in training and how buyers should test task suitability, data processing and execution permissions. The evidence supports investigating a candidate capability; it does not establish comprehensive victory for specialist models or eliminate the work required to adopt one.
02 GSP analysis
Comparison one: reconcile training, inference and availability claims
NVIDIA and Salesforce describe the same launch, but two points require close comparison. NVIDIA’s blog extends its customer-data wording to both training and inference. Salesforce’s product announcement makes a more specific distinction: customer data was not used for training, while customer data does not cross Salesforce’s trust boundary during inference. The latter does not mean that inference avoids business data. It cannot justify omitting checks on customer records, tool calls or retained logs. GSP uses the product owner’s specific boundary and retains both sources for comparison.
Timing also needs to be separated by product. Salesforce’s availability section states that Koa is already offered to selected pilot customers, with U.S. general availability expected in winter 2026. October concerns post-trained NVIDIA models for Missionforce. Sharing an announcement does not make the products’ regions, hosting arrangements or pilot conditions identical. Procurement should confirm the particular service available to the buyer instead of treating a launch headline as evidence of complete availability.
A useful checklist has three separate rows: training-data provenance, inference data flow, and currently purchasable regions and stages. Attach product documentation and unanswered questions to each. Identifying what remains undisclosed helps establish a workable adoption plan more than treating supplier-owned infrastructure as proof that every customer control requirement has already been satisfied.
03 GSP analysis
Comparison two: turn workflow specifications into trainable and testable tasks
Salesforce’s announcement emphasises synthetic scenarios and CRM actions. The research preprint describes expanding workflow specifications into multi-turn tasks and grounding rewards in successful tool use. This makes the task process a training target, rather than asking only for plausible answers. The paper also identifies multi-turn tool use as a particularly clear area of improvement over the base model, while reporting performance below the strongest frontier models. A comparative error claim from a marketing benchmark cannot therefore be read as one result covering every task, model and customer environment.
The more useful procurement question is whether the buyer’s rules can become executable acceptance conditions. Updating an opportunity, for example, involves more than changing a stage. The task needs object identification, allowed fields, prerequisites, duplicate-request handling and confirmation of the resulting state. An ambiguous business rule can yield consistent execution of the wrong task. Scoring only the final explanation can also miss a tool that never successfully wrote the change.
GSP proposes documenting a few common actions and retaining normal, incomplete-information, insufficient-permission and tool-failure cases. Check model recommendations separately from actual execution outcomes. The training method provides ideas for evaluation design without requiring customers to build their own model. Acceptance should establish whether their process completes correctly and returns exceptions to an owner. Supplier ownership of weights cannot substitute for that task evidence.
What each source establishes
Observations and limits in public material
| Source | Documented observation | Interpretive boundary |
|---|---|---|
| NVIDIA | NVIDIA describes Nemotron post-training, supplier infrastructure and CRM-action performance. | This is a partner announcement; compare its inference-data and pilot-date wording with the product owner’s more precise statement. |
| Salesforce | Salesforce states no customer training data, inference within its trust boundary and current selected-customer pilots. | U.S. general availability is expected in winter; the October milestone concerns post-trained Missionforce models. |
| Zixiang Chen et al. / Salesforce research | The authors’ preprint reports multi-turn tool-use gains and superiority to one strong proprietary baseline, while remaining below the strongest frontier models. | Author evaluations concern specified tasks and comparisons, not universal leadership or customer production outcomes. |
Partner announcements, product availability and author-run evaluations provide different levels of evidence.
- [1] Jensen Huang at Dreamforce: Salesforce and NVIDIA ↗September 15, 2026; Koa model ownership; post-training; availability · Accessed
- [2] Announcing Koa: Salesforce’s First CRM Reasoning Model, Built on NVIDIA Nemotron ↗September 15, 2026; What makes Koa different; Availability · Accessed
- [3] Salesforce Koa: An Enterprise Language Model for Agentic Tool Use ↗Abstract; version 1 submitted September 14, 2026 · Accessed
04 GSP analysis
Strategic choice: supplier customisation still requires customer acceptance
Post-training lets an enterprise software supplier target particular workflows and forms of tool use. That is the choice illustrated by Koa. It does not establish that general-purpose models necessarily misunderstand CRM or that every customer will pay less. Domain performance depends on a combination of the model, tool descriptions, context and process configuration. A specialist label alone cannot identify which component produces an improvement.
The customer is buying a Salesforce-hosted model option for Agentforce, rather than commissioning and owning a model of its own. The supplier manages updates and the runtime environment. The customer still needs to confirm the scope of records read, actions tools can execute and notification of version changes. GSP proposes three separate maps: who maintains the model, which components process business data, and which identities can approve particular actions. These maps relate to each other but do not substitute for one another.
Suppose a manufacturer uses an agent to check discount conditions before a quotation. Inspect which records it can read, whether it can remain advisory, which changes require approval and how missing conditions return to a person. Hosting within supplier infrastructure is one input to that assessment; it does not automatically secure acceptance or establish a reduction of several weeks. The adoption decision should rest on replayable customer tasks, understandable error categories and explicit maintenance responsibility. Verify the practical value of supplier control through delivery rather than inferring it from positioning at launch.
05 GSP analysis
Value distribution: an open base is not customer portability
An open-weight foundation supports Salesforce’s ability to post-train and manage a runtime. The openness of that foundation and the customer’s rights in the resulting product are different questions. Koa’s announcement does not promise every customer possession of customised weights or unrestricted movement outside the hosted environment. Model choice, data export and replacement should be checked against the actual product and agreement. More technical control for a supplier cannot simply be rewritten as more asset ownership for its customers.
The operating mechanism worth examining is the combination of workflow knowledge, task examples and tools into application differentiation. The public material does not establish how that choice changes either company’s revenue mix. Domain training may reduce certain errors, but the magnitude, tasks and transfer into a customer environment retain their comparison conditions. An aggregate score does not automatically authorise more field changes or larger transactions.
Customers can break portability into inspectable outputs: business rules, tool definitions, prompts, task examples, execution logs and evaluation results. Even when the model cannot be handed over, those materials can support comparison with alternatives. Conversely, possession of weights without clear processes does not make replacement straightforward. GSP proposes separating model-lifecycle responsibility from business-configuration responsibility. Check supplier updates as well as who maintains internal policies and permissions. Control becomes commercially meaningful through work that can be completed and exceptions that can be handled, rather than ownership language considered in isolation.
06 GSP analysis
The user journey: recommendation, confirmation and execution in collaboration tools
Salesforce says Koa already supports an internal Slack employee agent. This establishes an internal use case, but public information does not demonstrate that the entry point necessarily improves adoption or total productivity. The design lesson is to expose the stages between a conversational request and a business-system action: identify the request, obtain context, propose or confirm an action, execute the tool, inspect the result and tell the user what happened. Natural language does not remove those stages.
Suppose a service team requests case assignment in a collaboration channel. The agent first needs the correct customer and case, then the requester’s access scope and the assignment rule. Missing information should prompt clarification or handoff rather than a guess made to maximise completion. Begin with recommendations and record differences from human choices before enabling specific writes. Reversible, bounded actions can provide a starting point, but a label such as field completion does not establish limited consequences. Examine the actual field and its downstream effects.
Feedback should distinguish a prepared recommendation, a submitted operation and a confirmed target state. Tool timeouts and repeated requests require explicit handling; fluent text should not conceal incomplete execution. Training should cover checking action evidence, correcting target objects and escalating exceptions. Login frequency and chat volume describe use without proving completion. Accept the task against tool results, human intervention and later correction as well as the initial response. This keeps interaction quality connected to what the business system actually did.
07 GSP analysis
Responsibility: connect supplier commitments to an internal action owner
Procurement should confirm regions, version notifications, data processing, support and export arrangements for the selected service. Announcement-level capabilities do not replace the specific terms of purchase. Customers should not assume version pinning or recovery features exist. GSP proposes listing unspecified items and connecting them to pilot tasks, so a purchasing discussion about model capability does not postpone discovery that a business process has no owner.
Business staff can define permitted actions and exceptions; technical staff maintain interfaces, identities and logs; data owners confirm inputs and retention; procurement and relevant specialists check service commitments; finance observes complete task costs. A small organisation need not create a department for every function, but it should identify who accepts results, changes rules and handles exceptions. Centralised or distributed decisions have no universally superior form. The practical requirement is that departmental boundaries do not leave important questions unowned.
For example, a service team may want automatic request assignment. Its business owner defines routing, a technical owner tests permission configuration, and support staff specify treatment of failed assignments. A simulated mistake can then check whether logging, notification and correction connect. Set response expectations according to the actual process rather than inventing one two-hour requirement for every organisation. The supplier is responsible within its commitments and the enterprise for its configuration and use decisions. Convert those distinctions into executable handoffs instead of placing all behavioural responsibility abstractly on either party.
08 GSP analysis
Investment and alternatives: adopting a model option is not building a model
Distinguish Salesforce’s investment in a specialist model from a customer’s investment in adopting the hosted option. Customers may not operate training infrastructure, but integration, evaluation, rule preparation, review and maintenance remain work. Without comparable pricing and usage information, it is impossible to conclude that the specialist option is necessarily cheaper or more expensive than a general-purpose interface. Scale, request composition, latency requirements and human involvement affect complete task costs.
Compare the hosted domain model, an existing general-purpose model with clear tool rules, and deterministic automation where the process is fixed. The latter will not cover every open-ended request, but some well-defined state updates may not need model reasoning at every step. Weak performance can also arise from incorrect tool descriptions, missing data or conflicting policies. Do not attribute every difference to model families. Supplier announcements also serve a communication purpose, and company benchmarks need checking in the buyer’s workflow.
GSP proposes one task set and the same allowed permissions across candidates, recording success, error categories, retries, human time and fees. A faster response that creates more downstream corrections should not be judged on its first answer alone. If advantages occur only on a few complex actions, choose the specialist model for those actions without replacing the entire system. Purchase should follow demonstrable improvement in the customer’s process and an ability to maintain it. Supplier ownership by itself is insufficient justification.
09 Suggested actions
Implementation: move from action specifications to bounded execution
Start with an action inventory. For each action, document inputs, target objects, allowed fields, prerequisites, completion state and an exception owner. Choose a pilot based on reversibility, data scope and consequences of error. Summarisation, field completion and knowledge retrieval cannot be assigned one consequence level merely from their names. Different field changes can trigger very different downstream processes. Work at the level of the actual action rather than comparing parameters or general promotional capabilities.
Next, run shadow evaluations through record replay or an isolated environment, allowing candidates to process the same cases without directly changing live business state. Include normal flows, missing information, insufficient permissions and tool failures, while recording processing boundaries. Then enable execution for one defined action with confirmation conditions, timeout handling, duplicate-request protection and outcome checks. Confirm the selected service’s version and recovery capabilities beforehand. Proposed controls should not be described as features that the product already provides.
Expand according to results and make task examples, log checks and rule updates ordinary operations. Define conditions for proceeding, adjusting and stopping at each stage. Passing means progress within the tested scope, rather than approval for every future use. New objects or tools require renewed assessment instead of inheriting all previous permissions. This is GSP’s proposed implementation sequence, not a report of outcomes already achieved by Koa customers. Keeping a manual process or choosing simpler automation may also be a reasonable conclusion when the trial provides that evidence.
10 Suggested actions
Metrics and experiments: measure task correctness and permission correctness separately
Task quality includes correct target objects, accurate fields, process completion, human handoffs and exception escalation. Permission quality examines whether an action was authorised, data scope matched configuration and records can be reviewed. The two are related but should not collapse into one measure. A model may fulfil a request outside the requester’s authority, or honour all permissions while lacking enough information to finish. A single success rate can conceal those different outcomes.
Then examine processing time, user experience and complete cost, including inference, retries, human review, evaluation maintenance and training. Demand, team experience and process changes also influence business results. Do not attribute all sales growth or faster case resolution to a model. Stratify experiments by task type, complexity and consequences of error; compare the same inputs and available tools, and retain model versions and configuration. Where real customer actions are involved, begin with replay or a controlled process before selecting an appropriate comparison design.
Agree stop conditions before the pilot, covering quality and cost as well as untraceable execution and policy mismatch. When one task category deteriorates, restrict that category and distinguish model, knowledge, tool and permission causes before correction and retesting. Recovery may mean human handling or a known process. Do not promise model-version rollback without checking availability. The purpose of measurement is to find a sustainable scope of completed work and identify exceptions that still need a person.
From judgment to testable action
GSP’s proposed sequence for this situation
- 01
Map three forms of control
Identify responsibility for weights, business-data processing and tool-action authorisation separately. The customer can distinguish supplier controls from settings it must manage itself.
- 02
Replay the customer’s tasks
Compare candidates against actual rules using anonymised or synthetic cases, retaining error categories. Evaluation identifies specific advantages and exceptions still requiring human handling.
- 03
Enable execution by action
Validate recommendations first, then enable defined writes with logs and a recovery plan. Exceptions can be traced to versions, calls and final disposition.
Define actions and data flows, test task outcomes, then configure execution scope for each action.
- [1] Jensen Huang at Dreamforce: Salesforce and NVIDIA ↗September 15, 2026; Koa model ownership; post-training; availability · Accessed
- [2] Announcing Koa: Salesforce’s First CRM Reasoning Model, Built on NVIDIA Nemotron ↗September 15, 2026; What makes Koa different; Availability · Accessed
- [3] Salesforce Koa: An Enterprise Language Model for Agentic Tool Use ↗Abstract; version 1 submitted September 14, 2026 · Accessed
11 Suggested actions
Conditions for adoption: select by task rather than ownership narrative
Suitability of Koa as a hosted domain option depends on the enterprise’s Agentforce processes, available regions, task characteristics, data-processing requirements and implementation capacity. Adoption does not turn the customer into a model-building organisation or require it to own a training team first. Likewise, a large CRM database does not automatically justify a domain model. Establish usable data, clear rules and an observed limitation in the current method before selecting a remedy.
Decisions can vary by task over time. If a general-purpose model or deterministic process reaches the same quality at a more suitable cost for one action, compare again. If a specialist model performs better on multi-turn tool tasks, retain it within that scope. Reaccept tasks after policy, tool or model changes to avoid relying on stale scores. Preserved examples, rules and evaluation records support replacement comparisons, while model export, multi-model routing and version pinning must be confirmed against actual service capabilities.
The ultimate question is not whether the business owns a model. It is who can demonstrate completion under its data and permission conditions, and who takes over when exceptions occur. Salesforce’s weight control can contribute to its product design; the customer’s operating control still comes from explicit configuration, inspectable execution and continuing maintenance. If those foundations are missing, process definition, better tool descriptions and user training may contribute more than immediately adding a model option. A launch introduces a candidate capability. Task evidence should determine adoption.
THE EVIDENCE
Grounding the argument in evidence.
What the source reports
NVIDIA describes Nemotron post-training, supplier infrastructure and CRM-action performance.
This is a partner announcement; compare its inference-data and pilot-date wording with the product owner’s more precise statement.
What the source reports
Salesforce states no customer training data, inference within its trust boundary and current selected-customer pilots.
U.S. general availability is expected in winter; the October milestone concerns post-trained Missionforce models.
What the source reports
The authors’ preprint reports multi-turn tool-use gains and superiority to one strong proprietary baseline, while remaining below the strongest frontier models.
Author evaluations concern specified tasks and comparisons, not universal leadership or customer production outcomes.
DECISION POINTS
From understanding to testable action.
Map three forms of control
Identify responsibility for weights, business-data processing and tool-action authorisation separately.
The customer can distinguish supplier controls from settings it must manage itself.
Replay the customer’s tasks
Compare candidates against actual rules using anonymised or synthetic cases, retaining error categories.
Evaluation identifies specific advantages and exceptions still requiring human handling.
Enable execution by action
Validate recommendations first, then enable defined writes with logs and a recovery plan.
Exceptions can be traced to versions, calls and final disposition.
QUESTIONS TO EXPLORE
What still needs to be established?
- Do published evaluation gains transfer to the customer’s object model, tools and permissions?
- Who reaccepts tasks when a model version or business policy changes, and which exportable records support replacement?
Research sources
Synthesized from original reporting, institutional materials and research. Source observations, GSP interpretation and proposed actions are identified separately.
- Jensen Huang at Dreamforce: Salesforce and NVIDIA ↗NVIDIA · September 15, 2026; Koa model ownership; post-training; availabilityAccessed
- Announcing Koa: Salesforce’s First CRM Reasoning Model, Built on NVIDIA Nemotron ↗SalesforceSeptember 15, 2026; What makes Koa different; AvailabilityAccessed
- Salesforce Koa: An Enterprise Language Model for Agentic Tool Use ↗Zixiang Chen et al. / Salesforce researchAbstract; version 1 submitted September 14, 2026Accessed
Prepared from the cited public sources with AI-assisted research. Reported facts and editorial interpretation are presented separately.
CONTINUE THE RESEARCH
Explore your question further.
Request the full research report and discuss your market, brand questions and business context with GSP.
Request the full research report ↗