Salesforce Offers SaaS Companies Worldwide a Blueprint: Training 27 Years of Software Experience into AI Without Touching Customer Data

A couple of days ago, one item in the business briefing my agent sent me caught my attention:

Salesforce had released a CRM reasoning model called Koa, saying it had trained 27 years of CRM experience into the model.

I used to work in SaaS, and I come from a sales background, so CRM is familiar territory. Salesforce is the clear heavyweight in the field, and plenty of Chinese CRM products have ‘copied’ it. But over the past couple of years, as we entered the AI era, it had rarely appeared in my feeds. I had almost forgotten about it.

So seeing the Salesforce name, a reasoning model, and ‘27 years of business experience’ together immediately got me interested.

The world’s biggest CRM giant was building its own reasoning model, and claiming to have packed ‘27 years of experience’ into it. My first reaction was: a model, rather than an agent? How do you ‘pack’ 27 years of business experience into one?

Even more interestingly, it explicitly stated:

No real customer data was used anywhere in the training process.

What?! No customer data?

Then what exactly was this supposed ‘27 years of business experience’?

That made me even more curious. I followed the story and kept digging, getting more excited the more I read.

Because underneath it was a fundamental—and fascinating—shift in enterprise software in the AI era.

First, a distinction: Koa is the brain, not the agent

Before getting into how it works, let’s clear up an easy misunderstanding.

Reading a news summary, many people could easily assume that Salesforce had built an agent called Koa.

That is not the case.

The paper’s title is very precise:

Salesforce Koa: An Enterprise Language Model for Agentic Tool Use.

In plain language, that means:

An enterprise large language model built specifically for agents to use tools.

So it is a full-fledged large foundation model with 120 billion parameters.

On September 15, Salesforce and NVIDIA announced Koa. They post-trained NVIDIA Nemotron, an open-weight foundation model, for enterprise work, producing a reasoning model for Salesforce’s own Agentforce platform.

How, then, does it relate to what we usually call an agent?

If we break down a digital employee working inside a business:

Koa is that employee’s brain.

The surrounding Agentforce platform is its body and execution system; the underlying CRM database, email, and business interfaces are its hands and feet.

Suppose you run a company. Bringing in a general-purpose large language model is like hiring a fresh graduate from a top university.

You ask: ‘We’ve spoken with this customer three times. Their budget is 800,000, but the contract is still unsigned. What should I do next?’

It can write you a very convincing high-level analysis.

But a real business needs someone to carry out specific tasks, rather than just produce an analysis:

Tasks:
① Find this customer’s opportunity record
② Review the records of the last three conversations
③ Check the contract’s approval status
④ Decide what the sales stage should be changed to
⑤ Update the system’s data
⑥ Create a follow-up task for the legal team
⑦ Notify the relevant business owner
⑧ Automatically send another reminder in three days if the contract is still unsigned

This is the work Koa is meant to do.

Here is another common everyday scenario.

A customer sends a question: ‘Why has our bill suddenly gone up by 20% this month?’

An ordinary chatbot would just search the help documentation and write a polite explanation of billing that does not solve the problem.

A system powered by Koa, on the other hand, works through a sequence of business decisions:

Step 1: Identify the customer
Step 2: Call an interface to retrieve the account’s subscription history
Step 3: Compare the two months’ bills and identify 25 additional user accounts
Step 4: Check permission records to find out who approved the additions and on what date
Step 5: Determine whether the bill follows the rules
   · If it is correct: clearly explain the changes to the customer
   · If it was calculated incorrectly: automatically create an exception ticket and send it to finance for review

During this process, Koa does not reach into the database and change the data itself.

It is responsible for just two things:

Understanding the current business state, and deciding which tool to call next.

The surrounding runtime system carries out the actual operations.

Koa is the ‘business decision-making brain’ Salesforce has trained specifically for its own systems.

All right, that brings us to the question: how did Salesforce train this brain called Koa while claiming it never used a single piece of customer data?

27 years of experience became a ‘practice ground’ for AI

In this part, let’s look at how Salesforce could put 27 years of experience into this brain without customer data—and what it was actually putting in.

The answer is unexpected: Workflow Specification.

What is the most valuable ‘inheritance’ Salesforce has built up over the past 27 years?

It is not the confidential transaction records of individual companies in its databases, or the number of contracts stored there. It is the business workflow specifications accumulated over time:

When a sales lead comes in, what conditions must it meet to become an opportunity?

Under what circumstances must a support ticket be escalated to a supervisor?

