ESCAPE VELOCITY · SESSION TWO HANDS-ON WORKSHOP · JUNE 2026

Building
agentic
harnesses

Two flights in one afternoon: first the harness that makes an agent worth trusting — then what happens when that harness starts maintaining itself.

RISHI DEAN · github.com/rishidean/tutorials-agent-loop

THE AGENDATWO PARTS · ONE ARC

Part one builds the harness — part two is what happens when the harness starts writing itself.

DEVELOPING WITH AGENTIC WORKFLOWS HANDS-ON WORKSHOP · JUNE 2026

Getting
airborne

Demystifying agentic engineering, so we can leave the "ground" and "take flight" on the AI Adoption Continuum. 

RISHI DEAN · github.com/rishidean/tutorials-agent-loop

HOW TO READ THISSELF-PACED

Every claim here is runnable — the repo builds a real app, unattended.

A quick caveat

HOW TO READ THE DEMOMINIMAL REPRODUCIBLE CASE

Judge the mechanism first. Then argue about blast radius — I’ll make that argument for you.

Part one

What this answers: what the keynote established, and where today picks up.

THE AI ADOPTION CONTINUUMRECAP · FROM THE KEYNOTE

THE AI ADOPTION CONTINUUMRECAP · FROM THE KEYNOTE

The jump we make today

What you'll walk away with

Part two

What this answers: what the system is, and how it runs unattended.

THE OPEN SECRET

WHERE THE INTELLIGENCE LIVES

WHAT WE MEAN BY AGENTIC

TWO THINGS MODELS DO

In a loop, most of the work is tool calls returning ground truth not the model free-associating. run-qa’s Playwright test actually ran; the model didn’t decide it passed. A call is an anchor — a result that can’t be argued with.

THE PRIMITIVES

THE SYSTEM

Overview · the three stages

This map recurs — the next three slides zoom into one stage each.

{{ c.tag }}

{{ c.title }}

●{{ it }}

THE TOPOLOGY

GREEN = passed, ship it · RED = failed, fix & re-run (max 3)

THE TOPOLOGY · BY FILE

YOU MAY HAVE HEARDLOOPS VS GRAPHS

An edge is real only if data moves across it — and every arrow here carries data. By the graph crowd’s own rule, “a loop is fine.” Loops buy depth; graphs buy breadth — Jet is this, fanned wide.

THE SYSTEM

Stage 1 / 3 · Setup

Why first: the system can't act until it knows the rules.

How we work.

Everything true for every sprint: architecture, conventions, and the definition of done. One constraint forces quality —

What needs to get done, where we're at.

Three characters per line — that's your state machine. The checkbox ticks after each sprint. Stuck work marks [!] and stops.

How to decompose · roadmap.md

What to build this turn.

One spec per sprint: acceptance criteria, technical approach, edge cases. This is where your engineering judgment lives.

Where judgment lives · sprint-3.md

THE SYSTEM

Stage 2 / 3 · Actors

Why next: someone has to do the work — and check it.

Executes the spec for a single  feature / sprint. Then done.

The Builder is just a Claude Code session — no special framework, no persistent agent. Spun up fresh for one sprint, then thrown away. Its power is that nothing carries over.

THE QA MANAGER

THE QUALITY TEAM

This is the scaffolding that earns the trust — the answer to the doubt loop from Part 1.

Every verdict is a contract — GREEN / RED · CRITICAL / WARN / NIT — a shape the next step consumes, never prose.

Judgment · latent vs Verification · anchored Two anchors and one opinion — lint and tests are deterministic; the reviewer is a fresh-context judgment, and the anchors outrank it.

{{ q.mark }}

{{ q.name }}

{{ q.model }}

{{ q.job }}

{{ q.snippet }}

{{ q.file }}

THE INNER LOOP

THE SYSTEM

Stage 3 / 3 · Orchestrator

Why last: something has to keep the sprints moving, hands-free.

KNOWLEDGE HANDOFF

QA GREEN → three writes — roadmap = state · PROGRESS = memory · CLAUDE = learning

A deliberate simplification. In production this handoff is a context-management system writing to several stores — here it’s one file per job, so you can read the whole mechanism in one sitting.

