Loop Engineering: How to make your AI agent run itself

You are the bottleneck. Not the model

Most people use a coding agent the same way: type a request, watch it work, read the diff, type the next request. You are sitting in the chair the whole time. The agent is brilliant for thirty seconds and then waits for you.

That is hand-operating a tool that should run itself. The people getting real leverage out of these tools stopped doing it.

They built a loop: a small system that finds the work, hands it to the agent, checks the result against a goal, writes down what it learned, and decides the next move. They set it up once. After that, the loop sits in the chair, not them.

The gap between you and them is not a smarter model or a secret prompt. It is twelve moves, in three tiers: decide if you even need a loop, build the core, then make it safe and compounding. Every part here uses pieces you already have.

Save this. You will read it twice.

TIER 1 - Decide before you build

1. The shift: you stopped being the operator

For two years the job was operating the tool by hand. Better prompts, better context, better one-shot output. That phase is ending.

The new job is one floor up: designing the system that decides what the agent works on, when, with what check, and what it remembers between runs. You are not writing the next message anymore. You are building the thing that writes it.

If you remember one line: a loop is just a prompt the system sends instead of you.

2. The 4-condition test (run it before you build anything)

A loop is not always worth it. It earns its cost only when all four are true. Miss one and it costs more than it returns.

• The task repeats. A loop amortizes its setup over many runs. For a one-time job, a good prompt is faster and cheaper. If it doesn’t recur, you don’t have a loop, you have a script you ran once.

• Verification is automated. Something has to fail the work without you in the room: a test, a type check, a linter, a build. No automated gate and you’re back in the chair reading every diff, which is the exact job the loop was supposed to remove.

• Your budget can absorb the waste. Loops re-read context, retry, and explore. That burns tokens whether or not a run ships anything. Free on an unmetered plan, painful on a $20 one.

• The agent has real tools. Logs, a way to run the code it writes, and see what breaks. Without that, the loop iterates blind.

If you fail one of these, the honest answer is: don’t build a loop yet. A single well-aimed prompt still wins for one-off and judgment-call work.

3. Know which jobs to hand it

Good first loops are boring and machine-checkable:

• CI failure triage: nightly, classify failures, draft fixes for the easy ones.

• Dependency bumps: weekly, test compatibility, open PRs.

• Lint-and-fix passes on every PR.

• Flaky-test reproduction: loop until a theory survives.

Bad first loops need a human in the chair: architecture rewrites, auth or payments code, production deploys, anything where “done” is a judgment call. Keep the loop on small changes a test suite can reject.

TIER 2 - Build the core

4. Get one manual run reliable first

A loop multiplies whatever is underneath it. Wrap one around a weak setup and you don’t get autonomy, you get slop produced faster.

So before you automate anything, make a single manual run solid. The standing facts in a CLAUDE.md, the right tools connected, a clear thing to verify against. The loop reuses all of it on every iteration, so every weakness gets multiplied by however many times it runs. Fix the run first. Then loop it.

5. Give it a goal and an independent grader

A loop needs a stop condition that is not “the agent feels done.” A goal gives you one: an objective the loop iterates against until an independent check says it’s met.

/goal All tests pass and lint is clean. Triage failures, draft fixes, repeat until the goal holds.

The key word is independent. The thing that decides “done” must not be the thing that did the work. That one separation is what makes a loop trustworthy instead of a machine that congratulates itself.

**6. Split the maker from the checker

**

Why a separate grader beats self-review is structural, not effort. A model judging its own output sees its own reasoning and prefers conclusions that match what it already wrote. A fresh agent, with its own clean context, sees only the artifact and the standard. It has no stake in the maker’s choices.

So define the verifier as a subagent:

You did not produce this work. Check it against the goal and the project rules. Run the tests yourself. Report pass or fail with concrete reasons and file references. Do not be generous.

Now the loop has a maker and a checker, and the checker holds the gate.

7. Put it on a timer, then in the cloud

A goal-driven run still waits for you to start it. Add a cadence. A recurring loop reruns the prompt on an interval, so the agent chips away at a backlog instead of waiting for a human.

/loop 30m Pull new failing tests, draft fixes in claude/ branches, hand each to the verifier. /goal main is green.

Then take your laptop out of it. Cloud routines run a saved config on managed infrastructure on a schedule or an event, with your machine closed. A timer turns a run into a habit. The cloud turns the habit into infrastructure.

