Owner's manual · No. 6-Part Framework

A robot that works
while you sleep

"Agent loops" sound complicated. They're not. It's a worker that repeats a job on a schedule, with an inspector checking everything and a notebook so it never forgets. Here's the whole machine, in plain English.

The big idea

An AI agent on a loop is like hiring a workshop apprentice: it wakes up on a trigger, works on a copy (never your original), follows your recipe card, gets its work checked by a separate inspector, uses real tools to deliver, and writes everything in a notebook so tomorrow it's smarter than today.

The machine

The six parts — every loop needs all of them

Part 1

The Heartbeat trigger

What wakes the machine up. A schedule ("every morning at 9"), a condition ("keep going until the tests pass"), or an event ("someone opened a pull request").

Plain English: the alarm clock. No alarm clock, no worker — it only runs when you're standing there pressing the button yourself.

Part 2

The Sandbox isolation / worktree

The agent works on its own copy of the project (a "git worktree" or separate branch) — never directly on the real thing.

Plain English: photocopy the document before handing it to the apprentice. If they ruin it, the original is safe in the drawer.

Part 3

The Recipe skill

Written instructions the agent loads automatically every run — a SKILL.md or CLAUDE.md file holding the "how".

Plain English: the recipe card taped above the workbench. Write the craft down once; every shift inherits it. No recipe = the apprentice improvises daily.

Part 4

Maker & Checker the golden rule

Two separate agents: the maker builds the thing; a different checker (read-only, or armed with tests) inspects it and answers PASS or FAIL — with reasons.

Plain English: the builder never signs off their own work. Ever. A separate inspector walks the site. Letting one agent mark its own homework is how you get confident garbage.

Part 5

The Hands connector / MCP

Integrations that let the loop act in the real world — open a pull request, post to Slack, call an API, run the test suite.

Plain English: a worker with no tools can only talk about the job. Connectors are the hands that actually deliver the parcel.

Part 6

The Spine state / memory

Files that survive between runs — a committed progress.md, shared logs, artifacts. Each run reads where the last one ended.

Plain English: the shift-handover notebook. Without it, every morning the worker shows up with amnesia and does Monday's job again forever. This is the #1 thing people forget.

How a cycle runs

The loop itself

Discoverwhat needs doing? Plansmallest safe step Executemaker works in the sandbox Verifychecker: PASS / FAIL Done / human gate or hit a cap → stop
Discover → Plan → Execute → Verify → repeat, until "done," a human gate, or a cap. Never uncapped.

Two safety rails on everything: caps (max retries, max time, max spend, max tokens — so it can't run away with your wallet) and observability (every run leaves a paper trail a human can read).

Before you build one

The pre-flight checklist

  • Define "done" in numbers before writing a single instruction — "all tests green," not "make it better."
  • Pin the checks upfront — decide what the inspector tests before the builder starts.
  • Choose the least autonomous setup that still works — boring beats clever.
  • Set the alarm clock — a trigger so it runs without you.
  • Shared folders & logs — so runs compound instead of repeating.
  • Attach the evidence — every run hands you its receipts for review.
  • Cap everything — retries, cadence, cost.
  • Start in a throwaway repo — watch the first runs like a hawk; earn trust gradually.
  • Human gates on the scary stuff — merges, anything public, anything that spends money. The robot proposes; you approve.

⚠ Failure modes

The six ways loops die

No spine

Amnesia. The loop does the same work every run and calls it progress.

Self-verifying agent

The builder grades its own homework — and always gives itself an A.

No caps

A runaway loop is a money-shredder with a schedule.

Vague "done"

If "done" isn't measurable, the loop either never stops or stops instantly.

Wrong cadence

Running every 5 minutes when daily is plenty — paying 288× for zero extra signal.

Too much trust, too soon

Autonomy is earned run by run — not granted on day one.

Worked examples

What people actually build

The overnight triage loop — every morning it pulls open issues, drafts fixes on its own copy, the inspector checks each one, only PASSes become pull requests, and the notebook is updated.

The test-fixer — run tests → read the failures → fix the cause → run again → repeat until green. The tests themselves are the inspector.

The support sorter — reads incoming tickets, answers what it safely can, logs the patterns to a shared folder, and spins up coding agents for genuine bugs.

The compounding system — several specialist loops all writing to one shared "brain," each making the others smarter. (This vault works exactly that way.)