Harness
A better doer needs a better harness.
The model is only one part
A capable model still needs a place to work
Imagine giving two people the same excellent power tool. One has the measurements, the right attachments and a clear safety line. The other has an empty bench and a vague instruction. The tool is identical. The useful result is not.
AI works much the same way. A model supplies language, reasoning and the ability to choose a next action. A harness is the working environment around it: the relevant information, tools, permissions, checkpoints and memory that help those actions stay pointed at the goal. The practical inference is simple: as a model becomes more capable of taking action, the environment in which it acts becomes more consequential.
Capability and control multiply each other
A stronger model can attempt harder work. A stronger harness makes the attempt safer and more repeatable.
Model contribution
- Reasoning and generation Produces candidate decisions, code and explanations.
- Tool use Can choose and operate available tools.
- Generalisation Transfers patterns to unfamiliar tasks.
neither is sufficient
Harness contribution
- Relevant context Supplies evidence and standing constraints.
- Authority boundaries Limits tools, writes and external effects.
- Evaluation Tests claims before they become accepted work.
The highest-leverage upgrade may be the weakest side of the pair.
Start with the smallest useful rig
Give it a goal, a boundary and a way to check the work
A harness does not need to begin as an elaborate platform. The minimum useful version has three layers. First, give the model the goal, the relevant context and the constraints that define a good result. Second, give it only the tools and permissions the task requires. Third, make the work pass through a check before it can be called complete.
Add memory when a task must survive more than one session. Add a plan when several decisions depend on one another. Add approval gates when an action is costly or difficult to reverse. Each layer should answer a real failure you have observed. More machinery is not automatically safer: a bloated harness can bury the important context, slow the work and preserve a bad assumption with impressive consistency.
A worked example
The same request becomes a different job
Take a hypothetical request: “Let customers cancel a subscription from their account page.” A bare agent can inspect the code and produce a plausible button. It may still miss the business rule that access continues until the paid period ends, the requirement to record who cancelled, or the email that support expects to be sent.
Now put the same model inside a modest harness. The context includes the cancellation policy and the few relevant files. Its tools can search the codebase and run tests, but cannot deploy to production. The plan must name the user-visible states before implementation. A test checks that access remains active until the correct date. A final approval gate asks a person to inspect the account state and customer message.
The model still contributes the reasoning and code. The harness supplies the evidence, boundaries and sequence. The human operator decides what the policy should be, which risks matter and whether the result is acceptable. None of those parts replaces the others. Together they turn a plausible answer into controlled work.
Where results begin to separate
Same engine, different conditions for judgement
Two operators can therefore get different results from the same model without either result being mysterious. One keeps the task inside a useful amount of context and notices when it approaches a degraded working zone. Their setup can preserve the important decisions before compacting, applies deliberate context choices, and uses compressed output only when brevity will not remove needed detail. The other may provide more material but fewer signals about what matters.
The harness is not the entire difference. The model's underlying capability still sets a ceiling. The operator's judgement still determines the goal and catches failures the checks did not anticipate. Domain knowledge, data quality and simple luck also matter. Harness engineering is valuable because it improves the controllable conditions, not because it guarantees a correct result.
Same engine, different operating system
The harness changes what the model can see, do and prove.
Bare interaction
- One prompt Intent lives in a transient message.
- Unbounded answer No explicit authority or stop rule.
- Plausibility review The output is judged mainly by reading.
add operating structure
Controlled workflow
- Task plus evidence Primary sources and current state are selected.
- Tools plus boundaries Allowed actions and escalation are explicit.
- Executable proof Tests, diffs and live checks can reject the answer.
A better harness does not make errors impossible. It makes them easier to detect and contain.
The practical next move
Fix the repeated failure before adding another layer
Start by watching one task fail. Did the model lack a fact, use the wrong tool, forget a decision, act beyond its authority or declare success without checking? Repair that specific gap with the smallest durable layer. Then run the task again and see whether the failure actually changed.
That is the student lens I find most useful here: treat the harness as a record of what the work has taught you. The professional test is whether it makes outcomes easier to inspect, maintain and reverse on Monday morning. The human test is whether it returns attention instead of demanding more of it. A better harness is not the one with the most parts. It is the one that helps a capable model do useful work while leaving responsibility where it belongs.