The model is the engine.
The harness is everything else.
A harness is everything around an AI agent that isn't the model's weights: the instructions it reads, the tools it can use, the environment it runs in, the memory it keeps, and the checks that tell it whether it got things right.
Same model, different harness, very different results. Snap the blocks together below and watch what changes.
Think of a brilliant new hire on day one
They're smart. But with no README, no idea how to run the tests, and no notes from yesterday, they'll spend most of their time figuring out the project instead of doing the work. An AI agent is in the same spot, except it can't ask anyone. It only sees the files you give it and the commands it's allowed to run.
The model
Raw capability: reasoning, writing code. You rent it. You can't change it.
The harness
Everything you can change: rules, tools, setup, memory, checks. If it isn't model weights, it's harness.
The result
How much of the model's capability actually turns into finished work. That part is up to you.
A real team, same model the whole time
A TypeScript + React app (~20k lines). They never changed the model. They only added harness blocks, one at a time.
Successful runs out of 5. From the course, Lecture 02.
Snap together a harness, then run the agent
Drag blocks onto the baseplate, or tap them. Pick a task, press Run, and see what goes right and what breaks. The bottom row is the 5 core blocks every harness needs. The row above holds power-ups you add once your tasks get longer or run without you.
Core blocks
Power-ups
Tap a block to add or remove it. Tap a placed block to read about it.
Prompt, context, harness, loop, graph
These aren't competing ideas. Each one stacks on the one below it. Tap a block in the tower to see what it shapes and when you need it.
This course treats the harness as the foundation, with loops and graphs built on it. Some writers place it elsewhere in the stack; the blocks are the same either way.
Common confusions
"Isn't a harness just a good prompt file?"
No. A prompt file (AGENTS.md, CLAUDE.md, .cursorrules) is one block: Instructions. Without tools it can't act, without an environment it can't run, without state it forgets, and without feedback it can't tell whether it's right.
"Are Claude Code, Codex, and Cursor harnesses?"
Yes, they're general-purpose agent harnesses: they supply the loop, tools, and context management. Your repo adds the project-specific layer on top: your rules, your setup script, your tests, your progress files. Both layers count, and the second one is the part you control.
"Is it the same as an agent framework like LangGraph?"
A framework is a toolkit for building loops and graphs. Using one doesn't give your project verification commands, reproducible setup, or progress tracking. You still have to put those blocks in.
"Is this related to a 'test harness'?"
Same idea. A test harness is the scaffolding around code under test. An agent harness is the scaffolding around an agent at work: it feeds the agent inputs, constrains it, and checks its output.
"Won't better models make harnesses unnecessary?"
Some blocks matter less as models improve, and new ones become critical. The course's advice is to remove blocks one at a time and measure the drop. That tells you which blocks are pulling their weight today.
When an agent fails, check the harness before you blame the model
Every failure points at a missing or weak block. Read the symptom and pick the block that fixes it.
The first afternoon, in order of payoff
Start with the cheapest blocks that pay off most. Add power-ups only when a real failure calls for one. Tick each step off as you go (saved in this browser).
A harness is engineering, so it has trade-offs
👍 What you gain
- Same model, far better results. Teams go from "unreliable" to "reliable" without paying for a bigger model.
- Repeatable. Every session starts from a known state, so results stop depending on luck.
- Longer tasks. State and clean hand-offs let work span many sessions, or run overnight.
- Debuggable. When something breaks, you can trace it to one block and fix it once.
- Helps humans too. A clear AGENTS.md, a one-command setup, and good tests help every new teammate as well.
👎 What it costs
- Setup time. Scripts, tests, and docs take real effort to write.
- Harness rot. Instructions and scripts go stale as code changes. Stale rules are worse than none.
- Over-building. A graph of five agents for a one-line bug fix just adds cost and things that can break.
- Context overhead. Huge instruction files eat the context window. Give a map, not a manual.
- False confidence. Weak tests let an agent "pass" while the product is still broken.
Rule of thumb: add a block only when a failure asks for it
Run the agent, see where it fails, figure out which block was missing, add that block, and run again. Try the builder with "Fix a small bug" plus every power-up to see over-building in action.