Your Company Should Train Its Own AI Models - Will Brown, Prime Intellect

An org chart tells you who reports to whom. An experienced employee also knows whose support gets a change adopted, which mandates tend to stick, and where work gets held up. For Will Brown, who leads applied research at Prime Intellect, that gap matters when agents move from individual assignments to work that spans an enterprise.

A startup can already use Claude Code throughout development. Brown’s question is what happens when a company wants an agent to gain experience over its time on the job. Prime Intellect builds infrastructure for training and deploying open models in a company’s own harness, the software that gives an agent tools and directs its work. A company could keep using frontier models while teaching an open model the parts of the job its own people know best.

Some of that experience leaves a trail in code, email, and meeting notes. Several teams might keep running into the same delay while another has quietly found a way around it. An employee who sees only one team’s work has little reason to know the problem is already solved. An agent that can read across those records could connect the teams. The harder question is how the next agent doing the job gets the benefit of that discovery.

Give a coding agent a skill file and access to a repository, and it can work out quite a lot during a session. Start the workflow again and the agent may have to read the same instructions and explore the same code. Caching can lower the cost of repeated input. Even with a good cache hit rate, the workflow still depends on supplying that background each time.

Company knowledge falls on a spectrum from rules to patterns. A required step can live in code or a skill file someone can edit. A preference that depends on the circumstances is harder to spell out. So is a recurring point of friction that employees have learned to anticipate. When the same judgment comes up across many tasks, those examples make a case for training. Changing the model’s weights gives the examples a way to influence later sessions without putting them all back in the prompt.

How might a frontier model learn to use a particular combination of Salesforce tools? In Brown’s hypothetical, a former practitioner takes work through an expert network and explains the workflow. Someone at the network passes that account to a builder, who turns it into a reinforcement learning environment where a model can practice the task. A lab might buy that environment and have a researcher refine it for the next training run. By then, the person who knows what competent Salesforce work looks like has little say in the exercise the model actually attempts.

A developer correcting a coding agent has a shorter route. In one interaction, the developer sees the situation, the action the agent took, and the alternative they would have preferred. Adding a line to AGENTS.md makes sense when the correction applies as a rule. Do that for every exception and the file itself becomes a refactoring job. Keeping a correction with its circumstances gives a trainer an example of when the alternative was better.

Skills and memory still belong in the harness, and tools can retrieve facts from files or databases. The benefit Brown wants from training is fluency. Think of asking a model about the six months of news after its knowledge cutoff. You can bring it up to date in one conversation, then face the same job in the next. Older events take much less introduction. Brown wants a company’s model to develop that kind of familiarity with the setting in which it works.

A team can start before it has a training run in mind. Treat the model like a codebase and add a test case when real use exposes a behavior worth checking. A trace records the prompt, what the agent did, and any feedback the user gave. The prompt can supply a future test input. A correction can tell the evaluator what to look for in the next attempt. Curating those cases by hand takes work, which is why Brown sees a role for agents in selecting and preparing them.

Two decisions lend themselves to this approach because the team can identify the judgment it wants to learn.

• Which model should handle this task? Give the same assignment to a large model and a cheaper, smaller one. Have a person or another agent judge whether the smaller model did as well. A match gives the router in the harness evidence for sending more tasks of that kind to the cheaper model.
• What would the employee approve? Approving a tool call in Claude Code is a familiar example of judging a proposed action. A company also has decisions that depend on its own practices and preferences. Pair the situation and proposal with the employee’s choice, and a decision model has a target for predicting how that employee would judge a similar case.

For a long-running agent, one approval captures only a moment of the job. Prime Intellect also works with teams that have many traces from a high-volume production workflow. The traces establish which tasks users actually attempt. Agents, equipped with tools and human guidance, can help curate those records and combine real and synthetic material into environments where a model can practice the longer workflow. Verifiers, Prime Intellect’s environment and evaluation library

One bot is easy to follow until you want a second one. With 20 bots running, finding the thread that needs an answer becomes a job of its own. Merging everything into one stream still leaves a person hunting through messages for the question. Brown has been experimenting with another interface. Let agents run with an idea. When an agent reaches a decision that needs a person, it can write a small, task-specific card on the fly.

What does the card capture that is hard to recover from a long thread? It brings the decision the agent needs together with the person’s answer. The person can respond directly, and the response doubles as a label for that particular question. The agent still has to judge when an interruption is worth making.

A model learning to predict that choice has an explicit target. That reduces reliance on a proxy reward the model might learn to game. The company could train just the model that handles approvals or coordinates other agents. A frontier model could continue doing much of the underlying work while the company teaches the component where its own preferences matter.

Brown reports that a company using Prime Intellect tooling spent about $300,000 training a model for knowledge work such as spreadsheets and slides. He places the model near the Pareto frontier for that work, though he gives no benchmark scores or comparison axes to quantify the tradeoff. His budget comparison is easier to grasp. A run at that price is a decision on the scale of hiring a software engineer. A team could also spread its training investment over time as examples accumulate.

What would a person need to see before committing compute tonight? In an internal Prime Intellect prototype, the team collects traces from its agents. A person can inspect the issues flagged in those traces, review a proposed experiment, and decide whether to start the run. The issues explain why a behavior deserves attention. The proposal lets the person judge whether this experiment is worth trying.

The overnight schedule depends on how employees use the agents. During the day, inference capacity serves their requests. If demand drops at night, the company could put some of that capacity toward training. A change in the weights could then carry a correction into future sessions, including sessions with employees who never saw the original mistake.

In Brown’s sequence, a company first discovers the workflow, writes skills for the steps it can specify, builds evals, and learns which tasks it can route. By the time it considers regular training, it has more than a collection of company documents. It has examples of where its agents struggle, judgments from people who know the work, and test cases for seeing whether the next model handles it better.