What levels of approval does a refund of more than $5,000 require? Can a refund still be issued after 30 days?

What do standard operating procedures actually look like across finance, manufacturing, healthcare, and other industries?

These rules used to sit inside product logic, data architectures, permission boundaries, and industry solutions.

They did something extremely clever:

They used these mature business specifications to build an enormous ‘business operations simulator’ inside the system.

Salesforce synthesized vast numbers of virtual scenarios across 14 industries.

Then they brought in an auxiliary large language model to play three roles in the simulator:

• Role one: play all kinds of virtual customers, including deliberately difficult ones;
• Role two: play the software system, returning realistic simulated data in response to tool calls;
• Role three: act as the judge, watching and scoring the entire process.

They put Koa into this virtual sandbox and sent it ‘to work.’

Every task in the sandbox was defined very clearly:

Simulated work task: Handle a customer’s refund request
Available tools:
· Look up customer information
· Look up past orders
· Look up the refund policy
· Issue a refund
· Hand over to a human support representative
Work rules:
· Refunds above $5,000 require human approval
· Purchases made more than 30 days ago cannot be refunded directly
· The actual status of the order must be checked first
Success criteria:
· The customer’s issue is resolved in accordance with the rules
· No permissions are exceeded and no tools are misused

A virtual customer arrives and says: ‘The software I bought two months ago doesn’t work well. I want a refund now!’

Koa must work through this in the sandbox on its own: look up the customer → look up the order → discover that the purchase was made 63 days ago → check the refund rules → recognize that it is past the deadline and cannot issue a direct refund → explain this to the customer and hand over to a human if necessary.

If it simply went along with the customer and said, ‘Sure, your refund has been issued,’ that might sound like good service, but it would not be doing the job correctly.

Koa can run through a single scenario thousands or tens of thousands of times in the simulator.

The real training asset is not static, inert data sitting in a database. It is work experience turned into a ‘business simulator’ that can keep generating training scenarios.

When it came to the training mechanism itself, Salesforce also found something crucial:

For complex, multi-turn tool use, traditional supervised fine-tuning, or SFT—having the model memorize a bank of exercises—was of little use.

Real business situations never have just one correct answer. When dealing with a complaining customer, one person might check the conversation history first, while another checks the order. Force a model to memorize one fixed sequence of steps, and the slightest change in a real situation can leave it stuck in a loop.

So they put their full focus on reinforcement learning.

The judge has to examine the entire process. For questions involving specific business data, did the model call the relevant tools to obtain evidence? Which of the customer’s issues were actually resolved?

Get the job done without crossing any red lines → earn a reward;

Fail to get it done, or call tools indiscriminately → lose points;

If the same tool call is repeated consecutively, the reward for that round is set straight to zero.

These work processes and the feedback they generate are used to adjust the model’s parameters. That is how reinforcement learning works here. The model can practice the same type of task repeatedly, trying different situations and gradually improving its score.

Salesforce also deliberately removes tools that could get the job done, to see how the model responds. When it cannot do something, it must explain what is missing or hand the task over to a person. It must not pretend the work is finished.

Being able to do the work also means knowing when not to act recklessly.

Only at this point did I understand what those ‘27 years of experience’ actually looked like.

A company that has spent 27 years building CRM software knows better than anyone how to assess sales leads, route tickets, and determine which actions require approval. That accumulated knowledge lets it define clear work rules, create practice scenarios, and know how to check the results. The conversations, actions, and feedback generated through those simulations are then used for training.

It turns out that the working methods accumulated in software can also be used to set exercises for AI.

Koa certainly won’t outscore today’s handful of top-tier models on benchmarks, but Salesforce was never trying to compete with general-purpose models at writing poetry or code.

What it wants is this: across the few thousand core actions that businesses perform every day, a model that is controllable enough, cheap enough, and firmly in its own hands.

An old SaaS pain point: businesses can afford the software but struggle to use it

By this point, I was feeling quite reflective.

I used to work in SaaS and came from a sales background. In all fairness, the rise of SaaS over the past thirty years has been a huge step forward for business.

It turned customer information that had been scattered across salespeople’s heads—and even their little notebooks—into standardized processes. Following up on leads, advancing opportunities through sales stages, and routing approvals all moved to the cloud. Business processes became standardized, information could be shared, and teams could work together more smoothly.

But another unavoidable source of friction appeared at the same time. I suspect anyone who has worked in SaaS will recognize the pain:

A business has bought the software. Can its employees actually put it to use?

Not necessarily.

