ESCAPE VELOCITY · SESSION 2 HANDS-ON WORKSHOP · SUMMER 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/pedal

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/pedal

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

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.

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.

One glyph per sprint — that's your state machine. The glyph flips after each sprint. Stuck work marks ⛔ and stops.

How to decompose · docs/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 · S2-Ride-Request.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 adds logging and scopes the count to the Sprints section.

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  ·  THREE SPRINTS

// back in a few

STEP 3 · WATCHSTEP 3 / 4

STEP 4 · PLAYSTEP 4 / 4

$ npm run dev # then open localhost:5173 — add ?demo=1 for the ride controls

DEBRIEF

The keynote’s thesis, running: specs made intent executable; the gate kept execution governed.

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.

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/pedal · 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 → docs/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
# PEDAL outer loop. Dumb on purpose: all the
# intelligence is in the files it reads.
set -euo pipefail
MAX_TURNS="${MAX_TURNS:-4}"
# DEMO_MODE=planted swaps the S2 matching fixture first

for turn in $(seq 1 "$MAX_TURNS"); do
  if grep -q '⛔' docs/Roadmap.md; then
    echo "blocked (⛔). A human steps in. See PROGRESS.md."
    exit 1
  fi
  remaining=$(sed -n '/## Sprints/,/## Current Status/p' \
    docs/Roadmap.md | grep -c '🔲' || true)
  if [ "$remaining" -eq 0 ]; then
    echo "every sprint is done. Take the ride."; exit 0
  fi
  echo "── Turn $turn: $remaining sprint(s) left. Fresh session."
  claude -p "$(cat prompt.md)"
done

Appendix · The FILESFile 02 / 13

CLAUDE.md

Broad context — true for every sprint

# PEDAL — Broad Context

## Product
Rider-only pedicab hailing app. Destination → estimate
(4 min · $18) → request → matching → driver assigned →
ride → pay the driver directly. Local, deterministic.

## Read order
README → Vision → FunctionalBrief → Flows →
BusinessRules → Roadmap → the active sprint spec.
BusinessRules governs behavior; Flows governs sequence.

## Technical boundary
Vite + React + TypeScript strict. Tailwind. Typed
reducer. localStorage pedal.ride.v1. Demo controls
only under ?demo=1. No backend, auth, APIs, payment.

## Operating rules
Implement only the states the artifacts define. Never
widen scope. Deterministic fixtures — never random.

## Definition of Done
Not done until run-qa returns GREEN.
Then: results record, roadmap glyph, PROGRESS handoff,
recovery commit with the spec's exact message.

Appendix · The FILESFile 03 / 13

prompt.md

Marching orders — read at every session start

# Sprint Session — Marching Orders
You are the Builder for exactly one sprint. Fresh
session, no memory; everything you need is on disk.

1. Orient — CLAUDE.md, PROGRESS.md, docs/Roadmap.md.
   Find the first 🔲 sprint. Any ⛔ → stop.
2. Read the contract — the spec, plus Flows.md and
   BusinessRules.md for anything it references.
3. Build — only what the spec defines. A missing
   product decision? Mark ⛔, name it, stop.
4. Verify — run-qa until GREEN (max 3 attempts).
   Still RED → mark ⛔ with the failing check, stop.
5. Document — Test Results Log, docs/results/,
   roadmap glyph, PROGRESS handoff, promote learnings.
6. Commit — the spec's exact message.

One sprint per session. The loop handles the next.

Appendix · The FILESFile 04 / 13

docs/Roadmap.md

The manifest — one glyph per sprint

# PEDAL Roadmap · ## Sprints — Booking

🔲 S1 — App Setup and Shell   — specs/booking/S1-App-Setup-and-Shell.md
🔲 S2 — Ride Request          — specs/booking/S2-Ride-Request.md
🔲 S3 — Ride Lifecycle        — specs/booking/S3-Ride-Lifecycle.md

S2 starts only after S1 passes. A failed sprint stays
active; the harness may not skip ahead.

Appendix · THE FILESFile 04 / 13 · at scale

docs/Roadmap.md

One file, nested — named epics, ordinal sprints

Appendix · The FILESFile 05 / 13

PROGRESS.md

The memory — the Builder writes it, sprint by sprint

# Progress Log

APPENDIX · THE FILESFile 06 / 13

specs/booking/S1-App-Setup-and-Shell.md

App Setup and Shell

# Booking S1: App Setup and Shell

## What to build
The PEDAL foundation: Vite + React + TS strict,
Tailwind visual system, mobile rider frame, static
city map, typed reducer, deterministic fixtures.

## Acceptance Criteria
- App boots to destination entry — nothing more
- State survives refresh via pedal.ride.v1
- Invalid stored state clears; never crashes
- typecheck · test:run · build · test:e2e all pass

## Technical Notes
- Demo Controls foundation behind ?demo=1
- No ride-request behavior beyond the shell contract

APPENDIX · THE FILESFile 07 / 13

