TL;DR: Salesforce Koa, Harvey Tenet, and Shopify’s specialist AI models show how software companies are teaching models to perform domain-specific work. In my System of Execution framework, the strategic question is who controls the workflows, outcome evidence, and permissions needed to turn that experience into learning - and whether the resulting advantage can endure.
As AI makes code cheaper to produce, much of software is focused on building more of it. This has been obvious for quite some time now, as coding has become the hot use case.
However, this dynamic is taking another leap forward, as seen in three recent product announcements involving specialist models: Salesforce’s Koa, Harvey’s Tenet, and recent Shopify ML team experiments. These point to a second shift underway, where some expertise that used to be written as procedure can now be learned into model weights.
This evolution matters economically. A software company can take a capable open-weight model, train it for a defined job, and potentially lower the cost of delivering intelligence inside its product. Weights become another way to package and deploy expertise.
In that sense, weights are the new code.
Last month in The System of Execution, I argued that an emerging source of enterprise value lies in controlling the loop from intent and authority through execution, verification, and outcome. I called the evidence of this system the “receipt”: a record of what was authorized, what happened, and what resulted.
And yet, in defining this concept, I left the next step largely unexplored: What can the system learn from that record? After attending Dreamforce last week, I was inspired to come back to that unasked and unanswered question.
My argument here is that as specialist models become easier to build, lasting advantage may depend less on the weights themselves than on the process that improves them: the environment in which they practice, the judgment of what counts as success, and access to real outcomes with permission to learn from them. Frontier models remain essential.
The question is how much defined, repeated work software companies can take into their own hands, and whether doing so creates a lasting advantage.
Salesforce Koa and the specialist AI shift
At Salesforce’s Dreamforce 2026 conference at the Moscone Center in San Francisco, CEO Marc Benioff delivered his two-hour keynote while strolling around the audience in the auditorium rather than standing above them on stage. After delivering a series of strategic and product updates, he called upon special guests emblematic of the company’s agentic reinvention.
The first was Anthropic CEO Dario Amodei. A short time later, Nvidia CEO Jensen Huang jumped out of a chair and joined Benioff to walk through the crowd. “We’re all following you, bro” Benioff joked.
The exchange between the two CEOs captured the larger story that unfolded throughout the week: the head of a software empire following the man supplying open models to help him enter a new era.
Earlier, Benioff had dismissed talk of a SaaSpocalypse as “crazy nonsense” and described an interface shift in which Salesforce increasingly appears through Claude and Slack while its records and business logic sit underneath. Huang called AI “a layer on top of software”.
I agree with both. However, the more important announcement for me was Salesforce Koa. On September 15, Salesforce introduced its first CRM reasoning model.
For me, Koa raised a question that extends beyond the interface: how much of the expertise inside an application can a software company teach to a model it controls?
Let’s look at that announcement, as well as two other related ones that I think illuminate this issue:
Salesforce Koa. This is Salesforce’s first CRM reasoning model, built by further training NVIDIA’s open-weight Nemotron 3 Super. Salesforce controls the resulting weights and runs the model within its own infrastructure.
What matters is how Koa was taught. Salesforce’s AI leaders said imitating transcripts of successful work produced limited gains on the complex interactions they wanted to improve, so they “made it do the work”. The team built simulated workflows across more than fourteen industries. Synthetic customers arrived with different requests; tools answered the agent’s calls; a judge scored whether the task was resolved; repeated attempts supplied the feedback used to improve the model.
Salesforce says it used no customer data. Its accumulated knowledge entered through the environment: which situations the model encountered, which actions were available, and what counted as success. A company founded in 1999 with “No Software” as its slogan was turning some of its business-process knowledge into learned behavior.
Harvey Tenet. The legal AI company previewed Tenet on August 20, using Moonshot’s open-weight Kimi K3 as its base. Harvey trained the model on extended legal tasks, evaluated its work against expert rubrics, and used those scores to improve subsequent performance. The company also says it used no customer data. By Harvey’s own measurement, Tenet completes nearly twice as many held-out tasks as the underlying model. It is a research preview, not a product. The result supports the potential of specialization. But it has not yet established how the model will perform across customers’ everyday legal work.
Shopify. The e-commerce company offers a view of the next step: learning from deployment. Its engineering team describes a daily process that turns production failures into training material. The team evaluates, corrects, and replays difficult conversations. Successful repairs become examples for subsequent training. The improvement depends on the machinery around the model.
A narrower experiment shows how far specialization can go. On September 1, CEO Tobi Lutke shared a slide from a buyer-profile model with just 0.8 billion parameters. Over one week, as the training set expanded, the student moved from below Shopify’s production model to above the frontier model that taught it. Lutke called it a “very specialized task”.
These examples establish different parts of the argument. Salesforce and Harvey show how domain expertise can shape environments and evaluations. Shopify shows how production experience can feed subsequent updates. Whether that becomes a durable advantage depends on who can keep improving the system.
How specialist AI models learn software procedures
Enterprise software has always turned expertise into repeatable procedure: domain experts described how work should happen, engineers encoded it, and applications repeated the instructions at low marginal cost:
Specialist models introduce another place to put some of that operational knowledge.
Engineers can define a task, build examples or an environment to practice in, and specify how success will be judged. Training adjusts the model’s weights toward the behavior that earns those rewards. Andrej Karpathy described the general idea in Software 2.0 as training that “compiles the dataset into the binary”. Koa applies that logic to enterprise workflows.
Again, it’s essential to understand the mechanism behind this. In Koa’s paper, a developer’s specification of workflows and available tools is compiled into a training environment. The model attempts tasks inside that environment, receives feedback, and is trained on the results. The specification structures the practice. Training then changes the weights. However, reliability still has to be tested.
That gives a software company another place to put its operational knowledge. Some of the expertise involved in choosing a next step, gathering missing information or using the right tool can become learned behavior. As Marc Benioff noted with the release of Koa: “the knowledge is put inside the model itself”, and his next sentence says which knowledge: the structure of a deal, the lifecycle of a service case. That is expertise that used to be written as software.
But knowing how to work a service case is different from knowing what happened in yours this morning.
A 2023 study by Microsoft researchers illustrates that distinction. On questions about events after its training cutoff, Mistral 7B achieved roughly 50% accuracy after fine-tuning on the relevant material, 59% with additional paraphrases, and 88% when relevant passages were retrieved at answer time. That experiment supports a practical reason to supply changing facts through retrieval. It does not establish a universal boundary between what belongs in weights and what belongs outside them.
For a service agent, the responsibilities can be separated like this:
Koa contributes learned behavior within this larger system. It still needs access to current records, authorized tools, and the software that carries out its decisions. Those dependencies connect the model to capabilities Salesforce has spent decades building.
Weights are also only one place to encode better behavior. A team can revise prompts, update instructions an agent loads, or change the surrounding code. The economic question is which combination delivers reliable work at the lowest total cost.
What interests me is the possibility of making experience part of that development process. Running a model does not automatically improve it. Someone must capture what happened, judge the result, turn useful feedback into changes, and verify that those changes help. As more procedure can be learned, the system that does this work becomes part of the argument about where software’s value will reside.
Agent traces and the System of Execution
That brings the argument back to the receipt. An agent trace records the steps around an authorized action: the request, context, tools called, approvals or corrections, and results observed. Linked to a reliable assessment of success, it becomes evidence the next version of the system can learn from.
The assessment is essential. An agent can update the right field and still make the wrong business decision. A customer can accept an answer that later proves incorrect. The valuable record connects what the agent attempted with what ultimately happened.
In The System of Execution, I called the evidence of authorized work and its result the receipt. I considered its role in charging for execution. It can also support learning.
Cursor says it uses production interactions to derive training rewards for Composer and can deploy a new version as often as every five hours. Shopify describes a loop that identifies failures in production conversations, repairs them with models and human experts, and uses the resulting examples in further training. Both examples show how much machinery sits between an interaction and an improvement.
This is where scale could acquire a different meaning in enterprise software: not merely customers or records, but the volume and variety of useful, evaluated work a company can learn from. A competitor can download the same base model. Reproducing the situations your customers encounter, the corrections they make, and the outcomes you can observe may be harder.
Where the trace is assembled
Enterprise outcomes are often distributed. An approval may happen in one application, an action in another, and its commercial result days later. Surrounding software must assemble those events. An agent harness supplies context, exposes tools, enforces permissions, and manages execution; to support learning, it also needs to connect attempts with outcomes and evaluate them.
Salesforce’s Enterprise AI Harness describes an architecture spanning those responsibilities. Many underlying components already exist; other capabilities and the unified experience remain planned. It is evidence of where Salesforce intends to position itself, not proof yet of a completed learning loop.
Who gets to learn from it?
The strategic question therefore has three parts: who can assemble the record, who is permitted to learn from it, and who captures the benefit? Architecture shapes the first. Customer agreements and choices govern the second. Product performance and pricing determine the third.
Salesforce makes that distinction explicit: “your data and your traces never train the model” even as it describes the record of a customer’s agents at work as “the edge no competitor can copy”. The trace may be valuable without belonging to the platform for shared model training.
Claudeforce shows why architecture alone does not settle ownership. When Claude runs inside Salesforce, Salesforce supplies the workflows and controls. When Salesforce is used inside Claude, the conversation may sit in Claude while Salesforce retains the authoritative record of execution. Salesforce may also capture the agent trace in that second configuration. Every action Claude takes against Salesforce arrives as an authenticated API call under the user's identity, through Salesforce's hosted MCP servers, and Salesforce logs what was read and what was written. What it does not see is the reasoning that produced the call. The trace splits: Claude holds the intent and the deliberation, Salesforce holds the action and its result. Public statements do not establish that either side exclusively holds the complete useful trace. Anthropic says it does not train on commercial customers' inputs and outputs by default, subject to feedback and explicit permission. That commitment concerns model training, not every possible use of records as context or operational evidence.
Where enterprise AI captures value
I see two economic paths for software companies.
In the first, a vendor can remain valuable without training its own model if it controls authoritative records, permissions, integrations, and execution. Those capabilities still matter when users start in another company’s interface.
The second path is improving the economics of the intelligence used to do that work. Koa gives Salesforce the option to train and serve a model it controls for suitable tasks alongside rented frontier models. The right comparison is total cost per successful task: training, serving, evaluation, maintenance, retries, and human intervention. A lower inference bill matters only if the specialist meets the required standard.
The two paths can reinforce each other. Running the workflow reveals recurring tasks, acceptable performance, and where specialization is worthwhile. Savings from a specialist can appear first in margins even without a separate model’s product or price. They can also fund lower prices, broader availability, or new capabilities. Competition determines how much the vendor keeps. Salesforce’s promise not to train Koa on customer traces fits this model: it can earn from the surrounding system while customers improve their own agents through context, prompts, skills, and workflow changes.
Customer traces do not automatically become a moat. A log is most useful when connected to the relevant records, tool definitions, permissions, and outcomes. Preserving those connections may create switching costs; the mere existence of the log does not.
That gives a better test of defensibility: which records must remain authoritative? Who can grant permission to act? Who can observe the result, evaluate it, and use it to improve subsequent work? And how easily can a competitor provide those capabilities?
The valuable position may belong to whoever can connect enough of the process to complete the work, verify the result, and earn the customer’s continued trust.
When to train a specialist and when to rent the frontier
The answer is not that specialist models replace frontier models. It is that they do different jobs:
Train a specialist when the work is high-volume · bounded · scoreable · stable procedure rather than fresh fact · sensitive to cost and latency · on your own surface, where you see what happened next.
Rent the frontier when the work is open-ended · long-horizon · rare · novel · a judgment call.
On Salesforce’s own CRM benchmark, Koa scores 0.86, above its untouched base at 0.84 and below the two frontier models it was tested against, at 0.90 and 0.87. The default in Salesforce’s new agent builder is OpenAI’s GPT-4.1. The system Harvey first benchmarked was overtaken by seven foundation models within a year.
A third architecture is to rent the model while keeping what you learn in the harness: prompts, skills, tools, routing and evaluations.
The frontier also remains the escalation layer inside bounded work. In a Fireworks test with Harvey, Claude Opus 4.7 alone passed fourteen of 100 long legal tasks. An open model doing the work with Opus available as an adviser passed eighteen at about two-fifths of the cost. The difference in task success sat inside the test’s noise; the cost gap did not. One possible future is therefore not displacement but selective invocation: the frontier handles uncertainty rather than every step.
It also remains the teacher. Shopify’s slide labels its frontier model “the teacher” and the small model “the student”. Where that role exists, access is licensed. The large labs’ public terms restrict using outputs to build competing models; whether a narrow internal specialist qualifies is not clear from public language, and enterprise agreements differ. The narrower point is that access to the teacher can be priced, conditioned, or restricted. So the frontier is not displaced. Its role narrows, and its share of volume can fall.
The durable asset is not the current weights. A specialist will age, and a better base will appear. If the company owns the training environment, evaluator, and examples that produced the model, it can rebuild on the new base. Shopify has described one Flow training run that takes about twelve hours on two nodes; Harvey’s Tenet effort used roughly 150 B300 GPUs over two months. Recompilation is possible, not automatically cheap.
Koa and Tenet already own part of that source: the environment and judge. Shopify Flow is a stronger case because production conversations become training signals. The open question is whether that loop becomes a durable economic advantage rather than simply a better engineering process.
Why open-weight models change enterprise AI economics
A closed model can be tuned on your procedure inside a provider’s boundary. What the customer does not get is the underlying artifact: weights they can take elsewhere, serve on their own cost line, or rebuild on their own schedule. Open weights change that control point.
All three cases in this essay sit on open bases: Nemotron under Koa, Kimi under Tenet, and Qwen under Shopify’s models. By Epoch AI’s measure, the best open-weight models have trailed the closed frontier by about four months on average since January 2026. For open-ended research, that gap can matter enormously.
For bounded, scoreable work, it may not.
That is where efficiency matters. Capability gets intelligence into the demo. Efficiency gets it into every transaction.
Shopify’s examples show the difference. Its 0.8-billion-parameter buyer-profile student combined a much shorter prompt with capacity rising from roughly 2 million profiles a day to 72 million. Separately, Shopify estimates that serving its Sidekick GraphQL agent with a frontier model would cost roughly $27 million a year versus about $1 million for its specialist. These are company estimates, not independently reproduced economics. But the unit is the right one: the cost of putting intelligence into a production workflow millions of times.
The specialist does not have to beat the frontier everywhere. It must make the work affordable enough to happen far more often.
A market-level hint of that split already exists. Huang said from the Dreamforce stage that open models had gone from roughly 30% to some 70% because people are “building their own custom AIs”. A cleaner public trace comes from Vercel’s AI Gateway: open-weight models carried 29% of tokens in June on less than 4% of spend; by August they carried 56% of tokens and 14% of spend. Vercel is one developer gateway, not the enterprise market, and most of those models are rented rather than owned. But cheap models are absorbing volume much faster than dollars.
The enterprise is further behind. Menlo Ventures estimated open-source models at 11% of enterprise LLM spend at the end of 2025 and found that prompt design and retrieval still dominate customization. Fine-tuning and more elaborate learning architectures remain relatively rare.
Those facts describe different stages of diffusion. Developers can already route routine inference to cheap open models. The stronger claim begins when a company has enough repeated work, feedback, and evaluation to compile what it knows into a model it controls.
Volume moves first. Ownership can follow.
That is why open weights matter here. They do not guarantee that open models beat closed ones, or that every enterprise should train its own model. They create an option: once a workflow becomes stable and valuable enough, the company that owns it can move procedure into the weights, choose where those weights run, and repeat the process on a better base.
Weights begin to behave more like software. But weights are not the new moat.
As capable weights become easier to reproduce, the question moves to what the model cannot manufacture: the customer’s live context, the history of what happened after it acted, the authority to change the system of record, and the environment against which its work is judged.
Those assets sit around the model. The System of Execution owns the context, authority, action, and outcome. If it can turn the receipt into an evaluation, and the evaluation into the next prompt, skill, routing rule, or set of weights, execution itself becomes the source from which the system is rebuilt.
The receipt turns out to be the source code.
That does not mean value leaves the model layer. The frontier still supplies the hardest reasoning, the teachers and the new bases from which specialists are compiled. But as intelligence becomes cheaper and more reproducible, scarcity moves toward the things that determine what intelligence knows, what it may do, and whether anyone can tell that it did the job correctly.
The same test points downward, to the memory a model lives in, the bandwidth it moves through, and the energy it consumes.
Intelligence is becoming abundant. Scarcity is not disappearing. It is moving.
The views and opinions expressed here are those of the author alone and are based on publicly available information. They do not constitute investment advice, a solicitation, or a recommendation to buy or sell any security or financial instrument. The author and Decoding Discontinuity may hold positions in the securities of companies mentioned. Certain companies referenced may be current or former clients of, or counterparties to, the author or affiliated entities; such relationships will be disclosed where applicable. The author maintains no current position in Anthropic, Harvey, or any private entity discussed. Past performance is not indicative of future results. Readers should conduct their own independent due diligence and consult a qualified financial advisor before making any investment decision.