The harness is the product; the model is a component

An agent is a model plus a harness, and of those two terms, only one is yours. The model is a component you rent; the harness — context assembly, tool execution, permissioning, loop control, recovery — is the system you actually build, and it's where every hour of differentiated engineering lives. Teams that agonize over model choice and treat the harness as glue code ship fragile systems and accumulate no moat.

I find the operating-system analogy the most durable way to hold this. The model is the CPU: astonishing, general-purpose, and identical to the one your competitor rents from the same vendor. The harness is the operating system — it decides what the CPU sees (context assembly), what it's allowed to touch (permissions), how its work gets scheduled and bounded (loop control, step budgets), and what happens when a process crashes (recovery). Nobody differentiates on the CPU they bought. They differentiate on what they built around it.

Where the engineering actually goes

The gap between "calls an LLM in a loop" and "runs in production" is measured in the harness. Anthropic's own framing around the Claude Agent SDK puts the remaining enterprise infrastructure — context management, orchestration, security, observability, evaluation, persistence — at 2,200 to 4,500 engineer-hours beyond what the SDK gives you. That is not prompt-tuning work. It's systems work: component contracts like retrieve/write/route/execute/verify/monitor, sandboxed executors with idempotency guarantees, output validators, continuation controllers that reset context on long-running jobs.

The evidence that harness decisions dominate model decisions keeps piling up. Vercel's tool-proliferation finding is my favorite: removing 80% of an agent's tools took task success to 100%. Same model. The failure was a harness failure — an overloaded tool surface confusing selection — and the fix was harness engineering. Similarly, harness type is the lever behind wildly different cost and reliability profiles: a reactive harness runs 1–3 model calls at 95%+ reliability, while a deliberative harness burns 5–20 calls and 2K–80K tokens to land at 65–90%. Choosing between those is an architecture decision the model never sees.

Swappability is the tell. In a well-built harness, the model is literally a configuration field. Composition over interface inheritance means you can hot-swap the planner's model, route 60% of traffic to a small model (router-first architectures report 50–70% cost reductions), or drop in next quarter's release without touching the permission system. If swapping models terrifies you, your harness is too thin; the model's quirks have leaked into everything.

The honest counterargument

There is one, and it's serious: harnesses shrink as models improve. Anthropic's own simplification trajectory shows it — moving from Opus 4.5 to 4.6, they removed sprint scaffolding and cut cost from $200 to $125 for the same work. Some of what you build today is compensation for model weakness, and that part is a depreciating asset. But watch which parts depreciate: the elaborate planning scaffolds and multi-step decomposition tricks. Permissioning, sandboxing, recovery, audit, integration with your actual systems and your actual data — those don't get absorbed by a smarter model, because they were never about intelligence. They're about trust and plumbing, and trust and plumbing are where enterprise value has always lived.

So my advice runs opposite to the instinct. Spend a day on model selection; it's a benchmark comparison and a config change. Spend the quarters on the harness — because when the next model ships, the team with the real harness upgrades in an afternoon, and the team with glue code starts over.