How to read: the large box is the harness — nothing happens outside it. Inside, the loop runs (plan → execute → test) and follows the top arrow back when a test fails. The course teaches you to build the box (module 2.1) and make the loop stop at the right time (module 2.2).
Learning path map
Detailed content
⚙️ Harness Engineering
Engineering the structure around the model: instructions, context, tools, permissions, sandbox, memory, state, observability, verifiers, and limits.
The set that defines what the agent sees, which tools it can use, which actions it can take, which rules it follows, how context is selected, how state is preserved, how results are verified, when to stop, and what requires approval.
Switching to a different model improves a few percentage points; building a decent harness changes the outcome by a whole category. It's the highest-return lever.
Harness = the system around the model · The differentiator isn’t the prompt · Every power granted needs a corresponding limit.
Deliberately selecting the files, documents, and examples relevant to the task—instead of feeding the entire repository as input.
Irrelevant context isn't neutral: it dilutes the signal, increases cost, and makes the agent imitate patterns you don't want to replicate.
Curation > volume · A good example is worth more than a long description · A single source of truth prevents conflicting instructions.
The explicit list of available resources (terminal, editor, search, tests, database, APIs) and what can be read, changed, run, or published with each one.
Implicit permission means full permission. Most agent incidents involve access no one decided to grant—they simply didn’t deny it.
Least privilege · Irreversible actions require approval · A tool without limits is a dangerous tool.
An isolated environment (container, worktree, branch, disposable database) where the agent can work without affecting production or your work environment.
A sandbox is what turns an “agent error” into a “discarded attempt.” Without isolation, every attempt is a real risk.
Isolation enables greater autonomy · Disposable state > precious state · Reversibility is a prerequisite for speed.
Memory is persistent or temporary information used for the task; state is the record of the current point in the work; observability consists of logs, metrics, and the history of actions.
Without state, the agent starts from scratch after every interruption. Without observability, you can’t audit or explain what happened.
State lets you resume · Logs are evidence, not decoration · Memory without curation becomes accumulated noise.
Tests and validations that assess the quality of the result, together with limits on time, cost, number of attempts, modified files, and permitted actions.
The verifier is what authorizes autonomy: the better it is, the more you can delegate without fear. Limits are the brake when the verifier fails.
Weak verifier = dangerous autonomy · File limits keep the diff reviewable · Human approval for critical actions is part of the harness.
🔄 Loop Engineering
Execution and correction cycles: observe, plan, execute, test, evaluate, correct — with a stopping condition, attempt limit, cost, rollback, and fallback.
An agent’s standard cycle: observe, understand, plan, execute, test, evaluate, correct, and repeat.
Loop Engineering isn’t telling AI to "keep going until it works" — it’s creating a controlled, measurable, and verifiable sequence.
Each iteration needs a new signal · Without evaluation, there’s no correction · Repeating without measuring wastes money.
A target that can be checked with a command, plus a persistent record of what’s already been done between loop iterations.
A loop with a subjective goal never ends; a loop without state repeats work and contradicts itself.
Objective = command that returns yes/no · Persistent state lets you resume · Measurable progress prevents blind loops.
The three outcomes of any loop: it finishes successfully, runs out of attempts/cost, or detects that it isn’t making progress and should stop and ask for help.
The stop-on-abandonment condition is the one almost no one implements — and it’s exactly what prevents burning through the budget in an infinite loop.
Every output needs to be explicit · Stopping and asking is a valid outcome · Without a limit, the loop keeps running until someone notices.
Explicit limits on retries and consumption, with a rule that the same action must not be repeated without changing the approach.
A stuck agent repeats the same fix with slight variations. Without an attempt limit, that becomes pure cost with no progress.
Same failure twice = change your strategy · Cost is a project constraint, not a detail · Measuring each attempt reveals unproductive loops.
Rollback restores the system to its previous state; fallback defines the alternative when the primary path doesn’t work.
The ability to undo defines how much risk you can accept. Where there's no rollback, there's no autonomy.
Migration must be reversible · A branch/worktree makes rollback cheap · A fallback prevents the entire workflow from stopping.
The required interruption of the loop before critical actions: deploy, migration, permission change, production change.
Approval in the wrong place becomes an automatic rubber stamp; in the right place, it’s the last control point before damage.
Approve with evidence, not trust · Fewer serious approvals > many ignored ones · Reversible actions can be automatic.