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).
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.
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.
Capture that reliable manual process into a single static SKILL.md. Now the knowledge lives outside your head.
Run the skill inside a loop with a state file and a gate - but still kick it off yourself and watch 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 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?
Hands-On: Sketch Your MVL
The smallest loop that works: one automation + one skill + one state file + one gate
manual โ skill โ loop โ schedule; skipping ahead is the #1 cause of loop failure
If you can't do the task reliably by prompting, a loop won't fix it - it'll fail faster
Add worktrees, connectors, and extra sub-agents only after the MVL works
The only metric that matters - cost to produce a change a human actually merges
If under half the loop's PRs are accepted, it's costing you more than it saves