What If the Harness Comes Before Pretraining? A Data Flywheel Perspective | Hanchen's Space BarTable of ContentsHarness → PretrainThe Data Flywheel<br>The Harness Completes the Flywheel<br>The Harness Lock-In Dilemma

Pretrain → HarnessBias in Pretraining<br>The Symbolic Layer above Pretraining Reflexes

ConclusionAcknowledgement

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.<br>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:<br>From a training point of view, the harness defines what trajectories the data flywheel collects, and therefore what the next pretraining run eats.<br>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.<br>In this post, I will explore some of the ideas that have been going around my head :<br>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.<br>Current pretraining bakes in biases like &ldquo;my context is correct&rdquo; This makes them powerful prediction machines but breaking them for better outcome is manual work done in the harness.<br>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.<br>I use &ldquo;harness&rdquo; 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.<br>Harness → Pretrain#<br>The Data Flywheel#<br>Let&rsquo;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.<br>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#<br>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.<br>Compare this against RL as a way of improving the same agent:<br>Benefit: every user session is a candidate, and training remains relatively simple without the need to tune fragile staleness or prepare complex RL infrastructure.<br>Downside: it needs users first, so a weak cold-start agent may not generate useful trajectories since users would not use it at all.<br>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#<br>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.<br>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?<br>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#<br>Bias in Pretraining#<br>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...