Model, Loop, Harness: Three Layers and Who Owns Each

Agent systems have three layers with different change rates, different skill requirements, and different owners. Teams that haven't separated them end up with everyone touching everything, and no one accountable for the layer that's actually causing problems.

The layers

The model. Takes messages and tool specs, returns text or tool calls. You don't build it, you select and configure it. Changes on the provider's schedule.

The loop. The execution mechanics: iterate, dispatch tools, manage state, enforce budgets, decide termination, handle errors, persist for resumption. Ordinary software, changes rarely once right.

The harness. Everything domain-specific: which tools exist and how they're described, what context gets assembled, what the prompts say, what the checks verify, what the permissions allow, how work is presented for review. Changes constantly.

⚠️ Most teams conflate the second and third, which is why loop bugs get fixed with prompt edits and domain problems get fixed by rewriting the loop.

Who should own each

The model layer — one person or a small group, making a deliberate choice with an eval-backed comparison. Not something individual engineers change per feature.

The loop — engineering, ideally one owner. It's infrastructure: correctness matters enormously, it's testable without a model, and it shouldn't be modified to solve domain problems.

The harness — this is the one that needs a different answer. Tool descriptions, prompts, and eval cases require domain knowledge. The person who knows what a good output looks like should be editing them, with engineering review.

→ The failure mode of engineering owning the whole harness: prompts and tool descriptions written by people guessing at domain judgment. It produces systems that are technically sound and subtly wrong in ways only a practitioner notices — and the practitioners' feedback arrives as complaints rather than as edits, which is a much lossier channel.

Why the separation pays

Debugging gets faster. "Which layer is this?" narrows the search immediately. Wrong tool chosen → harness. Run didn't resume after a crash → loop. Reasoning was poor with everything present → model.

Testing gets tractable. The loop is testable with stubs and no model at all — including all the unhappy paths. The harness is testable with recorded responses. Only model-layer questions need live calls.

Changes stay contained. A domain expert editing a tool description shouldn't be able to break resumption. Layer separation is what makes that structurally true rather than a matter of care.

The right people work on the right things. Engineering on the loop, domain experts on the harness, one deliberate owner for the model.

✅ Making the separation real

• The loop takes the harness as configuration — tools, prompts, budgets, checks passed in, not hard-coded.
• The harness contains no execution logic. If a tool description explains what to do when something fails, that behavior belongs in the loop.
• Model selection lives in configuration, in one place.
• Different review requirements per layer. Loop changes need engineering review; harness changes need domain review plus a lighter engineering check.
• Separate test suites. Loop tests with stubs; harness tests with recorded responses; model comparisons on a frozen eval set.

💡 The layer that surprises people

The loop is smaller and more stable than expected. Once termination, budgets, state, dispatch, errors, and resumption are right, it changes rarely.

The harness is larger and more volatile than expected — and it's where nearly all ongoing work lives. Which is the argument for making it configuration rather than code: the thing that changes weekly shouldn't require touching the thing that must stay correct.

The takeaway

Three layers: the model you select, the loop you build once, the harness you change constantly. Separate them so the loop takes the harness as configuration, and assign ownership accordingly — engineering on the loop, domain experts on tool descriptions and prompts and eval cases, one deliberate owner for the model. Then a failure has an address, and the people best placed to fix each layer are the ones who can.