Building Block 1 & 2 - Automations + Worktrees
The heartbeat that makes a loop run by itself, and the trick that lets many agents work at once without stepping on each other
The Five Building Blocks (Your Map)
Every loop is made of the same five pieces, plus a memory. We'll take them one or two at a time. Here's the whole map so you always know where you are:
1. Automations ← the heartbeat (this lesson) 2. Worktrees ← parallel without chaos (this lesson) 3. Skills ← write down project knowledge (next lesson) 4. Connectors ← touch your real tools 5. Sub-agents ← one makes, one checks + State file ← the memory that outlives the chat
Block 1 - Automations: The Heartbeat
An automation is what turns "a thing you did once" into "a thing that keeps happening." It's the heartbeat - everything else in the loop hangs off it. An automation fires on a schedule (every morning), on an event(someone opened a pull request), or on a condition.
Think of it like an alarm clock for your agent. You set when it wakes up and what it does when it does.
Two Kinds of "Keep Going": /loop vs /goal
There are two flavors of automation, and the difference matters a lot:
"Do this every 30 minutes (or every morning), no matter what." Good for regular health checks. It runs on a clock.
"Keep going until all the auth tests pass and the linter is clean." It doesn't stop on the clock - it stops when a goal is actually met. Crucially, a separate, smaller AI checks whether the goal is met, so the agent that wrote the code isn't the one grading its own homework.
Example of combining them: > /loop 30m /goal All tests in test/auth pass and lint is clean. Scan src/auth for new failures, propose fixes in a branch, open a draft pull request when the goal holds. Translation: "Every 30 minutes, look at the auth code. Keep working until the tests pass AND the linter is clean - and let a different checker decide when that's actually true."
Block 2 - Worktrees: Parallel Without Chaos
The moment you run two agents at once, a new problem appears: they both try to edit the same files and collide - exactly like two people editing the same paragraph of a document at the same time and overwriting each other.
The fix is a git worktree. In plain terms: it's a separate working copy of your project, on its own branch, that still shares the same project history. Each agent gets its own clean room to work in, so their edits physically cannot touch each other's.
WITHOUT worktrees WITH worktrees
───────────────── ──────────────
Agent A ┐ Agent A → copy A (branch A)
├─ same files → 💥 Agent B → copy B (branch B)
Agent B ┘ collision! ...no collision, merge laterThe Real Ceiling: You
Worktrees remove the mechanical collisions, so you can run ten agents at once. But should you? Each one produces work that you still have to review. Your review bandwidth - not the tool - is the true limit on how many parallel loops make sense.
Hands-On: Write Your Heartbeat in English
WHEN: __________ (a schedule like "every morning at 7am",
or an event like "when a PR is opened")
DO: __________ (the one job, e.g. "scan last night's
test failures and draft fixes")
UNTIL / STOP: ____ (a /goal condition like "tests pass",
plus a hard cap like "max 20 minutes")The heartbeat: fires on a schedule, an event, or a condition and kicks off the loop
Runs on a cadence ("every 30 min"), regardless of state
Runs until a condition is true; a separate small model verifies "done"
The thing that decides "done" should not be the thing that did the work
A separate working copy on its own branch - a clean room so parallel agents don't collide
Worktrees let you run many agents, but your ability to review caps how many you should