AGENTS · SYSTEMS · RELIABILITY
The model is not
the system.
A reliable coding agent does not emerge from a brilliant prompt. It emerges when the repository provides a map, work has boundaries, execution produces evidence, and every session leaves state another can resume. This is the compact version of all fourteen Learn Harness Engineering lectures.
01 / THE DESIGN UNIT
Do not design
a prompt.
Design the system around the model.
The course’s first conceptual correction is to separate capability from reliability. A model can understand the code and still build the wrong thing, touch too much, lose decisions across sessions, or declare victory while the system is broken. Those are not necessarily intelligence failures; they are execution-system failures.
The harness is everything that turns intent into a work cycle: what the agent knows, what it can do, where it acts, what it remembers, and which evidence it receives. If a failure can be attributed to one of those subsystems, changing models is a premature response.
Intent
A short project map, non-negotiable constraints, and links to relevant detail.
Capability
Enough access to read, change, execute, and diagnose, bounded by least privilege.
Repeatability
Pinned runtime, dependencies, and commands so two sessions operate the same system.
Continuity
Progress, decisions, blockers, and the next action persisted outside the conversation.
Evidence
Fast checks, behavioral tests, and runtime signals that close the loop.
02 / THE REPOSITORY AS MEMORY
A short map.
Detail near the code.
Useful information must be findable, current, and proportional to the task.
AGENTS.mdEntryPurpose, stack, commands, constraints, and routes to specific documentation.
docs/ + module docsContext on demandArchitecture, decisions, and rules beside the area where they apply.
PROGRESS.mdOperational stateWhat is done, active, blocked, and the next verifiable action.
FRESH-SESSION TESTUsing only the repository, a fresh session should be able to explain what the project is, how to start it, which rules it cannot break, how to verify it, and where to continue. Every missing answer becomes discovery cost or a guess.
Accumulating every correction in one file lowers signal, buries constraints, and creates contradictions. The entry point should route, not contain the universe. Repetitive mechanical rules should graduate into types, lint, tests, or CI.
03 / THE SESSION LIFECYCLE
Start ready.
End resumable.
Continuity is designed at session boundaries.
- 01INITIALIZE
Reconstruct reality
Read instructions and state, inspect the worktree, install what is needed, and run a baseline. If the starting point is already red, record it before touching business code.
- 02EXECUTE
One unit at a time
Choose one task, declare scope and exclusions, implement, observe, and correct until evidence exists.
- 03CLOSE
Logical commit or honest handoff
Verify, remove temporary debris, and persist decisions, results, and the next action. Incomplete is not failure; ambiguous is.
Think of it as a shift change: the next session does not need the full transcript; it needs a compact, faithful representation of the executable state.
04 / SCOPE AND DEFINITION OF DONE
Less open work.
More finished work.
For agents, WIP=1 is a safety default.
F-03A user can export the complete report from the results screen.
npm run test:e2e -- exportactive → passingNo filesystem refactor and no visual redesign.
A feature list is not a wish list. It is the shared contract between the selector, implementer, verifier, and next session. The agent may propose that something is ready; only evidence may move it to passing.
05 / FEEDBACK THAT CLOSES THE LOOP
“Looks correct”
is not evidence.
Each level answers a different question and exposes different failures.
- 01STATICCHEAP · FREQUENT
Is its shape valid?
Format, lint, types, build, and unit tests. They are fast and localize well, but do not prove the composed product.
- 02RUNTIMECONCRETE · DIAGNOSTIC
Does it start and behave?
Integration, migrations, health checks, side effects, and critical paths with real dependencies.
- 03SYSTEMEXPENSIVE · DECISIVE
Can the person finish the job?
E2E, visual review, accessibility, and failure scenarios. It tests interfaces and boundaries, not only components.
“Test failed” leaves the agent guessing. “The renderer accessed the filesystem; move the operation to the preload bridge and rerun the export flow” turns the check into a self-correction mechanism. When human feedback repeats, promote it into an executable rule.
06 / OBSERVABILITY
See what it did.
Know why it continued.
Reliability is an evidence problem, not a vibes problem.
The observed system
Startup, ready state, correlated logs, full errors, critical paths, resource use, and cleanup.
The observable decision
Goal, scope, exclusions, plan, acceptance criteria, verifier result, and the reason for each retry.
MINIMUM TRACEtask_id · code_version · active_feature · command · result · attempt · next_action
07 / FROM LOOP TO GRAPH
Automate after
you can stop.
Autonomy amplifies both the design and its defects.
Verifiable goal
Describe the end state, not an endless sequence of actions.
Separate judge
Deterministic tests or an evaluator with fresh context; the author does not grade their own exam.
Budget and exit
Maximum attempts, time, cost, and explicit escalation when progress stops.
External memory
The loop rebuilds context from artifacts; it does not depend on remembering the conversation.
there is one primary goal, one dominant path, local retries, and one advancing state.
there are specialized roles, parallel work, conditional routes, rollback to different stages, arbiters, or human approval.
A graph does not replace the harness: it makes it visible at scale. Its nodes have responsibilities; its edges, conditions; its state, merge rules; and its anchors tie it to real outcomes so a metric does not become the wrong goal.
THE MINIMUM PLAYBOOK
Map. Contract.
Evidence. Handoff.
- Make a fresh session able to operate the repo without an oral explanation.
- Activate one unit with explicit behavior, exclusions, and a check.
- Use tests and runtime to decide done; never the author’s confidence.
- Leave the system green or document precisely why it is not.
- Only then automate the loop; draw a graph only when the routes require one.
08 / ALL 14 LECTURES IN ONE LINE
Complete coverage.
No filler.
The course’s full arc, reduced to the decision worth keeping from each unit.
- 01
Diagnose the system
A capable agent can fail because requirements are vague, context is missing, the environment is broken, feedback is weak, or state is lost.
- 02
Design five subsystems
A prompt file is not a harness: instructions, tools, environment, state, and feedback have separate jobs.
- 03
Make the repo the record
What is not visible and maintained somewhere a fresh session can reach effectively does not exist.
- 04
Give a map, not a manual
The entry file should route to documentation near the code and loaded on demand.
- 05
Persist the why
Code preserves what changed; the handoff must preserve decisions, results, and the next action.
- 06
Initialize before implementing
First prove the project starts, can be verified, and can be resumed.
- 07
Limit WIP to one
Finishing one verifiable unit before opening another reduces accidental scope and half-work.
- 08
Externalize the contract
Every feature needs expected behavior, verification, state, and evidence.
- 09
Take “done” away from the author
Agent confidence is not a termination criterion; an executable, independent condition is.
- 10
Test the whole journey
Unit tests isolate; integration and E2E expose contracts, state, and resources that fail when composed.
- 11
Make execution visible
Logs and health checks explain what happened; plans, criteria, and rubrics explain why to accept it.
- 12
Close cleanly
Green build and tests, updated state, no temporary debris, and a working startup path.
- 13
Automate only a closed loop
Autonomy needs a goal, verifier, limit, and external state; without them it only repeats uncertainty.
- 14
Use graphs when topology matters
Specialization, parallelism, rollback, and arbitration justify explicit nodes and routes.
09 / SOURCES
Read the course.
Then the foundations.
This piece synthesizes the lectures; it does not replace their examples, exercises, or nuance.
- 01Complete course · Learn Harness Engineering↗
- 02Harness engineering in an agent-first world · OpenAI↗
- 03Effective harnesses for long-running agents · Anthropic↗
- 04Harness design for long-running application development · Anthropic↗
- 05Building effective agents · Anthropic↗
Editorial synthesis based on public material available on August 31, 2026. Practical recommendations were rewritten and grouped; this is not a verbatim reproduction of the course.