Why?

Because every piece of software has a learning curve. People must first learn how to operate it before they can use it. Many companies and sales teams understand the importance of management and collaboration perfectly well; they simply get stuck at the very first step. This is especially apparent in the Chinese market.

A good salesperson’s core strengths should be understanding customers, identifying needs, and building trust.

But to keep the system running, they also have to spend a great deal of time and energy every day adapting to the software. Which field does this information go in? How should I change the opportunity stage? Where has the approval process got to? Which menu do I click next?

All too often, to get something done, employees first have to train themselves to become skilled ‘software operators.’

This is why enterprise software has spawned such large teams of implementation consultants and trainers, along with dedicated teams at some big companies whose role is called Customer Success.

Businesses buy CRM because they want to manage sales well and keep their operations working. They do not want a software manual hundreds of pages long, followed by three months spent getting familiar with the software.

Yet there has long been an enormous gap between selling software and using it well. Software companies have relied on armies of customer success and implementation staff working on-site, teaching customers step by step how to configure and operate the software, and how to fit their businesses into the system.

Essentially, everyone has been using human services to bridge the gap between ‘business intent’ and ‘software operations.’

That brings us to a question we take for granted but rarely think deeply about:

Why must people learn the software before the work can move forward?

A fundamental reversal: from ‘people learning software’ to ‘software teaching AI how to work’

What I find most inspiring about Koa is precisely how it breaks that habit.

Put these two things side by side, and the reversal in structure becomes very clear:

This is a fundamental reversal.

Consider the operational knowledge that once required a consultant sitting beside you to teach it, and employees practicing it again and again: who should this ticket be assigned to? What key information is missing from this opportunity? Which underlying interfaces should be called to check this refund?

Those abilities are now being compressed into a model’s weights.

Software is moving from ‘software you learn to use’

to ‘software that knows how to use itself.’

You no longer need to figure out what a button buried in a submenu is called, or remember where to submit the details when converting a lead into an opportunity.

You simply state your business goal as you would to an experienced business assistant:

‘Find the customers whose deals we lost last month but still have a chance of winning back. Work out why we lost them, arrange the safe follow-up actions directly, and list anything that needs my confirmation.’

The model quietly handles the remaining work in the background: looking up records, comparing them, linking objects, processing tickets, and sending notifications.

As the model absorbs the burden of learning and operating software, the friction between people and tools is, for the first time, dramatically reduced.

Software won’t disappear, but our relationship with it will change

Take that logic one step further: if agents increasingly operate software, will SaaS as we know it disappear?

I do not think software will disappear entirely. It will simply become less and less visible to people.

The day after releasing Koa, Salesforce followed up with another product move: AIforce.

The official announcement used a very direct term: Headless.

In everyday language, that means taking away the ‘face.’

(The ‘face’ here means the user interface that people see.)

The familiar image of software we have lived with for thirty years—complicated menus, rows of tables, flashy dashboards, and web pages you must log into before you can click anything—is moving into the background.

Salesforce even says outright in its promotional material that employees may go months without logging into Salesforce in the future. From Slack, Claude, or any chat window they regularly use, they will be able to call its capabilities directly.

But that certainly does not mean software is dead. Instead, it splits software clearly into two layers:

One layer: the System of Record

Customer records, financial transactions, permission boundaries, and compliance audits. These core assets will not disappear. On the contrary, they will become the one trusted anchor to reality for agents acting in the real world.

The other layer: the Capability Layer

Software companies will no longer sell only static pages. They will expose Salesforce’s data, workflows, business logic, permissions, and actions through MCP, APIs, plugins, and skills.

Software sheds the outer layer designed for humans to click, moves into the background, and becomes the underlying foundation of capabilities on which a business runs.

In the future, counting a software company’s features and pages may tell us less and less. What deserves more attention is whether its understanding of business can actually help an agent get the work done.

The rules, permissions, tools, and success criteria inside software—all the things that used to sit behind the interface—will become more worthy of study.

In the past, we turned work experience into software, then taught people to use it;

now, we use that experience to train AI to operate software on people’s behalf.

Software has not disappeared, but the relationship between people and software has changed completely.

I think what people have always hoped for is not really ‘never having to work again.’ It is finally being able to give more thought to the work itself, and spend less time figuring out how to use the tools.

How to nurture customer relationships, how to run a business, how to understand real people and their needs—these things, full of human warmth and business judgment, deserve our serious attention.

As for which box the information goes in or which button to click next, let the tools do a little more of the worrying.