The usual way that people look at the agent life cycle follows a temporal order: pretrain, midtrain, posttrain. And then, almost as an afterthought, the harness comes. First you train the model, then you build the harness.
However, in this post we will argue that the harness and pretraining, the two ends of the pipeline, are secretly holding hands. And this comes in two directions:
- From a training point of view, the harness defines what trajectories the data flywheel collects, and therefore what the next pretraining run eats.
- From an agent deployment point of view, pretraining is a nonperfect statistical approximation of intelligence. And harness has to come to the rescue to correct the bad instincts that pretraining baked in.
In this post, I will explore some of the ideas that have been going around my head :
- Harness might need to be designed before RL. And once the harness is ready to be shipped, the data flywheel can take over and scale with users trajectories.
- Current pretraining bakes in biases like “my context is correct” This makes them powerful prediction machines but breaking them for better outcome is manual work done in the harness.
- There are two ways to fix these biases: encode the correction in the harness, or distill rational human actions into the weights. They look like rivals, but the flywheel connects them — the harness fix comes first because it generates the data the distillation fix needs.
I use “harness” in the same sense as my ICLR reflections post: the layer that determines the format of inputs to the model checkpoint — context layout, tools, subagent structure — as opposed to the environment, which determines the content.
Harness → Pretrain
The Data Flywheel
Let’s first go through what a data flywheel is. The very defining precursor is Tesla FSD. Although the self driving technology was not perfect in the beginning, every car is a data-collection device: when the driver intervenes or disengages, the moment could get flagged and folded into the next training run. Deployment produces data, data produces a better model, a better model justifies wider deployment. The product is part of the data pipeline.
Coding agents run the same loop. Claude Code and Cursor sessions produce trajectories. All the context the model saw, and all the user interactions could be used in future training. Filter for the good or successful trajectories and you have SFT data that works on top of your existing agent plus harness.

The Harness Completes the Flywheel
What completes the flywheel is that the harness is not just where the model acts; it is also where future training data gets generated. Once the agent is deployed, every good session can become more training data for the next model.
Compare this against RL as a way of improving the same agent:
- Benefit: every user session is a candidate, and training remains relatively simple without the need to tune fragile staleness or prepare complex RL infrastructure.
- Downside: it needs users first, so a weak cold-start agent may not generate useful trajectories since users would not use it at all.
Thus one role of RL is to help the agent become good enough for people to use once new capabilities are added, especially before a new harness becomes generally available to the public. The flywheel can then scale with user data. RL bootstraps and disciplines; the harness is the flywheel.

The Harness Lock-In Dilemma
The flywheel is more of a known fact for people in the AI space. However, this flywheel has a consequence I have not seen discussed much. Once you commit to a harness, all your user data is shaped by it, and training on that data might lock you in further. Trajectories is limited to the context management method that the harness uses. SFT on them makes the model better at that harness, which makes the harness harder to change, which makes the next batch of data even more harness-specific.
How well training on harnesses generalizes is genuinely unclear. If a lab trains for two years on trajectories from harness A and then wants to ship harness B, how much capability transfers?
Lots of interesting future work fits here: measuring transfer across harnesses, or designing harnesses whose data stays maximally reusable. A small design decision made early compounds into billions of dollars worth of training data being either portable or stranded.

Pretrain → Harness
Bias in Pretraining
The reverse link starts from a fact about pretraining method: we teach the model that what the context says is correct and you should say more. This actually transfers a hidden bias into the model: it is trained to trust its context.
So if I write “The earth will explode in 2030” in the context, the model will treat it as true since there should be little contradicting evidence in the corpus. Not because the model is gullible, but because it was trained to believe in previous context. Well, people can argue that the above example can be fixed by some alignment post-training, but the bias are more subtle than that. We will see a more subtle example below
Imagine this: you asked a model for a CUDA kernel, and at some point it wrote a Triton version. From then on it will continue in Python essentially forever, even if CUDA is faster. Why? I argue that because in pretraining data, a file that is half Python is almost certainly all Python. It is a Python file! Language-switching mid-document is vanishingly rare in the corpus, so once the trajectory enters Python, the prior for staying there is overwhelming. The model isn’t being stubborn; it is doing exactly what next-token prediction on real files taught it to do.
Can we post-train it to not follow this pattern? SFT on a handful of corrected trajectories might not be enough. RL can actively suppress the wrong continuation, not just add rare positive examples; but with such a dominant prior, it may still take many rollouts before the penalty signal wins since correct demonstrates will come very rarely.
The Symbolic Layer above Pretraining Reflexes

There is a useful analogy from scuba diving. A panicking human’s reflex underwater is to hold their breath and bolt for the surface, which is exactly what ruptures your lungs. So divers are drilled on one explicit, symbolic rule: never hold your breath, ascend slowly. The rule does not remove the reflex; millions of years of evolutionary “pretraining” put it there and it is not going anywhere. The rule sits on top of the reflex and overrides it at the moment it fires.
That is what the harness is: the symbolic layer on top of the model’s reflexes.
For examples, as this blog on why humans don’t just sample, humans beat AI at long horizon tasks by leveraging a great symbolic-layer skill: we are good at forgetting and restarting. When an approach seems to be in the wrong direction, we walk away and come back with a fresh view. Models, on the other hand, sample forward: failed attempts stays in context and keeps biasing the next token. But the model doesn’t need to learn this. We can add it manually: context cleaning, spawning subagents, a harness rule that says “after two failed attempts, restart from scratch instead of patching.” Each is an explicit override of a pretraining reflex — the diver’s breathing rule.
This raises the question: where should human problem-solving strategies live - in the harness or in the weights?
Solution 1: encode the correction in the harness. Find a way to make strategies explicit rules: compact the context, spawn clean-context subagents, restart after two failed attempts. These rules can be dynamically determined by another action model and we only need to train a much smaller action model.
Solution 2: distill rational human actions into the weights. Train on trajectories where humans starts to affect the model: for example, a session that switches from Triton back to CUDA halfway because engineer prompted it to. Given enough of these, the model knows that it should change languages. Meta seems to be following this approach with the new AAI organization. This method aligns more closely with what LLM training has been carried out, but the problem is that training >1T parameter model on these rare trajectories could be difficult. And the flywheel might just be spinning too slow.

I would personally favor the first solution, because it is the one that works today and might be much more efficient to implement. But the second solution already proved its scalability. It remains unclear how we can scale up training on the harness.
Conclusion
The harness and pretraining are holding hands in both directions: the harness decides what data the flywheel feeds into the next training run, and pretraining bakes in reflexes that only the harness can override. The harness is both the corrective layer and the data generator. Maybe if the flywheel spins fast enough, agents can eventually become a superset of humans.
Acknowledgement
We thank Qizheng Zhang for the feedback on the initial draft of the blog. This blog is not a reflection of employer values. Just some random thoughts that I tried to put together in free time.