8. Give it a memory that resumes

This is the step that turns a configured loop into a system that improves. The agent forgets everything between runs. The loop does not have to. A state file records what was tried, what worked, what failed, and what became a rule.

State - payments-service

Verified facts

• Webhook secret is in STRIPE_WEBHOOK_SECRET, not the dashboard.
• prc column is integer cents. Confirmed via SELECT MIN/MAX.

Lessons learned

• e2e checkout flakes on a webhook race. Add a settle delay in tests.

Last run

2026-06-22 - 3 fixes merged, 2 escalated. Next: verify the rate-limit fix.

Two rules make it compound instead of just grow: write to it before the run ends, read it at the start of the next. Skip either and tomorrow restarts from zero.

TIER 3 - Make it safe and compounding

9. Distill lessons into skills

A state file is project memory. It dies with the project. The lessons that are general, the ones that would help on the next project too, graduate into skills: procedures the agent runs, sharpened every time they fail in a new way.

Known failure modes

• tls-handshake: Windows runners fail TLS 1.2 in PowerShell. Use bash.
• db-migration: ALTER on tables over 1M rows times out. Batch in 10k chunks.

Anti-patterns

• Never disable a failing test to make CI green. File it instead.

When a loop hits a wall, the lesson goes into the skill, and every future loop on every future project inherits it. That’s the difference between an agent that re-derives your setup each time and one that stands on everything it learned before.

10. Make it fail safe with guardrails

An unattended loop is also an unattended attack surface. No one is watching each step, so the rails are not optional. A hook is a wall the model cannot talk its way past.

{ “permissions”: { “allow”: [“Read(*)”, “Bash(npm run test *)”], “deny”: [“Bash(git push origin main)”, “Bash(rm *)”, “Edit(.env)”] }, “hooks”: { “PreToolUse”: [ { “matcher”: “Bash”, “hooks”: [ { “type”: “command”, “command”: “./.claude/hooks/block-dangerous.sh” } ] } ] } }

A loop that runs unattended and cannot do anything irreversible is one you can actually leave alone. Keep a human on the merge button and anything that can’t be undone.

11. Route the work by cost

An always-on loop on the top-tier model for every step bleeds money on work a cheaper model would do fine. Route it: the orchestrator on the heavyweight model, the high-volume passes on cheaper ones, a fallback for tasks the top tier declines. The verifier and simple classifiers can run cheap. Save the expensive model for the hard reasoning.

12. Track one number, and know how loops die

The only metric that matters is cost per accepted change. Not tokens spent, not tasks attempted, not loops scheduled. If you’re accepting less than half of what the loop produces, you’re doing the review work it was supposed to save, and it’s losing.

The three ways loops die quietly:

• The Ralph Wiggum loop. It calls a half-done job finished because “done” was the agent’s opinion, not a test. Fix: a real gate that can fail the work.

• Goal drift. Over long runs the original constraints fade. The “don’t touch billing” rule disappears around turn 47. Fix: a standing spec the agent rereads each run.

• Comprehension debt. The faster the loop ships code you didn’t write, the larger the gap between what the repo contains and what you understand. Fix: read the diffs, keep the loop on small changes, and never let it touch architecture.

The mistakes that turn loops into money pits

• Skipping the 4-condition test. Most people fail at least one and build anyway.

• No objective gate. A second agent asked to “review” with no test is just a second optimist.

• One agent doing both the work and the verification. It always gives itself an A.

• No state file, so every run restarts from zero.

• No hard stop, so the loop runs until you notice the bill.

• Broad permissions on an unattended loop. The denies and hooks are not optional.

• Top-tier model on every iteration. Route by task or it bleeds money.

The point

A prompter has a powerful tool and operates it by hand. A loop designer builds a system that operates itself and only calls them in for the parts that need a human: the goal, the standard, the merge button, anything irreversible.

The move from one to the other is a sequence, not a secret: see the agent as a loop, make one run reliable, give it a goal and an honest grader, put it on a timer, then teach it to remember and to fail safe. The model at the center never changes. Everything that improves is the loop you wrapped around it.

Pick the one step you’re not doing yet, probably an independent grader, a state file, or a single safety hook, and add it today. Then the next. Stop operating it by hand. Build the loop.

If this helped, follow me. I break down AI tools and prediction markets every week, no fluff.