ExpertsFMA Model For Everyone: How Ronak From Trajectory Is Building Products For Continual Learning
Training Data · November 5, 2026
5 Selected Lessons:
reasoning_pattern · 3 case · 1 heuristic · 1
Redefine the unit of work to match economic value, not surface metric
Source
Training Data — A Model For Everyone: How Ronak From Trajectory Is Building Products For Continual Learning (November 5, 2026) · at 8:55 ▸
When this applies
when an industry has defaulted to measuring a convenient but shallow metric (e.g., time, words, clicks) instead of the actual unit of value delivered
The takeaway
Choose your unit of measurement/optimization to match the unit of value you actually want to produce, not the unit that's easiest to count.
Why it works
Tokens measure computation, not completed economic work; reframing the unit of work as a 'trajectory' (task) aligns measurement, incentive, and training objective with actual value delivered.
One level up
Naming conventions shape what gets optimized — pick names/units deliberately to steer a field's attention.
Where it stops holding
This stops working when the 'task' unit is too coarse or ill-defined to be consistently measured or compared, making tokens the only tractable proxy.
Detail
approach: Identify the shallow default metric the field uses (tokens), compare it to how humans actually judge work (task/trajectory completion), and redefine the system's unit of optimization accordingly.
signals:
- metric that's easy to count but doesn't map to value (tokens)
- humans naturally talk in terms of tasks, not sub-units
rationale: In RL terms this maps rollouts to real economically valuable trajectories, and lets companies 'own that path' and define their own notion of value.
In their words
And now suddenly your trajectories are the tasks of economic value that are happening. And so I want this basically paradigm to propagate where the unit of work that we think about is a trajectory.
The product builder as gardener: set trellises, let the system grow autonomously
Source
Training Data — A Model For Everyone: How Ronak From Trajectory Is Building Products For Continual Learning (November 5, 2026) · at 26:10 ▸
When this applies
when managing any system capable of autonomous self-improvement, where the manager's job shifts from direct control to shaping constraints and direction
The takeaway
As systems gain the ability to self-improve from their own operating data, redefine your role from direct controller to designer of the boundaries and direction within which the system grows itself.
Why it works
Once a system can learn from its own traces of use (model, then harness, then company), the human's leverage point moves from specifying every output to designing the structural constraints ('trellises') that shape autonomous growth.
One level up
Increasing system autonomy shifts human value-add up a level of abstraction — from doing/deciding to shaping constraints and taste.
Where it stops holding
This stops working when the self-improving system lacks sufficient guardrails or a reliable success signal, in which case unmonitored growth could drift away from intended goals (echoing the RSI-vs-continual-learning alignment concern).
Detail
approach: Start by enabling self-improvement of the model; extend it to the harness; eventually the product/company. Meanwhile the product builder's job becomes setting structural guardrails ('trellises') and letting growth happen autonomously within them.
signals:
- product has enough trace data and reward signal to self-improve
- harness becomes 'most of the product' for AI-native companies
rationale: Ronak frames this explicitly as an 'exciting world' companies 'should start building towards,' marking it as forward-looking vision rather than achieved state.
In their words
I think there, then products and product builders start to become almost like a gardener. Like you have your plant and it's going to grow autonomously on its own. And your goal as a product builder is to basically just set these trellises in the ground of here's where I want to shape my product.
No single company can build the whole stack — map the ecosystem of adjacent infra bets
Source
Training Data — A Model For Everyone: How Ronak From Trajectory Is Building Products For Continual Learning (November 5, 2026) · at 26:10 ▸
When this applies
when evaluating a new technology wave to decide which layer of the stack to build in, versus which layers to rely on others for
The takeaway
When evaluating where to build in an emerging technology stack, identify the full set of infrastructure layers required, and deliberately choose to own only the highest-leverage layer rather than trying to build everything.
Why it works
Complex new capabilities (like continual learning) require multiple specialized infrastructure layers (sandboxing, training, product interface); recognizing this lets a founder focus on the highest-leverage layer and trust the ecosystem for the rest.
One level up
Healthy new technology paradigms emerge from an ecosystem of specialized companies, not one company vertically integrating everything.
Where it stops holding
This stops working when no other company is willing to build the adjacent necessary infrastructure, forcing vertical integration regardless of preference.
Detail
approach: List out needed infra layers for the paradigm (sandboxing/compute, training algorithms, product interface) and identify which one is the highest-leverage place to focus.
signals:
- multiple companies physically/competitively clustering around the same emerging paradigm, each owning a different layer
rationale: Ronak explicitly says Trajectory is 'not the only company in the ecosystem that needs to work really well' and names Modal and Thinking Machines as complementary bets.
In their words
And two blocks down from that is thinking machines, also in SF. And I think there's like all these sort of companies that need to be built to basically power all the infrastructure to make continual learning work.
Route 90% of tasks to a cheap trained model, reserve the frontier model for the hard 10%
Source
Training Data — A Model For Everyone: How Ronak From Trajectory Is Building Products For Continual Learning (November 5, 2026) · at 16:17 ▸
When this applies
when you have both a general-purpose expensive resource and a specialized cheap resource and must allocate work between them
The takeaway
Reserve your most expensive, general-purpose capability for the minority of genuinely novel cases, and route the high-volume repetitive majority to a cheaper specialized resource.
Why it works
A specialized model trained on thousands of repetitions of a narrow task becomes cheaper, faster, and sufficiently reliable for that bulk of volume, while genuinely novel or hard cases still need the generalist's broader capability.
One level up
Economic efficiency in any system comes from matching resource cost/capability to task difficulty distribution, not uniform allocation.
Where it stops holding
This stops working when task difficulty can't be reliably predicted in advance, making routing decisions themselves error-prone or when the specialized model hasn't seen enough volume to be trustworthy yet.
Detail
rule: Use a frontier model for roughly 10% of tasks (the hard/novel ones) and a trained specialized model for the other ~90% (the repetitive bulk) to capture margin and efficiency.
threshold: Explicitly stated ratio: 'a frontier model like [Fable] for 10% of tasks, and then for 90% of the time, you can smartly route to a model that you've trained.'
rationale: The trained model has 'seen a task a hundred times or a thousand times over,' making it faster, cheaper, more reliable for that volume.
In their words
And so the eventual world is maybe you use a frontier model like Fable for 10% of tasks, and then for 90% of the time, you can smartly route to a model that you've trained that is far more efficient and also gets you better margins.
Harvey legal model: 6x cheaper, 4%→18% accuracy via domain data
Source
Training Data — A Model For Everyone: How Ronak From Trajectory Is Building Products For Continual Learning (November 5, 2026) · at 5:56 ▸
When this applies
when a domain expert company has unique proprietary data/expertise but is dependent on a generic third-party model that can't leverage that edge
The takeaway
When you have unique, hard-won domain data and a way to turn it into training signal, you can beat generic frontier capability on cost and task-specific accuracy simultaneously.
Why it works
Training a custom model on a company's own expert-labeled benchmark and production data lets the company convert its accumulated domain expertise into model performance that a generic frontier model cannot replicate.
One level up
Owning your data and training pipeline converts accumulated domain experience into a defensible, differentiated capability ('shaping your own destiny').
Where it stops holding
This stops working when the domain lacks enough proprietary labeled data or a usable benchmark to meaningfully out-train a frontier model.
Detail
situation: Harvey had 30 years of accumulated legal domain data/expertise but was limited by relying on frontier closed-source models that couldn't use that data.
decision: Harvey built its own legal agent benchmark from expert data and used Trajectory to train a custom model on it.
outcome: The trained model was six times cheaper than frontier models and improved accuracy from around 4% (open source baseline) to around 18% on their benchmark, with room to grow.
lesson: Proprietary domain data plus a training pipeline can convert expertise into a model that's both cheaper and more accurate than generic frontier alternatives for that specific task.
In their words
So, with Trajectory, what they were able to do is train a model that is six times cheaper. And it goes from around 4% accuracy for an open source model to around 18%.