Does the Harness Come Before Pretraining? A Data Flywheel View

This piece challenges the standard sequential view of agent development (pretrain → midtrain → posttrain → harness), arguing that harness design and pretraining are tightly coupled in both directions. The harness — context layout, tools, subagent structure — isn't just where a model acts; it's also where future training trajectories are generated. User sessions get filtered into SFT data, which improves the model on that specific harness, which in turn locks the system deeper into that harness's conventions. This creates a real engineering risk: switching harnesses later may strand years of accumulated training data if capability transfer turns out to be limited.

The reverse dependency comes from a pretraining artifact: models learn to treat context as trustworthy, which makes them powerful predictors but also biases them in subtle ways — such as continuing in the wrong programming language because mid-document language switches are vanishingly rare in training corpora. Using a scuba-diving analogy (overriding the panic reflex with an explicit 'ascend slowly' rule), the author frames the harness as a symbolic layer that overrides these baked-in reflexes at inference time, rather than something SFT alone can easily unlearn.

For engineers, this reframes a practical design question: should behavioral corrections live in harness rules or be distilled into model weights? The proposed path is to use RL to bootstrap a harness good enough for real users, then let the data flywheel scale from there — with harness design decisions made early having outsized, compounding effects on data portability.