THE ORCHESTRATORrun.sh

The distilled core. The real run.sh wraps this with logging, timing, and a configurable sprint cap.

Part three

What this answers — how to run the loop on your own machine.

STEP 1 · SET UPSTEP 1 / 4

STEP 2 · RUNSTEP 2 / 4

WHILE IT RUNS  ·  ~10 MINS

// back in a few

STEP 3 · WATCHSTEP 3 / 4

STEP 4 · PLAYSTEP 4 / 4

$ open index.html # or reference/index.html for the finished build

DEBRIEF

LOW FLOOR  ·  HIGH CEILING EXTENDING THE LOOP

Part four

What this answers — what airborne means next, and the one ask.

WHAT'S NEXT

{{ p.who }}

{{ p.stage }}

{{ p.text }}

THE CAPABILITY LADDER HELICOPTER → JET → SPACESHIP

Sequential is a choice, not a ceiling. Everything in this talk is column one — learn the loop before you fleet it. Column three is the next talk.

WHERE THIS FLIESKNOW YOUR BLAST RADIUS

I work high in the stack, where the floor catches me — that is the fair version of the “toy” critique, and it was never that the example was small. The loop still runs down there. The gate just moves: a human on the diff, not on the keystrokes.

THE LOOP OBJECTION WHERE THE LOOP LIVES

“Offloading a full task to an agent” is a loop too — someone else’s, with the control surface hidden. The one you can see is the one you can put a gate in.

WHAT AIRBORNE LOOKS LIKE

THE ACCELERATION

The advantage compounds. The gap between Driving and Helicopter isn't closing — it's widening. In public: the Bun runtime port — ≈535K lines of Zig → 1M+ lines of Rust in 11 days, ≈$165K of usage against roughly a year of engineering. (The review-burden critique is real — and earned.)

THE COST OBJECTIONTOKENS VS HEADCOUNT

Cap first: one repo, twenty items  →  read the usage report  →  earn the scale, then double.

The honest limit: cost rides usage — at this altitude you pay full price on every run. That isn’t a rebuttal, it’s why Part 2 exists: compiling the stable paths until they run free.

THE BUDGET OBJECTIONSEAT VS CAPACITY

And the honest half: if the hours aren’t producing gains, it really is waste. Which is an argument for measuring it — not for skipping it.

MY REQUEST OF YOU

Where to start github.com/rishidean/tutorials-agent-loop · scaffold the pattern into your own repo → ./scaffold-loop.sh

TECH REFERENCES

APPENDIX A · THE THEORY

Why it works01 / 05

that’s the skill → SKILL.md / run-qa

Why it works02 / 05

that’s the QA crew → linter · reviewer · tester

Why it works03 / 05

that’s the clean brain per sprint → roadmap.md + PROGRESS.md

Why it works04 / 05

that’s the Document step → promotes → CLAUDE.md

Why it works05 / 05

that’s why QA is a test → a test, not a vibe check

APPENDIX B · GOING FURTHER

Appendix · Going furtherThe four moves

Helicopter (this repo) → Jet (a team) → Spaceship (an org) full catalog → EXTENDING.md

Appendix · Going furtherEncode judgment · in depth

Judgment moves up a rung — you approve plans instead of writing specs. That's the Jet step.

Appendix · The principles

This is my way — the syntax will change, but these don’t.

APPENDIX C · THE FILES

APPENDIX · THE FILESFile 01 / 13

run.sh

The orchestrator — the outer loop (core trimmed for the slide; real file adds logging)

#!/usr/bin/env bash
set -euo pipefail
MAX=4; n=0
# planted mode: DEMO_MODE=planted swaps in a buggy build
# (fixtures/index.sprint2-buggy.html) before Sprint 3 so QA goes RED

echo "THE LOOP — starting..."
cat roadmap.md

while grep -q '^- \[ \]' roadmap.md && (( n < MAX )); do
  n=$((n+1))
  echo "SPRINT $n — launching fresh session..."
  claude -p "$(cat prompt.md)" \
    --dangerously-skip-permissions \
    --model opus \
    || { echo "session error"; break; }
  cat roadmap.md
  if grep -q '^- \[!\]' roadmap.md; then
    echo "BLOCKED — human needed."; break
  fi
  echo "Sprint $n complete."