specs/booking/S2-Ride-Request.md

Ride Request — the planted bug lives here

# Booking S2: Ride Request

## What to build
Destination → review → request → matching →
driver assigned. Landmark selection; canonical
estimate; deterministic 1,200 ms assignment.

## Acceptance Criteria
- Estimate shows 4 min · $18 before request
- Matching is its own visible state
- Assignment: Maya Chen · PEDAL 14 · ETA 3 min
- Every state survives refresh

## Technical Notes
- Playwright evidence through driver_assigned
- Exactly ONE matching timer may assign (BR-007) —
  the planted demo bug violates exactly this

APPENDIX · THE FILESFile 08 / 13

specs/booking/S3-Ride-Lifecycle.md

Ride Lifecycle — the epic completes

# Booking S3: Ride Lifecycle

## What to build
Driver arrived → ride in progress → ride complete →
"Pay the driver directly" → reset to a fresh ride.

## Acceptance Criteria
- Demo-mode transitions drive each lifecycle state
- $18 fare + the payment instruction at complete
- Every state restores after refresh; reset is clean
- Full end-to-end verification path passes

## Technical Notes
- Demo controls only under ?demo=1 — honest mocks
- Lifecycle transitions valid only in order (BR-008)

APPENDIX · THE FILESFile 09 / 13

docs/results/booking-s1.md

The result record — shape fixed by the spec; the run fills it in

# Booking S1 — Result Record

Outcome       Shell boots to destination entry;
              state survives refresh
Files         created + modified paths, listed
Verification  typecheck ✅  test:run ✅  build ✅  e2e ✅
              network boundary: local-origin only ✅
Deviations    any spec departure, and why it
              preserves the contract
Unresolved    None — or a named blocker, never
              a hidden TODO
Recovery      feat(booking-s1): app setup and shell
              the commit to return to

APPENDIX · THE FILESFile 10 / 13

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

run-qa — the quality gate

---
name: run-qa
description: The PEDAL quality gate. Anchors first,
  opinion second. One GREEN/RED verdict.
---

# run-qa — the gate
1. Anchors (deterministic):
   npm run typecheck · test:run · build · test:e2e
2. The crew (subagents):
   linter → code-reviewer → playwright-tester

Verdict:
- Any anchor FAIL or any CRITICAL finding → RED,
  every failure listed so the Builder can fix blind.
- WARN and NIT never block. Anchors outrank opinions.

Never weaken a check to reach GREEN. A test that
cannot run is a FAIL, not an N/A.
Three attempts, then ⛔ — a human steps in.

APPENDIX · THE FILESFile 11 / 13

.claude/agents/linter.md

Subagent 1 — structure & syntax

---
name: linter
description: Deterministic well-formedness anchor.
tools: Bash, Read, Edit, Glob, Grep    model: haiku
---

You check; you do not build.
1. npm run typecheck — record pass/fail with the
   first errors verbatim
2. npm run lint, if the script exists
3. Auto-fix only trivial formatting; anything
   needing judgment gets reported, never fixed

Report format, nothing else:
LINTER: GREEN | RED
FIXED: <files auto-fixed, or none>
ISSUES: <file:line — verbatim compiler output>

RED only for real failures: type errors, parse
errors, lint errors at error severity.

APPENDIX · THE FILESFile 12 / 13

.claude/agents/code-reviewer.md

Subagent 2 — bugs & logic

---
name: code-reviewer
description: Read-only review against the invariants.
tools: Read, Glob, Grep    model: sonnet
---

Review the sprint's diff against BusinessRules.md,
Flows.md, and the spec. Never modify files.

Hunt in priority order:
- Boundary violations — network, auth, payment,
  random values. Always CRITICAL (BR-013/014).
- Invariant violations — one matching timer (BR-007),
  lifecycle order (BR-008), fail-closed storage (BR-016)
- Persistence contract — pedal.ride.v1
- Logic bugs & unmet acceptance criteria

Return findings as CRITICAL / WARN / NIT, file:line
each. RED only when a CRITICAL exists. If the diff
is clean: GREEN, zero findings, stop.

APPENDIX · THE FILESFile 13 / 13

.claude/agents/playwright-tester.md

Subagent 3 — behavior & acceptance

---
name: playwright-tester
description: Behavioral anchor — acceptance criteria
  in a real browser.
tools: Bash, Read, Write, Edit, Glob, Grep   model: sonnet
---

Author tests for any acceptance criterion not yet
covered, then run npm run test:e2e. Deterministic
fixtures, deterministic tests — no arbitrary sleeps.

Key scenarios for Booking S2:
- Estimate (4 min · $18) shows before request
- Matching state observed BEFORE assignment
- Exactly one assignment fires (BR-007)
- Driver card: Maya Chen · PEDAL 14 · ETA 3 min
- Every state persists across refresh
- Network boundary: local-origin requests only

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 the architecture: it’s called the QA gate.

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.

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.