Watch how experienced developers talk about coding agents now and you notice something: they have stopped arguing about which model is smartest. The frontier models are all good enough. What they argue about instead is everything wrapped around the model — how it gets repo context, which tools it can touch, where one agent's job ends and another's begins. The interesting work has migrated from the model to the harness.

This is a meaningful shift. A year ago the question was "can the agent write this function." Now the agent can. The questions that remain are operational: how does it see the real codebase without you pasting files every session, how do you stop it from wandering into systems it should not touch, and how do you keep work moving when the account running the agent gets interrupted. None of those are model problems. They are harness problems.

Context is plumbing, not intelligence

The most common complaint is mundane: every session starts by feeding the agent the codebase again. People build entire bridges — MCP servers, sync tools, custom loaders — for the sole purpose of giving the agent durable access to repo context it should never have lost. That effort is a tell. If developers are building infrastructure just to keep the model oriented, the orientation problem is more valuable to solve than another point of benchmark score.

Real repo context is plumbing. It is not glamorous and it is not intelligence, but it is the difference between an agent that understands your architecture and one that confidently invents an endpoint that does not exist. The model supplies the reasoning; the harness has to supply the ground truth, reliably, without a human re-priming it every morning.

Boundaries are a feature, not a limitation

The second thing advanced users build is restriction. Custom hooks. Tool allowlists. State machines that constrain which tools fire in which order. Sub-agent boundaries so a context-collecting agent cannot start editing files. From the outside this looks like fighting the agent, but it is the opposite — it is what makes the agent trustworthy enough to run with less supervision.

An unbounded agent is exciting for a demo and exhausting in production, because you have to watch it. A bounded agent — one that physically cannot deploy, cannot touch the migration, cannot exceed its lane — can be left alone, because the harness guarantees the blast radius. The skill being built here is not prompting. It is drawing boundaries the model cannot cross, and that is a property of the harness, not the model.

Evidence is what survives the session

There is a third capability that keeps surfacing: stitching evidence together across logs, metrics, chat, and tickets. A long-context model finding a root cause that took a human team many hours is impressive, but the durable value is not the single answer. It is the trail — the assembled record of what was checked, what was found, and why the conclusion holds. That trail is what a teammate reads tomorrow, and it is the harness's job to capture it, because the model forgets the moment the session ends.

An agent that solves a problem and leaves no evidence has done half the job. The half that matters for a team — the reviewable record — lives in the layer around the agent.

Plan for the account getting cut off

The least discussed harness requirement is resilience to interruption. Hosted AI accounts get rate-limited, flagged for verification, or blocked mid-task, sometimes for reasons that have nothing to do with the work. When that happens, an agent with no local state simply stops, and whatever it understood evaporates. A harness that keeps context, history, and run-state locally lets the work survive the account, instead of dying with it.

This is the unromantic reality of building on top of someone else's model: your access is conditional, and the harness is your insurance against that condition changing without warning.

The model is the easy part now

Put these together and the conclusion is hard to avoid. Context, boundaries, evidence, and resilience are all properties of the layer around the agent, and all of them matter more, day to day, than which model you picked. The model is the commodity. The harness is the product. The developers building custom MCPs and hooks already know this — they are just building privately what the tooling has not yet handed them.