why build one you can break
lesson 01 named the four layers. this lesson builds a harness you can actually run — and then break on purpose.
the industry framing is the same one viv named and the 2026
harness writeups keep repeating: agent = model + harness.
the harness is scaffolding that connects the model to the
real world. its job is not wrapping messages.create. its
job is delivering the right context at every step.
cursor, claude code, aider: they are good products. they are also black boxes. you type, a diff appears. the loop that loaded context, called the model, parsed tool_use, and dispatched a write is somewhere you cannot step. when it fails, you shrug at the product. that is fine for editing a file. it is not fine for a queue triage that writes back into the repo.
you need a harness that is yours:
- a scaffold — five files, not a vendor folder
- tools — an allowlist, not "whatever the model named"
- a loop — prep → call → parse → dispatch, with a cap
- a gate — a rule that can fail the run so you do not ship
run the editor. two dicts. the product one lists what you cannot do. the repo one lists the files that make those things possible.
what this lesson is NOT
- not a product bake-off. you already saw the layer table.
- not ratchet logs, context-budget theory, or sdk shopping.
- not a company-wide rebuild.
what it IS: a small harness you can step through, a spec you
can fill, two bugs you will recognize in the wild (policy
stuffed into the prompt; no cap / no allowlist), and
build_harness_run(...) wired to a fake_model so it runs
here.
what you'll build
build_harness_run(spec, inputs, tools, fake_model, max_iters)
returns {text, iters, tool_calls, gate}. gate is pass or
fail from a rule on the spec — the thing you refuse to
ship without.
once you have that, you can break one layer at a time and watch the gate flip. that is the whole point of owning the loop.