done

echo "DONE — $n sprint(s) attempted"
cat PROGRESS.md

Appendix · The FILESFile 02 / 13

CLAUDE.md

Broad context — true for every sprint

# Click Farm

## Identity & Mission
You maintain the Click Farm game. Done = the feature
works, QA is GREEN, nothing else broke.

## Map
One index.html (inline CSS + JS). State lives in
localStorage. Specs are in specs/.
State: localStorage key clickfarm = { score, farmhands }.
Stable ids: #score, #harvest, #hire, #farmhands, #cost.

## Conventions
Vanilla HTML/CSS/JS — no frameworks, no build step.
Mobile-first, system fonts, one accent color.

## Running it
Open index.html in a browser to play. run-qa to check.
No package manager.

## Guardrails
Never add dependencies or a build tool. Don't edit
other sprints' specs. Ask before changing the schema.

## Definition of Done
Not done until run-qa returns GREEN.
If RED, read it, fix it, re-run. Never ship on RED.

Appendix · The FILESFile 03 / 13

prompt.md

Marching orders — read at every session start

# Sprint Turn
Read roadmap.md and pick the first sprint marked [ ].
Read that sprint's spec and PROGRESS.md for context.

Build the feature per the spec.
Then run the run-qa skill until GREEN (max 3 attempts).

When GREEN:
- Mark the sprint [x] in roadmap.md.
- Append a handoff to PROGRESS.md: what you built,
  key decisions, gotchas, what the next sprint needs.

If you can't reach GREEN after 3 attempts:
- Mark the sprint [!] in roadmap.md, then stop.

Updating the status is your final action — never skip it.

Appendix · The FILESFile 04 / 13

roadmap.md

The manifest — three characters per line

# Click Farm — Roadmap

- [ ] Sprint 1: Core clicker — harvest + persistent score    — specs/sprint-1.md
- [ ] Sprint 2: Farmhands — buy auto-harvesters             — specs/sprint-2.md
- [ ] Sprint 3: Scaling cost — price curve + spend guard    — specs/sprint-3.md
- [ ] Sprint 4: Polish — number formatting + click pulse    — specs/sprint-4.md

Appendix · THE FILESFile 04 / 13 · at scale

roadmap.md

One file, nested — Epics → Sprints → Features

Appendix · The FILESFile 05 / 13

PROGRESS.md

The memory — the Builder writes it, sprint by sprint

# Progress Log

APPENDIX · THE FILESFile 06 / 13

specs/sprint-1.md

Core clicker

# Sprint 1: Core Clicker

## What to build
A big Harvest button. Clicking it adds 1 to the
score. Score persists across reloads.

## Acceptance Criteria
- Clicking #harvest increases #score by 1
- #score persists after a reload (localStorage)
- Score is a non-negative integer

## Technical Notes
- Single index.html, inline CSS + JS
- localStorage key "clickfarm" → { score, farmhands }
- Stable ids: #score, #harvest

APPENDIX · THE FILESFile 07 / 13

specs/sprint-2.md

Farmhands — buy auto-harvesters

# Sprint 2: Farmhands (auto-harvest)

## What to build
A "Hire Farmhand" button (cost 10). Hiring deducts
10 and adds a farmhand. Each farmhand earns
+1 score/sec automatically.

## Acceptance Criteria
- #hire with score ≥ 10 deducts 10 and adds a #farmhands
- With ≥1 farmhand, #score rises ~1/sec on its own
- #cost shows the hire cost (10)

## Technical Notes
- New ids: #hire, #farmhands, #cost
- setInterval 1000ms; persist state on each tick

APPENDIX · THE FILESFile 08 / 13

specs/sprint-3.md

Scaling cost — QA catches the bug

# Sprint 3: Scaling Cost

## What to build
Farmhands get more expensive the more you own.
cost = floor(10 * 1.15 ^ farmhands). #cost
shows the NEXT price, updates after each hire.

