🔁Loop engineering · stop hand-flying the AI and let it work toward the goal on its own
The final level of the series. Until now you learned the pieces: memory, GitHub, RAG, the brain, C-A-R, agent-browser. Loop engineering is the glue that turns them into an autonomous system: the AI stops being "someone on the other side of the chat" and becomes an engine that iterates on its own toward a goal. I'll walk you through the cycle, the three brakes that save you from a surprise bill, and how to set up your first loop with commands that actually exist.
Jun 23, 202613 min
Who is this for?
For anyone already building with AI who has noticed something uncomfortable: you are the bottleneck. While you're at the keyboard, the AI moves forward; the moment you step away, everything stops. This resource is the leap from "I drive every step" to "I set up a system that moves on its own." You don't need to be a programmer: you need to understand the pattern.
1. The moment: when you realize YOU are the engine
Think about how you work with AI today. You write it an instruction. You wait. You read what it did. You tell it "now fix this." You wait again. You review. "Now add that." Over and over. It works — but there's a silent problem: you are the engine of the whole thing. Your attention is the fuel. The second you get up for a coffee, the project freezes.
The loop engineering moment arrives when you think: "what if I didn't have to sit here cranking the handle at every step? What if I gave it a goal and it figured things out on its own until it was done?". That's exactly what it is. A Firecrawl article on the subject put it perfectly: with loop engineering, the AI stops being a collaborator on the other side of the chat; it becomes a function that a program calls in a loop.
Picture it like this
Until now you've been the driver: both hands on the wheel the whole trip. Loop engineering is setting a destination in the GPS and switching on autopilot: the car accelerates, watches the road, corrects course and looks again, on its own, until it arrives. You stop driving and start supervising the trip.
2. The pain: manual work doesn't scale (and it burns you out)
The pain of not making this leap is real and honest — it's not an apocalypse, it's wear and tear. These are the symptoms:
Signs that manual work is holding you back
Long tasks (auditing the whole project, researching 8 competitors, migrating 40 files) take you hours because you do them in a line, one by one.
If you leave the computer, progress stops dead. The AI doesn't keep going without you.
You repeat the same kind of instruction every day and feel like a machine operator, not a director.
You can't do two big things at once because you only have one pair of hands and one open chat.
The most common misunderstanding
A lot of people think "automating the AI" is just giving it a longer prompt. It isn't. A long prompt still needs you to hit send and review. Loop engineering is something else: it's the system deciding on its own whether to keep going or stop, without you pressing anything.
3. The heart: the Act → Observe → Reason → Repeat cycle
Every loop, however simple or complex, turns on the same four steps. Memorize them, because they're the essence of everything:
The 4 steps of any loop
Act — the AI does something (writes code, searches the web, fixes a test).
Observe — it reads the result of what it did (did the test pass? what did the search return?).
Reason — it compares that result against the goal (are we there? is something missing? is there an error?).
Repeat — it decides on its own whether to start over or whether it's done.
The difference from normal chatting is the fourth step: the AI decides whether to keep going, not you. The loop runs on its own until the goal is met or until it hits a limit you set (we'll look at those limits now — they're sacred).
Open loop vs. closed loop
There are two flavors. Open loop: you give it a goal and total freedom ("find all my competitors and score them") — powerful for exploring, but if your criteria are vague, the result comes out noisy. Closed loop: you lay out the path step by step, with how to verify each one — more predictable, cheaper, better results. In production the closed loop is used almost always.
4. The 3 sacred brakes (without them it's not a loop, it's an open tab)
This is the part NOBODY tells you and the most important one. A loop that runs on its own can spend credits on its own. Most of the art of loop engineering isn't making the AI iterate — it's stopping it from iterating forever and draining your account. There are three brakes that must ALWAYS exist:
The 3 brakes that can never be missing
Iteration cap — a maximum number of rounds. "Try it 10 times at most, then stop."
Change check (diff-check) — if after N rounds the AI is no longer changing anything, stop. It's spinning in vain.
Spend cap — a token or money limit. When it's reached, the loop ends, whether it met the goal or not.
The 4th brake almost nobody sets (and it's the most treacherous)
The three brakes above control quantity (how many rounds, how much spend). But there's a quality brake that's the one that really saves you: the anti-cheat rule. If you ask the AI to "make all the tests pass," the easiest way for it to "win" is to… delete the test, mark it as skipped, or weaken what it checks. It clears your three brakes with a green flag — and your app is still broken. ALWAYS add to your loop: "forbidden to delete, skip or weaken what's being verified to fake success; fix the real cause". This applies to any goal, not just tests.
The line you should tattoo on yourself
From the Firecrawl article, word for word: "Without the three brakes, what you're running is not a loop. It's an open tab." Before launching any autonomous loop, ask yourself: do I have the round cap, the change check and the spend cap? If one is missing, don't launch it.
The other risk: understanding debt
When the AI produces code faster than you can understand it, a dangerous gap opens: you have things in your project you don't understand. The faster the loop runs, the wider that gap gets — unless someone reviews the changes. That's why loop engineering goes hand in hand with the C-A-R protocol: the loop builds, but you (or a verifier agent) audit.
5. The habit: thinking in loops, not in loose messages
Loop engineering isn't something you do once. It's a constant shift in mindset. Every time you're about to do a task with AI, before writing the first prompt, ask yourself: "is this a loose message, or is it a loop?". Most big tasks are loops disguised as many messages.
The moments when you should ALWAYS think in a loop
When a task has a clear "done" criterion (all tests pass, 10 bugs found, the document covers every point).
When you're repeating the same cycle by hand (run → fail → fix → run again).
When the task is too big for a single pass (audit everything, migrate everything, research many sources).
When you want something to happen while you're away (check a deploy, watch a site, a daily check).
The verifier rule (the highest-return pattern)
The most profitable trick of all: separate who does and who reviews. One agent (or chain of agents) makes the changes; a different agent grades them against your rules and tests. The verifier doesn't have to be smarter — it just has to be another one, with the cool head of an auditor. It's exactly what the C-A-R protocol does: build and audit in separate turns.
6. How to set up your first loop (with commands that actually exist)
Here's the nice part: you don't have to program anything weird. If you use a modern coding agent like Claude Code, it already ships with the pieces built in. These commands are real and are in its official docs:
The loop engineering kit in Claude Code
/goal <condition> — the heart of the loop toward a goal. You set a condition and, after each turn, a fast model checks whether it's already met; if not, Claude starts another round on its own, instead of handing control back to you. It's the "work until it's green." It needs a verifiable condition (e.g. "all tests pass," "clean git status").
/loop [interval] [prompt] — repeat over time, NOT iterate toward a goal. It runs a prompt every set interval (/loop 5m check the deploy) or, with no interval, Claude picks the pace itself. Useful for watching something, not for "achieving X." Don't confuse it with /goal.
/schedule — creates routines in the cloud: scheduled tasks (every hour, every day) that run even with your laptop closed, or that react to GitHub events.
/batch — splits a big job into 5 to 30 units in parallel, each in its own subagent and its own isolated worktree; each one does its part, runs the tests and opens its own pull request. (It's the industrial version of the loop for migrations and mass changes.)
The distinction almost nobody gets
A lot of people mix up `/goal` and `/loop`, and they're different things. `/goal` iterates until a condition is met (it's the "work until you achieve it" loop). `/loop` repeats on an interval (it's the "every X minutes do this"). For "fix all the tests" you want /goal. For "watch the deploy every 5 min" you want /loop. Confusing them is beginner mistake number one.
Authority fact · where this comes from
Loop engineering wasn't invented out of nowhere. It comes from the ReAct pattern (Reason → Act → Observe, from a 2022 paper) that taught models to reason and act in a cycle. Then came Reflexion, which added a self-critique step — the agent corrects itself. The 2026 leap is duration: agents went from short chat replies to running minutes or hours on their own. Loop engineering is putting serious engineering (and brakes) on that autonomy.
And the supporting pieces that make a loop reliable also exist: worktrees (claude --worktree) so several agents can work without stepping on each other, skills (folders with a SKILL.md) so the AI doesn't rediscover your context every time, hooks to attach actions at key moments, and MCP connectors so the loop can reach external tools (Slack, GitHub, your database).
You already have almost all the pieces in this series
The best part: you're not starting from zero. Memory gives the loop state that survives between rounds. RAG / the brain gives it context. Skills encode your knowledge. GitHub gives it a safe point to fall back to. agent-browser gives it the eyes to actually observe. Loop engineering just wires all of that into a cycle. You have them all in this series — at the end I'll leave you the direct links.
7. How it's actually used: design first, then invoke the command
Here's the detail almost every tutorial skips, and it's KEY: the loop doesn't start on its own just because you describe the task. Pasting a long text saying "set up a loop that fixes my tests" makes the AI design the plan for you — but it does NOT run it. For the AI to actually start iterating, you have to type the command explicitly (in Claude Code, /goal or /loop). It's two steps: first you design, then you invoke.
The command is NOT optional
If you only describe the loop in plain language, the AI replies with the plan and stops — it waits for your go-ahead. The autonomous loop only fires when you type the command (/goal … or /loop …). That's good: it forces you to approve the design and the brakes BEFORE letting the machine loose. Design and execution are separated on purpose.
Step 1 — Design the loop. Paste this to your agent, filling in the [brackets]. It'll hand you back the plan, the brakes and — importantly — the exact command you should type afterward:
Prompt to design your first autonomous loop (with brakes)text
I want to set up an autonomous loop (loop engineering) for this task: [DESCRIBE THE TASK, e.g.: "find and fix all the failing tests" or "deeply research my 5 competitors and synthesize a report"].
My tool is: [Claude Code / Cursor / other]. Before designing, look at my project and tell me the exact command or signal that serves as the "source of truth" for this task (e.g. the real test command, or how "done" is measured). If you can't find it, ask me.
Design it with me following the Act → Observe → Reason → Repeat cycle. I need you to propose, in clear language:
1. THE GOAL: the exact and VERIFIABLE "done" condition (how we'll know the loop should stop because it genuinely met the goal).
2. WHETHER an OPEN loop (freedom) or CLOSED loop (laid-out steps) is better for this task, and why.
3. THE CYCLE: what the AI does each round (act), how it checks the result (observe), and how it decides whether to keep going (reason).
4. THE SEPARATION: one agent that DOES and a different one that VERIFIES the result (including the anti-cheat rule below).
5. THE 4 BRAKES, mandatory:
- Iteration cap (maximum number of rounds).
- Stall check (stop if it's no longer progressing after N rounds).
- Spend cap (token or time limit).
- ANTI-CHEAT RULE: forbidden to delete, skip or weaken what's being verified to fake success. You have to fix the ROOT CAUSE (the real code), not slap on a patch that silences the symptom. If a round leaves MORE broken than it fixes, revert that round.
6. THE EXACT COMMAND I SHOULD TYPE MYSELF to run it (don't run it on your own). In Claude Code: if the task is "iterate until a condition is met" use `/goal <condition>`; if it's "repeat every so often" use `/loop <interval> <prompt>`. Give me the line already written, ready to copy, with the stop condition and the brakes included. Verify that the command actually exists; don't make it up.
7. WHAT I CAN SUPERVISE while it runs, one readable line per round even though I don't program, so I don't fall into understanding debt.
First show me ONLY the complete design, the 4 brakes and the exact command to type. Do NOT run the loop: I'll fire it by typing the command once I approve the design.
Step 2 — Fire the loop with the command. When the design and the brakes convince you, NOW you type the command the AI gave you. For "work until a condition is met" (the most common case), in Claude Code that's /goal. For example, to fix tests it'd be something like:
Claude Code
/goal all tests pass (run the full suite), without deleting or skipping any test, max 15 rounds
From there, the AI runs, observes the result, reasons and tries again on its own after each turn, until a fast model confirms the condition is met (or until it hits a brake). If what you want is to repeat something every so often (watch a deploy, say) instead of iterating toward a goal, then the command is /loop:
Claude Code
/loop 5m check whether the deployment finished and let me know what happened
The golden rule of the two steps
You design in plain language (step 1) → you review the plan and the brakes → you type the command (step 2). Never the other way around. That separation is your safety net: no loop starts without you having seen the plan and pressed the button. Five minutes of review save you an open tab.
8. The easiest paths · what the AI does and what you decide
To keep it from getting complicated, here's what your coding agent can do on its own through the chat, and what stays your decision:
What the AGENT does for you (through the chat)
Design the complete loop: the goal, the cycle, the brakes — and give you the exact command to type.
Once YOU fire the command (/goal or /loop), run the rounds on its own: act, observe, reason and retry until the condition is met or it hits a brake.
Launch parallel agents with /batch for big tasks (auditing, researching, migrating).
Verify its own work in a separate turn (the verifier pattern).
Create the skill (SKILL.md) that encodes the context so the loop is repeatable.
What YOU decide (don't delegate it)
The GOAL and when it counts as "done" — this defines the quality of the result.
Typing the command that fires the loop (/goal … or /loop …): it doesn't start on its own, you switch it on after seeing the plan.
The 4 brakes: how many rounds, when to stop for stalling, how much to spend, and the anti-cheat rule.
Reviewing the changes it produced (so you don't pile up understanding debt).
The quality criterion / the rubric — because a loop multiplies the good judgment you put in, and the bad too.
In NeuralOS
The loop engineering philosophy is what drives the agent teams in NeuralOS under the hood: agents that receive a goal and work toward it, with one agent that coordinates and others that execute or verify. Today you see it sketched in the interface (the vision already tangible); the full autonomous engine is part of the backend roadmap. The idea is that you set the goal and the criterion — the system runs the rounds.
Summary · your loop engineering checklist
Before launching any loop, confirm
I have a goal with a clear "done" condition.
I designed the Act → Observe → Reason → Repeat cycle.
I decided whether it's an open or closed loop (in production, almost always closed).
I have the 3 brakes: iteration cap + change check + spend cap.
I defined who does and who verifies (separate turns).
I'm going to review the changes so I don't pile up understanding debt.
I put my best judgment into the rubric — because the loop is going to multiply it.
The close of the series
If you got here following the series, you now have the complete system: memory, GitHub, RAG, the brain, graphify, C-A-R, security, skills, agent-browser… and now the loop that ties them together. You stopped hand-flying the AI: now you set it a goal, give it good judgment and brakes, and let it work. That's building like a studio, not like a machine operator.