The model I built a workflow on last quarter is already on a deprecation schedule. A lab I don’t own, on a timeline I didn’t set, decided that. The replacement is better on every benchmark and behaves differently on the three prompts I actually cared about, so I get to re-tune work that was finished.

That is not a complaint about model velocity. It is the whole point. You never owned the model. You rent it, month to month, from a vendor who reprices and deprecates on their schedule, not yours. The only part of the stack you actually own is the harness you wrapped around it. And almost everyone is pouring their attention into the one layer they can’t keep.

The model is the rental; the harness is the deed

An agent is two things: a model that reasons, and a harness that decides what the model sees, what it can do, and how its work is controlled. The reasoning is rented. Everything else is yours to build.

The harness is the layer sitting on top of whatever model you chose: global rules, skills, MCP servers, codebase search, hooks, and sub-agents. Most of those are Anthropic primitives you assemble rather than invent — MCP, skills, hooks, sub-agents — and “harness engineering” is the name the community has settled on for assembling them well. Karpathy named the broader discipline “agentic engineering” at Sequoia’s AI Ascent, and the phrase that stuck with me from the practitioners is “Claude Code is the floor, not the ceiling.” The out-of-the-box agent is a great place to start and a terrible place to finish, because the floor is the part the vendor controls and the ceiling is the part you build.

Here is the test that makes the ownership line obvious. When the next model ships, what survives? Your prompts get re-tuned. Your model choice gets re-evaluated. But your rules, your skills, your hooks, your retrieval layer, the control flow that orchestrates all of it, those carry over to the new model with minor adjustments. The harness is the asset with continuity. The model is the component you swap.

I argued in Prompting Split Into Four Skills that scaffolding survives while skills applied by hand do not. This is the sharper version of the same claim: scaffolding does not just survive, it is the moat, and it is the moat precisely because the thing it wraps is a depreciating rental.

The part that is genuinely new

Most of harness engineering is context engineering under a newer name — the relabeling Tobi Lütke proposed and Karpathy defined — and I have written about that layer already. The one component that is actually new is control flow.

A single agent session drowns. Too many tokens, too broad a scope, and the model degrades no matter how good your rules file is. The answer is to stop running one long session and start orchestrating many narrow ones. Geoffrey Huntley’s ralph loop is the clearest expression: feed a large specification, split it into tasks, run one agent session per task, append to a log as each completes, and exit only when a done condition and every validation check pass. You do not babysit it. You define the exit condition and the loop runs.

That is the shift the discourse keeps underselling. You are no longer the engineer who writes the feature. You are the engineer who builds the system of agents and code that writes the feature. The harness is where that system lives, and control flow is the part of it that no chat window and no prompt library gives you.

Context is code, so treat it like code

The fastest way to watch a good harness rot is to let its context drift. Dru Knox at Tessl makes the argument that context handed to agents deserves the same rigor as production code: version it, test it, lint it, run it through CI. You would never ship untested code. Shipping untested context is the same mistake wearing a different hat, and it fails in a way that is harder to see.

Three things from that discipline that matter in a regulated environment specifically:

• The dumb zone is a cliff, not a slope. Past a certain context load the agent’s performance does not decline gracefully, it collapses. You find the threshold by testing full-repository loads, and sometimes the fix is to delete context, not add it. In a bank, where the instinct is to stuff every policy and every control into the window, this is the counterintuitive part: more context can make the agent worse.
• One run proves nothing. Models are non-deterministic, so a single passing test is noise. You evaluate a piece of context across several scenarios and measure the average, and you grade the approach with a rubric rather than trusting a green unit-test bar, because agents will do unspeakable things to make a test pass. That is the same evidence standard your model risk function already demands of any model you put into production.
• Context has a lifecycle. A style guide that was essential last year is token waste once the model writes that language well on its own. The context that helps today becomes the context that bloats tomorrow, and only evaluation tells you when to prune.

Determinism beats hope, and that is the through-line. A rule written in prose is a nudge the model may ignore. A hook is code that always runs. A pre-tool-use hook blocks the destructive command before it executes. A stop hook runs your tests and type-checks the moment the agent claims it is done and forces another pass on failure. In a regulated shop the hook is not a productivity nicety, it is the control you can show an examiner, because it fires every time and leaves a record, and the prose instruction does neither.

