# Salesforce Koa explained: what the new CRM reasoning model actually changes Announced at Dreamforce 2026, Koa is Salesforce’s first CRM reasoning model, trained on 27 years of CRM intelligence. Here is what it changes for an enterprise org, and the three things that decide whether it works on yours. **Published:** 2026-09-16 **Canonical:** https://synconai.com/salesforce-koa-crm-reasoning-model **Author:** SynconAI Architecture Team ## In short Koa is a CRM reasoning model Salesforce announced on 15 September 2026 at Dreamforce, built on NVIDIA Nemotron and trained on 27 years of Salesforce CRM intelligence. It is designed so agents can reason through complex multistep enterprise tasks. Whether it helps a given org still depends on that org’s data model, permission design and evaluation method. ## What the vendor announced - **Announcing Koa: Salesforce’s First CRM Reasoning Model, Built on NVIDIA Nemotron** (2026-09-15) https://www.salesforce.com/news/press-releases/2026/09/15/koa-reasoning-model/ > Koa is trained with 27 years of Salesforce CRM intelligence to enable agents to reason through the complex, multistep tasks required for enterprise ## What to take away - Koa is a reasoning model specialised for CRM work, not a general assistant. The claim is multistep enterprise tasks, not chat. - A model trained on CRM patterns still reasons over your records. If a fact has four values in four places, better reasoning reaches a confident wrong answer faster. - Nothing about a new model changes the order of work: foundations, grounding, a narrow scope with tested refusal, then evaluation against real closed cases. - Ask what it costs to run and where it runs before designing on it. Residency and retention constrain which parts of a record can leave the platform at all. ## Our read Salesforce announced **Koa** at Dreamforce 2026 on 15 September: its first CRM reasoning model, built on NVIDIA Nemotron. In Salesforce's own words, Koa "is trained with 27 years of Salesforce CRM intelligence to enable agents to reason through the complex, multistep tasks required for enterprise". That is the announcement. The rest of this page is our read on it, and it is worth separating the two clearly, because a vendor announcement and an implementation opinion are different kinds of claim. ## What is actually new here Two things, and the second matters more than the first. The first is specialisation. A general model knows what a sales pipeline is in the way an encyclopedia does. A model trained on CRM patterns knows what a stalled opportunity looks like, what usually precedes a renewal, and which fields tend to carry the answer. Where that training holds, it should need less prompting to reach the same place. The second is the word **multistep**. Most AI features shipped into CRM so far answer in one pass: summarise this case, draft this email, suggest this next step. A reasoning model is built to work a problem through in stages, which is what real enterprise work looks like: read the account, check the contract, apply the entitlement rule, then decide. That is a different class of task, and it is also a different class of risk, because a chain of steps has more places to go wrong quietly. ## The part the announcement does not decide A better model reasons over your records. It does not repair them. | What Koa changes | What it does not change | | --- | --- | | How well an agent works through a multistep task | Whether the facts it reasons over agree with each other | | How much prompting a CRM task needs | Whether permissions are enforced where the model reads | | The ceiling on what an agent can attempt | Whether anyone can tell a right answer from a plausible one | | The quality of the reasoning chain | Whether the workflow needed a model at all | The middle row is the one that tends to be discovered late. An agent reasoning across several records in one request touches more of your data model in a single call than a single-shot summary does. If access is enforced through what the interface shows rather than what the data layer permits, a reasoning chain is a more thorough way of finding that out than any penetration test. And the top-right row is the one that costs the most. Where the contract end date exists on the Account, on the Opportunity, in a renewals spreadsheet and in a document, all with different values, a stronger model does not resolve the disagreement. It picks one, states it more convincingly, and buries the problem under a fluent sentence. ## What we would do about it Nothing architectural on the strength of an announcement, and we would say the same about any vendor's. What is worth doing this quarter has almost nothing to do with Koa specifically. Pick one workflow where multistep reasoning would genuinely help, something with a real chain in it rather than a single lookup. Write down every fact that workflow depends on, and for each one name the system that owns it and the person who can change it. Where two systems claim the same fact, resolve which wins. Then take twenty cases that have already been resolved and record what a good answer looked like in each. That set is your evaluation baseline, and it is the only thing that will later tell you whether Koa, or anything else, is actually an improvement on what you have. That work is not wasted whichever model you end up on. Skip it, and no model helps. ## What multistep actually costs you A reasoning chain is not a longer answer. It is several model calls, usually with retrieval between them, and that changes three things at once. **Latency stops being invisible.** A single-shot summary lands while the user is still reading the case. A five-step chain does not. If the workflow is an agent working in the background this does not matter. If a service rep is sitting waiting for it mid-call, it matters enormously, and that decision has to be made at design time rather than discovered in UAT. **Cost stops being per-answer and becomes per-path.** Two enquiries that look identical to a user can take a two-step and a seven-step route through the same agent. Budgeting on an average is how a pilot that looked affordable becomes a platform bill nobody forecast. **The failure surface multiplies.** A single-shot answer is either right or wrong and a human notices. A chain can take a correct first step, a correct second step, and a wrong third one, then present a fluent conclusion that carries no trace of where it went off. That is considerably harder to catch in review than an obviously bad answer, and it is the reason evaluation on reasoning systems has to look at the path and not only the output. None of that is an argument against reasoning models. It is an argument for knowing which of your workflows genuinely has a chain in it, because those are the ones where the trade is worth making. ## The permission blast radius This is the part we would look at first on any org, and it is specific to how Salesforce enforces access. A single-shot summarisation touches one record and inherits that record's sharing. A reasoning chain traverses: it reads the Account, follows to the Opportunity, checks a related Contract, looks at a Case, and pulls an Order line. Every hop is a separate access decision, and the chain is only as safe as the weakest one. In practice that means several things have to be true at once, and in most orgs at least one is not: | Control | What it has to do | Where it goes wrong | | --- | --- | --- | | Org-wide defaults and sharing rules | Decide what the running user can see on every object in the chain, not just the entry point | An object left Public Read/Write years ago because "nobody looks at it directly" | | Field-level security | Hide fields the user may not read, including on related objects | FLS set on the page layout rather than the profile, so an API read returns it anyway | | Restriction rules | Narrow access below the sharing model on sensitive objects | Rarely deployed, because they were added after most orgs set their model | | Apex sharing and `with sharing` | Enforce sharing in any custom code the agent invokes | A `without sharing` class written for a batch job, now reachable from an agent action | | Integration user permissions | Bound what a service account can reach | A single integration user with Modify All Data, because it was easier | The last row is the one that ends programmes. If your agent runs as an integration user with broad access rather than on behalf of the person asking, then every guardrail above is decoration. The model is not the risk. The identity the model runs as is the risk. Working this out is not a model question and no vendor announcement resolves it. It is an access review, and it is the same review whether the reasoning happens in Koa, in Gemini or in a model that does not exist yet. ## How we would evaluate it, concretely Most teams "test" an AI feature by trying it. That produces an opinion, not a baseline, and opinions do not survive a change of model. What we build instead, and what we would build before letting a reasoning model near a production workflow: **A replay set from closed work.** Twenty to fifty cases, opportunities or requests that have already been resolved, where a human decision is on record. That decision is the known-good answer. Invented test questions are useless here because they are too clean: one intent each, correct reference numbers, all the context in the first sentence. Real work arrives with two questions at once, a wrong order number, and the important detail three messages in. **A path assertion, not just an answer assertion.** For a reasoning chain, record which records the agent read and which actions it proposed, then assert on those too. An agent that reaches the right answer by reading something it should not have is a failure that an output-only test scores as a pass. **A refusal set.** Questions the agent must decline, tested in three forms: asked directly, asked indirectly, and asked halfway through an unrelated conversation. Refusal that only holds against the direct form has not been tested. **A baseline measured before anything is added.** What the current process costs and how long it takes today. Without it, every improvement claim afterwards is unfalsifiable. That set is the asset. It outlives the model, it makes the next model swap a measurement rather than an argument, and it is the single most reliable predictor we have of whether an AI programme will still be running in a year. ## Where we would start on your org Our honest answer to "should we adopt Koa" is that it is the wrong first question, and we would rather charge you for the right one. A readiness review on a single workflow usually takes a couple of weeks and produces four things: a map of every fact the workflow depends on with a named owner for each, an access trace showing exactly what the agent would be able to reach on the current sharing model, a replay set built from your own closed cases, and a written recommendation on whether to use a reasoning model, the platform's own AI, or deterministic automation that costs nothing to run. That last option is real and we recommend it more often than clients expect. A rule you can write down without hedging does not need a model, and paying per token to evaluate a condition that a Flow decides for free is a cost that compounds quietly. If the review says the foundations are not ready, it says so with the specific list of what to fix, which is worth more than a proof of concept that works on a curated slice and collapses on the second team. ## Where this fits with the rest of the stack Koa arrives alongside the rest of what Salesforce has been assembling: the Agentforce 360 portfolio, which its own newsroom now describes as including Slack, and the completed Fin acquisition on 10 September. Read together, the direction is a platform that expects agents to be doing multistep work across the customer record rather than answering questions beside it. That direction is the right one, and it raises the bar on foundations rather than lowering it. The orgs that will get value from a reasoning model this year are the ones that did the unglamorous data and permission work last year. ## The honest summary Koa is a significant announcement and a specialised model is the correct response to how badly general models handle CRM structure. It is also not a shortcut past the three things that decide whether enterprise AI works: one owner per fact, permissions enforced in the data layer, and an agreed measure of a correct answer. If those three are in place, this is good news. If they are not, this is the same news it has always been. ## Questions ### What is Koa? Koa is a CRM reasoning model announced by Salesforce on 15 September 2026, built on NVIDIA Nemotron. Salesforce describes it as trained with 27 years of Salesforce CRM intelligence, so that agents can reason through the complex multistep tasks enterprise work requires. ### How is a reasoning model different from the model behind a normal AI assistant? A reasoning model is built to work through a problem in steps rather than answer in one pass, which is what multistep tasks need: read a record, check a related one, apply a rule, decide. The trade is usually latency and cost per call, so the question for any given workflow is whether the task genuinely needs the reasoning. ### Does Koa remove the need for data and permission work first? No, and it makes that work matter more. A model that reasons across several records touches more of your data model in one request than a single-shot answer does. Where the same fact holds different values in different systems, stronger reasoning produces a more confident wrong answer, not a right one. ### What should an enterprise do about Koa this quarter? Nothing architectural on the strength of an announcement. Identify one workflow where multistep reasoning would genuinely help, write down every fact it depends on and who owns each, and build a set of twenty already-resolved cases as an evaluation baseline. That work pays off regardless of which model you end up using. --- SynconAI is a Salesforce Select Partner and an OpenAI Select Partner, delivering architect-led Salesforce and AI programmes across the United States and Australia. Related service: Agentforce and AI enablement (https://synconai.com/salesforce-consultancy).