The harness does half the thinking

Swap the model behind a coding agent from one frontier lab to another and you will feel a difference. Swap the harness (the tools it holds, how their results come back, the permission rules, the words of the system prompt) and you will feel a bigger one.

The harness is everything around the model that decides what it sees and what it can do. Teams pick a model in an afternoon and then spend months blaming it for failures that belong to the wrapper.

Small choices, large effects

A search tool that returns whole files buries the agent in text; the same tool returning matched excerpts lets it stay on task. A tool that hands back a file path costs a hundred tokens; the same tool pasting the file’s 60k characters costs the session its memory.

How a failure comes back matters as much as whether it happens. A denied action that returns “the user declined this, adjust your approach” produces a smarter next step than one that fails silently and lets the agent retry the same thing three times. Permission modes, hooks that catch a bad command before it runs, tool schemas that load only when a tool is actually needed: none of these change the model’s weights, and all of them change how the agent behaves.

The model is a component

That is the reframing that saves teams the most time. The model is one part. The harness is where you decide how that part gets used, what it is shown, and what it is allowed to touch.

Most agent reliability is won or lost there, and almost none of it makes the headlines. When an agent misbehaves, the honest first question is rarely “is the model good enough.” It is “what did we hand it, and in what shape.”