12 load-bearing claims behind harness engineering

The walkinglabs course is a structured public treatment of one thesis: the surrounding harness, not the model’s weights, governs how much capability is realised. The lectures here, each pinned to one load-bearing claim, build the argument from “why agents fail” through to “how a session exits cleanly.” This page is the index — one sentence per chapter, capturing the kernel you’d want to remember a year from now.

Capability vs. realization

Reliability is a harness property, not a weights property — the same model produces vastly different results depending on task clarity, context, environment, verification, and state management around it.

The five-part harness

A harness is instructions, tools, environment, state, and feedback — the infrastructure outside the model weights that decides how much of the model's capability actually ships.

Repository as system of record

What isn't in the repository doesn't exist for the agent; durable state lives in files the next session can read, not in conversation history that evaporates.

Split instructions, don't stack them

One giant AGENTS.md wastes context budget and buries critical constraints via the lost-in-the-middle effect; small, focused files load only what each task actually needs.

Continuity files for long tasks

Progress logs, decision records, and git checkpoints carry state across the context boundary, so a fresh session resumes work instead of redoing it.

Initialization is its own phase

Setup and feature work have incompatible optimization targets — agents prioritize visible output over foundation, so the first session must finish a runnable environment before any feature work is allowed.

One task, verified, at a time

Attention is finite; agents complete more features when scope is narrowed to a single task with an explicit verification requirement, rather than letting multiple tasks dilute focus.

Feature list as state machine

The feature list isn't a memo for humans — it's the externalized state machine the harness reads, transitions, and verifies against; conversation-only state means no enforceable definition of done.

Independent verification beats self-report

Modern models are systematically overconfident, so completion must be judged by an out-of-model check; replacing self-judgment with multi-layer runtime verification prevents premature victory.

End-to-end testing reshapes design

Unit tests miss integration defects that only surface when everything runs together; requiring the whole system to actually run pushes the agent toward cleaner component boundaries.

Observability inside the harness

Without runtime signals, 30–50% of session time goes to redundant diagnosis and blind retries; observability is an architectural requirement of the harness, not a debugging convenience added later.

Clean state on session exit

Entropy growth is the default — 'clean up later' means never; without a teardown discipline at each session's end, baseline recovery eventually dominates feature work.