Stop treating every CRM AI job like it needs the same model
Salesforce just explained why Koa sits beside frontier models instead of replacing them. For architects, model choice is now a design decision: match cost, trust boundary and reasoning style to the workflow.
On 13 October the Salesforce Newsroom published a short interview with Chief Data Officer Michael Andrew about something quieter than a feature launch: which AI model should run which job. The piece centres on Koa, Salesforce's first CRM reasoning model, built with NVIDIA and trained on simulations drawn from 27 years of CRM workflow experience. It runs inside the Salesforce trust boundary and is meant to sit alongside frontier and open models, not replace them.
That framing matters more than the product name. For most of the last two years, CRM AI projects started with "which model are we buying?" I think the better question is "which models, for which steps?"
What Salesforce is actually saying
Andrew's point in the interview is blunt. Different models have different strengths, and those strengths keep moving. Frontier models from partners such as Anthropic and OpenAI, open-source models, and custom models like Koa all have a place. Customers should pick by use case, cost and value, while keeping data inside a secure process they control.
He also draws a useful line between deterministic and probabilistic systems. Pressing a button to open a case always opens a case. Asking an agent to decide what to do next is closer to asking a new hire: you can train and guide them, but the answer is not guaranteed every time. Businesses run on the first kind of system. Agents are the second. Connecting those two worlds is why the model under an agent is not a branding choice.
Seafoam Media's October RevOps brief adds the deployment detail I care about as someone who has to ship this to clients. Salesforce and NVIDIA announced Koa as a CRM reasoning model for Agentforce, built on NVIDIA Nemotron. Salesforce says it matches or exceeds leading model performance on CRM actions with three times fewer errors. Seafoam notes, correctly, that Salesforce has not named the benchmark or the comparator behind that figure. Customer pilots start in October inside Agentforce, with U.S. general availability expected in winter. So this is not a "switch everything to Koa tomorrow" story. It is a design story that starts now.
Why a purpose-built CRM model exists
Routing a case, updating an opportunity stage, assembling a renewal package and checking a consent flag are multistep CRM jobs. They reward precise reasoning over familiar objects more than open-ended writing. A frontier model is often excellent at drafting an email or summarising a long thread. It is less obviously the right default for a workflow that must respect stage definitions, sharing rules and validation logic that your org has spent years encoding.
Koa is Salesforce's bet that a model trained on CRM simulations will make fewer of those workflow mistakes, while still living inside the trust boundary. Andrew is clear that it is orchestrated with frontier models, not instead of them. That is the architecture I want clients to copy even if they never touch Koa: one model for reasoning over CRM state, another for language-heavy work, with the platform deciding which step runs where.
Multiplayer AI changes the evaluation too
The same interview covers agents in Slack. Instead of one person talking to one agent in a private tab, people and agents share a channel and the same context. Andrew describes the agent as another teammate that already knows what the team said about the deal or the customer issue.
That changes how you judge a model. Accuracy on a single prompt is not enough. You also care whether the agent stays inside channel permissions and whether a wrong answer is visible before it becomes a record update. Shared context is powerful. It also means a bad model choice fails in public.
How I'd design model choice on a project
If I were scoping an Agentforce or AIforce project this month, I would not start with a bake-off of brand names. I would map the workflow first.
- Separate deterministic steps from judgement steps. Anything that must always produce the same result (create the case, apply the discount rule, write the audit field) stays in Flow, Apex or validation. Models advise; platform logic commits.
- Label each judgement step by what it needs. Speed and cost for triage. Strong CRM object reasoning for stage changes and renewals. Long-context language for summaries and customer-facing drafts. Those labels usually point at different models.
- Prefer the trust boundary for anything that reads sensitive fields. If a step needs closed-won amounts, health data or contract terms, a model that runs inside Salesforce's trust boundary is easier to defend to security than shipping that context to a general endpoint.
- Agree on stage and status meanings before you pilot. Seafoam's brief puts it well: an agent that reasons well over opportunity stages your reps each define differently will still get the answer wrong, just faster. Model quality cannot fix a disputed dictionary.
- Keep the right to swap models. Andrew's strongest line is that customers should keep evolving which model they use for a use case. Design the integration so the model is a configuration choice, not a rewrite.
The takeaway for CRM and RevOps teams
I am not asking anyone to wait for Koa GA before doing useful AI work. I am asking teams to stop treating "the CRM AI model" as a single SKU. Salesforce's own CDO is saying out loud that frontier, open and purpose-built CRM models will sit side by side, picked by job, cost and trust.
So in your next planning session, list the five agent workflows you actually want live this quarter. For each one, write down whether the hard part is language, CRM reasoning or a hard rule that should never be probabilistic. Put the hard rules in the platform. Put language work where the best writing model is. Put CRM reasoning where the trust boundary and object fluency are strongest. That is how you use model choice as an architecture decision instead of a vendor fashion cycle.