LOOP ENGINEERING
M~ hands over one task line. The loop asks its questions, compiles a refined prompt spec, then runs the work step by step, verified, until it's done — the Karpathy autoresearch pattern, pointed at the estate.
Where the pattern comes from
Karpathy's autoresearch, posted to X in March 2026: a nanochat LLM training core stripped to a single GPU, ~630 lines, one file. The division of labor is the whole idea:
The agent works an autonomous loop on a git branch: edit the code, run a fixed 5-minute training, check one number (val_bpb, lower is better), keep the commit if it improved, revert if it didn't, log every attempt, repeat — ~12 experiments per hour, roughly 100 overnight. Two days of it produced ~700 experiments and ~20 kept improvements worth an 11% training speedup on the big model.
The part M~ asked for lives in the setup phase, before the loop starts: agree the run tag, cut the branch, read the in-scope files, confirm — "Once you get confirmation, kick off the experimentation." Karpathy's human-side craft object is the prompt file itself (program.md), and the repo's own bound is stated plainly: if you can't evaluate it, you can't auto-research it. That is why this loop begins with questions — the questions are how the prompt gets iterated before any work runs.
| autoresearch (Karpathy) | This loop (M~ estate) |
|---|---|
| Human iterates on program.md | Agent asks 3–5 questions, compiles a refined task spec for M~ to confirm |
| Agent edits train.py | Agent runs work step-by-step in scratch, nothing touches live estate mid-loop |
| Fixed 5-min training run + val_bpb | VERIFY check per step (command / number / checklist) |
| Commit kept if better, else git reset | Winners advance; losers revert, logged keep/discard/crash |
| ~100 experiments run while asleep | Full deliverable + audit trail by morning on overnight tasks |
| NEVER STOP until human interrupts | Same: loop runs to done / budget / gate-pending / interrupt |
The loop, end to end
TASK → QUESTIONS → REFINED PROMPT → STEPS → VERIFY → DELIVER, with the two human veto gates marked on the irreversible exits. This is M~'s loop, built from Karpathy's mechanics:
Gate 0 is the spec confirm — M~ edits or ships the refined prompt before any work runs. Gate 1 is the irreversible step: the loop stages it (file, message, payment-ready state) and waits for fire / amend / kill. Everything reversible runs free.
Stage 1–2 · Spin up + ask
M~ gives one raw line — from a Cockpit registry row, typed in chat, or a standing cron task. Intake captures it as-is: no cleanup, no invented parameters. The agent reads scope, ambiguity, and stakes out of the raw line, then asks its question round before any work begins.
Karpathy parallelThe human owns the prompt, not the code
In autoresearch, the human's one craft object is program.md — "a super lightweight skill". He never touches the Python. Here: M~ never has to write the brief himself. The question round is the prompt iteration — the agent turns one vague line into an executable spec, which M~ confirms or edits at Gate 0.
Source: program.md — "This is an experiment to have the LLM do its own research"
| Question class | What it nails down | Sample for a real row |
|---|---|---|
| Goal | What "done" looks like, single metric if possible | "Insurance pack: terminate 3 legacy plans?" |
| Scope | Files/rows/accounts in, which out | "Only the 3 legacy plans, or new ones too?" |
| Constraints | Deadline, budget cap, blocked paths | "Must close before the next premium date" |
| Verification | The objective check that settles "correct" | " insurer confirmations PDF-ed + logged?" |
| Budget | Step/token/time cap + expiry date | "Run before 28 Oct expiry on one plan" |
Stage 3 · The refined prompt spec
The answers compile into a 5-field task spec — the loop's contract, M~'s program.md analog:
"if you can't evaluate it, you can't auto-research it" — the bound Karpathy states in program.md. VERIFY is the field the whole loop stands on: every discipline in Stage 4 keys off it.
Stage 4–5 · Run + verify, keep or discard
Karpathy's loop, translated: work in small verified steps on a scratch copy, log every attempt, never stop — until done, budget, gate, or interrupt:
What this loop does well
Verified strengths, straight from where the pattern has already been proven:
| What it does well | Why it holds | Evidence |
|---|---|---|
| Runs unattended for hours | The loop is closed and bounded: fixed budget, single metric, and nobody needs to be in it after Gate 0. | ✅ ~100 experiments ran overnight in Karpathy's run; 700 in 2 days |
| Keeps quality high while you sleep | Winners keep, losers revert. Every step is checked — there is no "hope it works" state. | ✅ 15 of 83 kept in Karpathy's sample session (≈18% pass rate) |
| Verifies cheaply every cycle | Work is checked by running a command/number/checklist — not by asking anyone. The cost of finding a win is high; the cost of checking one is near zero. | ✅ val_bpb mechanics, per program.md |
| Refines the prompt instead of the work | One round of questions up front, then confirmation, gets more out of the loop than any mid-run tweak. | ✅ Karpathy's own design: human iterates on prompt.md, not the code |
| Leaves a full audit trail | Every attempt — keep / discard / crash — is logged with reason. The trail is the reviewable memory of the run. | ✅ results.tsv: commit / metric / status / description |
| Composes into swarms | Chief-scientist-in-plan-mode + workers, or N loops on N branches — the pattern scales by spawning, not rewriting. | ✅ Karpathy's HN note on plan-mode + tmux workers; swarm analogy: commits as blocks. |
| Stays outside the loop (always M~) | Why |
|---|---|
| Money movement | Payments, transfers, premium terminations, subscription cancels — any financial-irreversible action |
| Sends | Anything that leaves the machine with M~'s name on it: email, Telegram, insurer/agent mail, posts |
| Deletes | Destruction of files, records, accounts, or anything unrecoverable |
| Legal / contractual effect | Signatures, commitments, terms acceptance — anything with legal consequence |
Deliverable + audit trail + stops
What M~ gets when a run ends — the same shape as waking to a finished autoresearch run:
| Stop condition | What happens |
|---|---|
| Deliverable accepted | Loop closes clean: artifact delivered, trail sealed, spec updated |
| Budget or expiry hit | Loop stops, reports where it stopped + what's next — never thrashes past its budget |
| Gate pending | Loop halts at the gate, everything staged, resumes the instant M~ answers |
| M~ interrupts | Karpathy: "The loop runs until the human interrupts you — period." That interrupt is always live. |
How to run it
The pattern is live in this estate already in pieces: cron jobs spin up work, decision inbox collects answers, deploy scripts execute. Loop engineering binds them with the four primitives the 261015 one-pager found missing:
| Primitive | Where it lives | Status |
|---|---|---|
| Task intake (raw line → scope/ambiguity/stakes read) | Intake on new tasks, Cockpit rows, cron task text | Spec'd — not yet live |
| Question round (3–5 numbered, options offered) | Runs at start of any new loop; on every "decide" row | Spec'd — not yet live |
| 5-field spec (goal/scope/constraints/verify/budget) | Task header; rides the audit trail | Spec'd — not yet live |
| Gate protocol (stage → ask → resume) | Any irreversible exit inside a run | Spec'd — not yet live |
Sources
Loop mechanics extracted 17 Oct 2026:
program.md — the canonical loop protocol
@karpathy X, 7 Mar 2026 — "the human iterates on the prompt, the AI agent iterates on the training code"
@karpathy X, 8 Mar 2026 — 700-experiment results post
HN thread — Karpathy on chief-scientist plan mode + swarm extensions
Internal: 261015-loop-engineering one-pager (dsk26); Cockpit registry + cron design (cckp26)