Guardrails, Queues & Self-Improving Loops
Keep a loop safe and cheap, build your first one today, and reach the top of the ladder — loops that improve themselves.
Scale it as a queue
The reframe that scales: don't picture one process spinning forever — picture a backlog of tickets, each pulled by an away-from-keyboard worker, implemented, committed, and crossed off. The loop stops when the backlog is empty.
Give each ticket its own git worktree and its own agent, and several workers drain the queue at once without stepping on each other. This also kills the single-long-session anti-pattern — many short, focused runs keep every task inside the model's smart zone.
Guardrails: bound cost and blast radius
Two failure modes to contain: a loop that spends forever producing slop, and a loop that does something destructive. Guardrails belong inside the loop, not after the pull request.
Hard ceilings on tokens, dollars, or iterations. Pause before burning more.
Run in a container with least privilege. The cautionary tale for an un-sandboxed loop: "you wake up to an empty home folder."
The first runs, the loop pauses for approval at every step — "quick check before I burn the tokens" — until you trust it. Then turn it off.
Every shortcut you catch the agent taking, ban it with a rule. Each guardrail prevents that regression forever after.
The shape to remember: human-in-the-loop at the edges, away-from-keyboard in the middle. Humans gate intake (is the spec right?) and review (read the diff); the agent runs unattended only in between. Prod, money, and database writes always need a human.
Build your first loop today
Start small and follow skill-driven loop development:
and proved works — that's your candidate, because you have the battle-tested skill behind it.
Repeats? Clear done? Affordable? Has the tools? Pass all four, proceed.
Trigger, execution skills, goal + verification, output + memory — invoked by one command.
Verify it does the right thing while it pauses for approval; then unattend it. Add a memory file from day one.
The top of the ladder, and the principles
The most advanced loops don't just produce output — they improve their own harness. After each run they generate why something failed (root cause), not just which test failed. Every caught shortcut becomes a permanent rule. It's the "if someone keeps stealing your bike, buy a lock" instinct, automated — the loop notices the recurring failure and adds the guardrail itself.
1. Separate the maker from the verifier. 2. State lives outside the model — files, git, notes. 3. A loop is a queue with a stop condition. 4. Translate fuzzy goals into measurable gates before looping. 5. Two-tier verification — LLM judge for intent, deterministic gate for correctness. 6. Bound cost and blast radius up front. 7. Ratchet, don't patch — every caught shortcut becomes a permanent rule.
Check yourself
Last three. Then go build one.
You're deciding where humans should sit in an otherwise-autonomous loop.
The right placement is…
You keep catching the loop disabling a flaky test to make the build green.
The durable fix is to…
You're picking your very first task to turn into a loop.
Choose…
Pick the smallest task you've already done by hand twice. Write down its definition of done as a number or a pass/fail. Bundle it into one orchestration skill with a budget cap and a memory file, run it in training mode once, then let it go. That's loop engineering — start there.