The Agentic Harness: Why the Model Is the Commodity and the Harness Is the Asset

An agentic harness is the control layer around a model: the code that decides where work happens, what the agent may touch, what leaves the machine, and what gets recorded. It is everything in an agent system that is neither the model nor the task, and it is the part that survives when you change models.

That definition matters because of a pattern you have probably lived through. You have switched primary models at least once in the last year. Possibly three times. Each time, something predictable happened: the new vendor shipped its own command-line tool with its own dialect, its own session format, its own way of asking for approval, and its own idea of what finished looks like. You wrote an integration. It worked.

Then a better option landed somewhere else, and that integration was the reason you did not move for six weeks.

This is the most expensive pattern in agent engineering right now, and it has a clean diagnosis. The part you actually needed never changed. What changed was the part you tangled it up with.

What an agentic harness actually contains

Strip out everything vendor-shaped and look at what is left. In almost every agent system worth running, three things stay constant regardless of which model is behind them.

Somewhere to put the work that cannot touch anything real. A place the agent operates that is not your branch, not your production database, and not your machine. This is a decision about your environment, and it does not become obsolete when a better model ships.

A gate before anything leaves. One place where a proposed action is checked before it becomes a side effect. What that gate permits is a policy question about your organisation, and no vendor has an opinion about it worth adopting.

A record of what happened. Not log lines. What the agent saw, what it chose, what it did, and how the run ended. This is the only thing that makes a failure diagnosable weeks later, and it is the raw material for every evaluation you will run.

None of those three mention a model. That is the point. They are answers to questions about your systems, and those questions have the same answer next quarter.

Why this is happening now

Two trends are running in opposite directions, and the gap between them is where the work has moved.

Capability per dollar keeps falling, and it falls across vendors at once. Open models keep closing on closed ones: as of August 2026, an open-weights model like Kimi K3 sits close enough to the frontier that choosing it is a normal engineering decision rather than a compromise you have to defend. The practical consequence is that the model is becoming something you pick in an afternoon and change again later, which is exactly how you already treat a database driver.

That example is deliberately dated, and it will age. Name whichever model is in that position when you read this; the argument does not depend on which one it is, and if it did, the argument would be wrong.

At the same time, models stay uneven. One is better at long terminal work, another at maths, another at staying inside a schema. Reliability has not converged at all, and no current model is trustworthy enough to be given an unsupervised credential and left alone.

Put those together and the conclusion is not subtle. When the thing in the middle is cheap, interchangeable, and individually unreliable, the engineering value moves to the layer that decides how it is used. Trust has nowhere else to live.

The line that decides how long your harness lasts

There is one design decision that separates a harness you keep from one you rewrite, and it is about what is configurable.

Make everything tunable and you have built a system that can widen its own cage. Make nothing tunable and you have built something nobody can adapt to a new task without a deploy.

The split that works: thresholds, budgets, prompts, routing rules and model choice all live in configuration, because those are the things a team genuinely needs to change weekly. What the agent is permitted to touch, what requires a human, and what can never happen at all live in reviewed code. A harness that can retune its own thresholds is adaptive. A harness that can retune its own permission boundary is a liability with good ergonomics.

If you take one rule from this piece, take that one. It is also the sentence that makes an interviewer sit up, because it demonstrates you have thought about the failure rather than the feature.

How to build an agentic harness without over-building it

Three practical consequences follow.

Keep the seam thin. The surface where your system touches a model should be small enough to rewrite in a day: send a request, get a decision, run a tool, return a result. Everything else sits behind that seam and knows nothing about which vendor is on the other side. When you can describe your model integration in one paragraph, switching costs an afternoon.

Do not build all of it on day one. Isolation and the permission gate are cheap early and painful to retrofit, because adding them later means auditing every call site you have already written. A full ledger can wait until you have something worth debugging. Anyone telling you to build eleven components before your first working agent is describing a finished system, not a starting point.

Use a framework for the boring half. Tool binding, schema generation, retries and checkpointing are identical in every agent system, and writing them yourself is not a differentiator. Which agents exist, when one hands to another, and what stops a run are your product. Let a framework own the first category and keep the second, and you have a boundary you can defend in a design review.

The agent framework question in interviews

This topic has arrived in interviews faster than most, and it is usually asked badly and answered worse. The question sounds like "what agent framework did you use". The weak answer is a name. The follow-up, which is the actual question, is "what would you keep if you moved off it".

A strong answer sounds like this. The model is the part I expect to replace. The harness is the part I expect to keep, so it holds isolation, the permission boundary, the approval gate and the trace. I let the framework own tool binding and retries because those are the same everywhere. I would reconsider if our routing logic stopped fitting its graph model, because at that point I would be writing adapters to fight it.

That answer works because it is a boundary rather than a preference, and because it names the condition that would reverse it. Our Agent Engineering course builds the whole thing in order, and the lesson on judging a framework is this argument at full length, with the six problems every framework has to solve.

If you want the pieces individually: least privilege for agents is the permission boundary, the run is the unit is the trace, and build versus buy is the decision under interview conditions. The agent design patterns concept is the vocabulary underneath all of it.

Build for the model you will have

Building for the model you have today is the same mistake as building for the browser you have today, and it was a mistake then too.

The harness is not glamorous. Nobody demos a permission boundary. But it is the part of an agent system that is still yours after the model underneath it has been replaced twice, and on current evidence it will be replaced twice. Build accordingly.