Who Does What: Model vs. Harness
Reviewed by Human · Updated September 22, 2026
✗ Wrong way
You are my coding agent. Remember what we did last session and keep going. Don't repeat finished work, and please verify your own changes before you tell me it's done.
Every ask in that message is a job the model can't reliably do on its own. It has no memory of last session — the chat is gone. It can't "not repeat finished work" if nothing on disk records what was finished. And "verify your own changes" means nothing without a command it's required to run. You've handed the model four harness jobs and called them instructions.
✓ Better way
Read `claude-progress.md` and `feature_list.json` before doing anything. Continue the first feature marked in_progress. When it's built, run `npm test` and paste the output before claiming done.
Now the model does the one thing it's good at — deciding what code to write — and the harness carries memory (progress + feature list), scope (one in_progress feature), and verification (real test output). The division of labor is explicit.
Same complaint, two setups
✗ No State subsystem
The model is asked to remember across a boundary it physically cannot cross. This isn't a smart-enough problem. It's a missing-State problem.
✓ State subsystem present
Memory now lives on disk. The model reads it instead of recalling it. Same model, same underlying request — but the job landed on the subsystem built for it.
Live Demo — AI Terminal
Watch how the same request routes differently once you know the division of labor. The model proposes; the harness disposes.
Your prompt
Field note
For a while I kept a running list of gripes about my agent: it forgot the auth decision, it re-implemented a helper we already had, it 'lost' the migration order. I was ready to blame the model. Then I wrote each gripe next to the five subsystems and almost every one landed on the same square — State. Nothing in the repo recorded those decisions, so a fresh session had no way to know them. The 'fix' wasn't a smarter model or a longer prompt. It was three lines in a progress file the agent read at startup. The complaints didn't come back. That was the moment 'my agent is dumb' quietly became 'my harness is missing a subsystem,' and debugging got a lot less mystical.
What Is the Difference Between the Model and the Harness?
The clean split: the model owns *what*, the harness owns *when, where, and how*. **Model**: the reasoning engine that decides what code to write. **Harness**: the environment that governs when it runs, where it reads state, and how it proves the work. This is why a stronger model doesn't rescue a harness-less setup — you've made the *what* smarter while leaving *when, where, and how* undefined. It's the same insight behind treating any failure as a harness problem before a model problem: first ask which of the five jobs got dumped on the model by mistake.
Complaints are a diagnostic
You don't need a debugger for most agent misbehavior. You need the five names. "It forgot" → State. "It said done but it wasn't" → Verification. "It changed things I never asked for" → Scope. "It fought a broken environment" → Lifecycle. "It didn't know the rules" → Instructions. The complaint tells you the missing subsystem.
Your turn
Take the four complaints from the insight above (or your own). Assign each one to exactly one subsystem — no fair picking two.
Reflect
When mapping gets fast and unambiguous, you've internalized the framework.
You've finished this module.
Mark it complete to earn your XP and keep your streak alive.
Progress saved locally · Sign up to earn XP