## Acceptance Criteria
- #cost increases after each hire (per the formula)
- When score < cost, clicking #hire does nothing
  (score & farmhands unchanged)
- Score never goes negative; hiring at score == cost succeeds

## Technical Notes
- Integer math, Math.floor
- Guard lives in the acceptance test; the bug is
  planted via the fixture swap, not the spec

APPENDIX · THE FILESFile 09 / 13

specs/sprint-4.md

Polish — formatting + feedback

# Sprint 4: Polish

## What to build
Number formatting + click feedback.

## Acceptance Criteria
- Score ≥ 1000 shows abbreviated (1.2K / 3.4M / 5.6B);
  below 1000 shows the integer
- Same formatting on #cost
- Underlying state stays an exact integer (display-only)
- #harvest pulses briefly on click

## Technical Notes
- Format on display only — never round the stored value

APPENDIX · THE FILESFile 10 / 13

.claude/skills/run-qa/SKILL.md

run-qa — the quality gate

---
name: run-qa
description: Full QA pass — lint, review, e2e.
  Returns one GREEN/RED verdict.
---

# run-qa
Run these in order. Each is a subagent; use its
returned message as the result.

1. Delegate to linter.
2. Delegate to code-reviewer.
3. Delegate to playwright-tester.

Verdict:
- Any lint error, any CRITICAL finding, or any
  failed spec → RED. List what failed.
- Otherwise → GREEN.

If RED: fix the issues, re-run from step 1.
Stop after 3 attempts; then report to the human.

APPENDIX · THE FILESFile 11 / 13

.claude/agents/linter.md

Subagent 1 — structure & syntax

---
name: linter
description: Validates HTML structure and JS errors.
tools: Read, Edit, Bash    model: haiku
---

Run validation on index.html:
1. Check HTML is well-formed (tags, nesting)
2. Run node --check on inline script content
3. Check for unclosed strings, missing semicolons,
   undefined variables

Auto-fix trivial violations (formatting, whitespace).
For judgment calls, leave it and report it.

Return "CLEAN" if no errors remain, else the list
of remaining errors with location.

APPENDIX · THE FILESFile 12 / 13

.claude/agents/code-reviewer.md

Subagent 2 — bugs & logic

---
name: code-reviewer
description: Reviews changes for bugs and UX issues.
tools: Read, Grep, Glob    model: sonnet
---

Review index.html against the sprint spec.
Do not change any files.

Check for:
- Logic bugs (especially localStorage read/write)
- State issues (stale data, race conditions)
- UX problems (unaffordable hires, negative balances)
- Missing acceptance criteria

Return findings as:
- CRITICAL — bugs, data corruption, broken function
- WARN — likely problems, edge cases
- NIT  — style, naming
For each: the issue + a one-line fix. Else "CLEAN".

APPENDIX · THE FILESFile 13 / 13

.claude/agents/playwright-tester.md

Subagent 3 — behavior & acceptance

---
name: playwright-tester
description: Runs behavioral tests against the app.
tools: Read, Write, Bash    model: sonnet
---

Write and run a Playwright test for the sprint's
acceptance criteria.
1. Create tests/click-farm.spec.js from the sprint spec
2. Open index.html via file:// or a local server
3. Test each acceptance criterion

Key scenarios for Sprint 3:
- Click → score increments
- Hire with enough score → cost deducted, +1 farmhand
- Hire when you can't afford it → blocked, no change
- Hire at score == cost → succeeds, score ≥ 0
- Score never goes below 0
- State persists across refresh

Return "GREEN" if all pass, else "RED" plus, per
failure: test name, failed assertion, actual result.

APPENDIX D · OBJECTIONS

Appendix · ObjectionsFair questions · 1 of 2

If you don’t trust the model — good. Neither does the harness. Your distrust is load-bearing: it’s called the QA gate.

APPENDIX · OBJECTIONSFAIR QUESTIONS · 2 OF 2

Receipts, if pressed: the Bun port — a year of work in eleven days, in public · the fan-out-and-verify diamond running in production inside Claude’s research feature · three communities converging on file-based state and deterministic gates without ever meeting.