Two harnesses, not one

There is a trap waiting for anyone who builds a great personal harness and assumes it ships. It does not, and the reason is worth stating plainly.

The cleanest cut, one the community has slowly converged on, is that there are two different species of agent. The personal agent runs on your machine, serves one user, and lives happily on flat markdown, the Karpathy LLM-wiki pattern of index docs, tags, and entities. It is the simplest thing that works, and for a single user it is genuinely ideal. The production agent ships inside a platform to strangers who log in, and the markdown wiki that made the personal agent great is fatal the moment you have concurrency, live data, access control, and retrieval at scale. Reading whole markdown documents burns tokens, and no amount of prompt optimization saves you.

The production harness needs a database doing two jobs. A context retriever documents the structure of your business data and auto-generates the query tools the agent uses, so it filters and searches instead of crawling documents blind. An agent-memory layer promotes the important facts out of each conversation into vector-searchable long-term storage, so the second session knows what the first one learned. There is also a legal seam most people miss: personal second brains run on a coding-agent subscription licensed for personal use, and you cannot lean on that once you have external users.

For a bank the two-species split is not trivia. It is the line between a tool an architect runs at their desk and a system that touches customer data under governance, and the harness for the second one has to be built from different bones. Confusing the two is how a promising internal demo dies in the control review.

The honest tension

I will not pretend the field agrees on everything. There is a real disagreement about the model itself, and it bears on how much the harness actually buys you.

One camp, Dru Knox among them, says crank it to the maximum: use the strongest available model unless you have a specific reason not to, and optimize for cost only after you have identified the repetitive, well-understood work. The other camp, IndyDevDan among them, argues that a strong harness makes a cheaper model punch well above its weight, and that models matter less every quarter. Both are describing something true. The reconciliation most practitioners land on is to use the strongest model for planning and review, cheaper models for the grunt work, and let the harness route between them.

Notice what that reconciliation assumes. It assumes you have a harness good enough to route, to plan in one place and execute in another, to hold a cheap model to a standard through validation it cannot skip. The disagreement about which model to use is only livable because the harness is the thing deciding. Which is the argument, restated from the other side.

Why this is the moat in a regulated shop

Put the ownership question next to the banking constraints and the conclusion gets sharp.

You cannot own the model. It is an API you reach across a vendor boundary, on infrastructure you do not run, governed by a model risk framework that was written for models you could actually inspect. I made the where-does-it-run case in Claude Code: Where It Actually Runs, and the honest answer is that the reasoning engine will always sit partly outside your control. You cannot own the thing you rent from Anthropic or OpenAI or whoever wins the quarter.

You can own the harness. The rules are yours, in plain text you version. The hooks are yours, deterministic and auditable. The retrieval layer is yours, sitting on data you govern. The control flow is yours, and it is the same reconciliation loop infrastructure engineers have run for a decade, which I traced in The Reconciliation Loop. When the model swaps, the harness ports. When the examiner asks what controls the agent, the harness is what you show them, because the model cannot answer that question and the harness can.

This is what Judgment Is the New Moat looks like once it is built rather than argued. Execution is a commodity when anyone can rent the same model you rent. The durable advantage is not the reasoning, which everyone can buy, but the accumulated harness that decides what the reasoning does, and that advantage compounds in exactly the layer the vendor cannot deprecate out from under you. The specialization is the moat: a change-management harness, a control-testing harness, a reconciliation harness tuned to your institution will beat a generic agent at your work, every time, on any model.

The lab will ship a better model next quarter. It always does. Rent it, and re-tune the three prompts you care about, and move on. Then go spend your real attention on the deed, not the rental.

---

The model is the part of your stack with the shortest shelf life and the loudest marketing. The harness is the part with the longest life and no marketing at all. Build accordingly.

The companion read is Prompting Split Into Four Skills, Infrastructure Is the Fifth, which works the layer below this one: how the disciplines become scaffolding before the scaffolding becomes a moat.

I write about AI-assisted development, enterprise architecture, and the vendor relationships that quietly shape both. Find me on X @orestesgarcia or LinkedIn /in/setsero.