Level 7Lesson 63โฑ๏ธ 45 min

The Minimum Viable Loop

Put the pieces together into the smallest loop that actually works - and learn the one order of operations that prevents most failures

Resist the Urge to Build a Robot Army

You now know all five building blocks plus the state file. The temptation is to wire them all into a giant multi-agent swarm on day one. Don't. The number-one rule of your first loop is: build the smallest one that works. A Minimum Viable Loop (MVL).

Why small wins: a tiny loop is easy to understand, cheap to run, and easy to fix when it misbehaves. A huge one is a mystery box that burns money in ways you can't trace. You can always add pieces later - you can rarely debug complexity you added too early.

The Four Pillars of a Minimum Viable Loop

An MVL needs just four things, in a straight line:

   AUTOMATION        SKILL           STATE FILE         GATE
   (the heartbeat) โ†’ (the project  โ†’ (the memory of  โ†’ (the automatic
    runs on a         knowledge,      what's done       checker that
    schedule)         a SKILL.md)     so far)           rejects bad work)

   "every morning" โ†’ "here's how โ†’ "resume where โ†’ "tests must pass
                      we triage"     I left off"        before it counts"

That's it. One trigger, one skill so the agent knows your project, one file so it remembers, and one objective gate so "done" means something. Worktrees, connectors, and extra sub-agents are upgrades you add after this works.

The Order of Operations (Don't Skip This)

This is the most practical thing in the whole level. Build your loop in this exact order. Skipping straight to the end is the number-one reason loops fail in production.

1 - Make it work manually, 100% reliably

First, do the task by hand-prompting the agent until it works every time. If you can't do it reliably by hand, a loop won't magically fix that - it'll just fail faster and more often.

2 - Write it down as a Skill

Capture that reliable manual process into a single static SKILL.md. Now the knowledge lives outside your head.

3 - Wrap it in a loop

Run the skill inside a loop with a state file and a gate - but still kick it off yourself and watch it.

4 - Only now, schedule it

Once it runs cleanly under your eye, put it on a schedule to run unattended. Automating something you haven't watched work is asking for a quiet disaster.

One line to tattoo on your brain: manual โ†’ skill โ†’ loop โ†’ schedule. In that order, every time.

One Loop, Start to Finish

Here's what a complete, modest morning loop looks like in plain English:

7:00am - the automation wakes up on the repo.
  โ†’ It runs the "CI triage" skill: read last night's test
    failures, the open issues, and recent commits.
  โ†’ It writes what it finds into STATE.md.
  โ†’ For each easy, machine-checkable failure, it drafts a fix
    in an isolated worktree.
  โ†’ A checker sub-agent reviews each draft against the tests.
  โ†’ The gate runs the tests - only passing fixes count as "done".
  โ†’ A connector opens a draft PR and posts a summary to Slack.
  โ†’ Anything it can't safely handle is left in your inbox.

You: review the finished drafts over coffee. You never typed
     a single prompt during any of it.

You designed that once. Every block you learned shows up exactly once. That's a real loop - and notice it's still small enough to understand in one read.

The Only Metric That Matters

How do you know if your loop is actually helping? Not by tokens spent, tasks attempted, or loops scheduled. The one true measure is Cost per Accepted Change - how much does it cost to produce a change a human actually accepts and merges?

The 50% rule: if humans accept fewer than half of the loop's pull requests, you're spending more time reviewing junk than the loop saved you. At that point the loop is losing you money and time - fix it or shut it off. A loop that produces work people throw away isn't a productivity tool; it's an expensive distraction.

Hands-On: Sketch Your MVL

Hands-on (20 min): On one page, draw your Minimum Viable Loop using the four pillars: name your automation (when it runs), your skill(the SKILL.md you drafted in Lesson 59), your state file (the STATE.md from Lesson 62), and your gate (the exact automatic check that decides "done"). Then write the order you'll build it in: which step are you on right now - manual, skill, loop, or schedule? Be honest. Most people discover they're still on step 1, and that's the correct place to be. This sketch is the core of your capstone.
Lesson 63 Quick Reference
Minimum Viable Loop (MVL)

The smallest loop that works: one automation + one skill + one state file + one gate

Build order

manual โ†’ skill โ†’ loop โ†’ schedule; skipping ahead is the #1 cause of loop failure

Make it reliable by hand first

If you can't do the task reliably by prompting, a loop won't fix it - it'll fail faster

Start small

Add worktrees, connectors, and extra sub-agents only after the MVL works

Cost per Accepted Change

The only metric that matters - cost to produce a change a human actually merges

The 50% rule

If under half the loop's PRs are accepted, it's costing you more than it saves

โ† The State File - Memory That Lasts
Unlocks in ~12 min of reading