Loop engineering: stop prompting your AI, start designing loops that prompt it
The people who built the leading AI coding tools say they barely prompt anymore. They write loops that prompt the agent for them. Here is what that actually means, where it came from, and how to run your first one, in plain language.
Loop engineering is designing the system that prompts an AI agent, instead of prompting it yourself one message at a time. You set a goal and a way to check the work. A loop then gives the agent instructions, runs it, verifies the output, and decides what to do next, over and over, often on a schedule and with helper agents.
The one-line version, from Addy Osmani who named the pattern: you stop being the person who prompts the agent, and you build the thing that does the prompting instead.
Where the term came from
Two statements from people who build these tools kicked off the whole conversation in mid 2026. Both are real, and both are worth reading in their own words.
I do not prompt Claude anymore. I have loops running that prompt Claude and figure out what to do. My job is to write loops.
You should not be prompting coding agents anymore. You should be designing loops that prompt your agents.
Neither of them coined the phrase. The label loop engineering was popularized shortly after by Addy Osmani, who tied the two ideas together into one name. The honest read: the pattern is real and already shipping, and the term is a fresh handle for something practitioners were already doing with schedules, hooks, and helper agents.
The ladder: prompt, context, harness, loop
Loop engineering is easiest to understand as the next rung on a ladder you may already know. Each rung zooms out and asks the human to manage one level higher.
Prompt engineering tunes a single instruction. Context engineering manages everything the agent can see in one session.
Harness engineering shapes the whole environment one agent runs in. Loop engineering runs those harnesses on a schedule, spawns helpers, and feeds the system its next task.
Worth keeping honest: the full ladder is a community way of explaining the shift, not a single official diagram. What is well sourced is the top rung and the quote behind it.
Prompt engineering vs loop engineering
The clearest way to feel the difference: notice who is doing the repeating. In the old way, that is you. In loop engineering, you hand that job to the system.
The anatomy of a loop, in six beats
Almost every good loop, for code or anything else, moves through the same six beats. This is the cycle in the diagram above, spelled out.
- 1
Set the goal
You define a clear, checkable outcome. Not "work on marketing" but "publish one on-brand post a day until the queue is empty." The done-condition is the most important line you write.
- 2
Discover and plan
The agent gathers what it needs first: reads files, pulls data, checks what changed, then decides what to do next. The plan is made fresh each pass, not fixed up front.
- 3
Run in parallel
The work gets done, often by several helper agents at once, each in its own context. One scouts, one drafts, one checks. The orchestrator keeps them moving.
- 4
Verify
A separate step checks the work against something real: a test that passes, a build that compiles, a fact that holds. The worker does not grade its own homework.
- 5
Ship
What passed verification goes out. What failed loops back with the reason attached, so the next pass is smarter instead of repeating the same mistake.
- 6
Decide what is next
The loop asks "what now?" and either picks the next task or waits for the schedule to wake it again. Then it starts over. That is the whole trick.
Open loops drift, closed loops hold
The single biggest mistake is skipping verification. A loop that ships without a check feels fast for an hour, then quietly compounds small errors until the output is junk. The fix is a closed loop: a gate that sends failures back with the reason attached.
Do not let the agent grade its own homework. Anthropic's own guidance on building effective agents is blunt about this: check the work against ground truth from the environment, like a test that passes or a build that compiles, and have a separate step do the checking. The worker that did the work is the worst judge of it.
The building blocks of a real loop
You do not build a loop from scratch. You assemble it from primitives the tools already ship. Here are the ones in Claude Code, the tool the original quotes were about. Most loops combine several of these rather than relying on one.
/goalWork until a condition is met
Set a finish line in plain English and the agent keeps going across turns until it is met. Under the hood it is a checkpoint that runs after every turn, asks a small fast model "done yet?", and re-triggers the agent on a "no". There is no built-in turn cap, so you add one to the condition yourself.
/loopRe-run a prompt on an interval
Run the same prompt on a fixed cadence, for example every 30 minutes, or let the agent pick its own interval. Good for watching something change: a deploy, a queue, a metric. Tasks are session-scoped and expire after about a week.
Routines and scheduled tasksWake itself up on a schedule
Durable schedules that fire without a session open: managed in the cloud (no machine needed) or on your own desktop with access to local files. This is what turns a one-off into a habit that runs every morning whether you are there or not.
HooksFire logic at key moments
Small rules that run at specific events, like when the agent is about to stop. A stop-hook can refuse the stop and push the agent to keep going. This is the raw primitive that goals and the well-known "Ralph loop" pattern are built on.
Sub-agentsDelegate to focused helpers
The main agent hands a slice of work to a helper that runs in its own clean context and reports back a summary. You get parallelism and focus without flooding the main thread. Background helpers can run while you keep working.
Agent teamsA lead that coordinates teammates
An experimental setup where one agent leads and several teammates each run independently, sharing a task list and a mailbox. The lead splits the work, assigns it, and synthesizes the result. Closer to managing people than running a script.
The parts the hype skips
Loops are token-hungry
A loop that runs unattended for an hour can burn through far more tokens than a person typing prompts, because it keeps going whether the next step is needed or not. Put a budget on it: a turn cap in the goal, a sensible interval, and a stop condition. A loop with no ceiling is a way to spend money while you sleep.
Memory has to live outside the session
A single agent session forgets everything when it ends, and stuffing days of history into one context makes it slower and dumber. Reliable loops write progress to plain files the next run can read. The file system is the loop's memory, not the chat history.
You are still in the loop
Loop engineering does not remove the human, it moves the human up a level. Your job shifts from typing every step to setting good goals, designing the checks, and reviewing what comes out. Set one running and walk away for a day with no verification and you will come back to confident nonsense.
Loops are not just for code
Loop engineering started with coding for one practical reason: code has cheap, honest verification. Tests either pass or they do not. But the shape works anywhere you can name a goal, a repeatable action, and a check. Content, research, outreach, and operations all loop well.
A marketing loop, for example, runs the same six beats. It spots a trend, drafts a post, checks it against your brand voice and the facts, publishes what passes, measures how it did, and decides what to make next. That is exactly the loop we built Brand Brain to run, so a solo founder can stay consistent without sitting in the chair every day.
A content loop, same six beats
For the content version of this in full, read loop engineering for content. You can also go deeper on Claude routines for marketing automation and putting your content on autopilot with AI agents.
How to run your first loop
You do not need agent teams or a fleet of helpers to start. You need one boring, repetitive task with a clear finish line. Here is the on-ramp.
- 1
Pick a loop-shaped task
Repetitive, with a finish line you can actually check. Daily standup notes, triaging a queue, drafting posts from a list. If you cannot describe when it is "done", it is not ready to loop yet.
- 2
Write the goal as something checkable
The done-condition is the whole game. "Make it good" cannot be verified. "Every item in the list has a draft and the list is empty" can. Add a turn cap so it cannot run forever.
- 3
Add a verification step
Decide what "correct" means and have a separate check enforce it before anything ships. Even a second pass that re-reads the work against your rules beats no check at all.
- 4
Give it a memory file
A plain file where the loop records what it did and what is left. That is how run number two knows where run number one stopped.
- 5
Pick a cadence and watch closely
Run it on a schedule, then babysit the first handful of passes. Widen the leash only as it earns trust. One reliable loop beats ten ambitious ones you have to supervise.
Frequently asked questions
What is loop engineering?
Loop engineering is designing the system that prompts an AI agent, instead of prompting it yourself one message at a time. You set a goal and a way to check the work, then a loop repeatedly gives the agent instructions, runs it, verifies the output, and decides what to do next, often on a schedule and with helper agents. In short: you stop being the person who prompts, and you build the thing that does the prompting.
Who coined the term "loop engineering"?
The phrase was popularized in June 2026 by Addy Osmani, who synthesized two widely shared statements: Boris Cherny, head of Claude Code at Anthropic, said "my job is to write loops," and Peter Steinberger, creator of OpenClaw, posted that "you should be designing loops that prompt your agents." Osmani named the pattern those two were describing.
What is the difference between prompt engineering and loop engineering?
Prompt engineering is writing one good instruction and reading one reply. Loop engineering is one level up: you design a system that writes the instructions, runs the agent, checks the result, and feeds itself the next step over and over. Prompt engineering optimizes a single turn. Loop engineering optimizes a process that runs many turns on its own.
What is the difference between harness engineering and loop engineering?
A harness is the environment a single agent runs inside: its tools, its memory, its permissions, the context it sees. Harness engineering is making that environment good. Loop engineering sits one floor above it: it runs those harnesses on a schedule, spawns helpers, verifies output, and feeds the system its next task. Harness is the room; the loop is what keeps sending the agent back into it.
What are the steps in an agent loop?
A typical agent loop has six beats: set a clear goal with a done-condition, discover and plan by reading the current state, run the work (often with parallel helpers), verify the output against something real like a test or a fact, ship what passed, and decide what to do next before starting over. Verification and an external place to remember progress are what separate a reliable loop from one that drifts.
Is loop engineering just a buzzword?
Partly. The underlying pattern, wrapping an agent so it re-prompts itself until a goal is met, is real and already shipping in tools like Claude Code. The fresh label is mostly a name for practice people were already doing with hooks, schedules, and sub-agents. Treat "loop engineering" as a useful handle for that pattern, not a brand-new technology, and you will not be misled by the hype.
What tools do you use to build an agent loop?
In Claude Code the core building blocks are: /goal to run until a condition is met, /loop to re-run a prompt on an interval, routines and scheduled tasks to wake on a schedule, hooks to fire logic at key moments (including the stop-hook the Ralph loop pattern uses), sub-agents to delegate to focused helpers, and experimental agent teams for a lead-and-teammates setup. You combine these rather than picking one.
Does loop engineering only work for coding?
No. It started with coding because code has cheap, honest verification: tests either pass or they do not. But the same shape works anywhere you can define a goal, a repeatable action, and a check. Content, research, outreach, and ops all loop well. A marketing loop might spot a trend, draft a post, check it against your brand and facts, publish, then measure and repeat.
How do I start with loop engineering?
Start small. Pick one repetitive task with a clear finish line, write the goal as something you can actually check, add a verification step so nothing ships unchecked, give the agent a file to record progress between runs, and pick a cadence. Watch the first few runs closely, then widen the leash as it earns trust. One reliable loop beats ten ambitious ones that need babysitting.
Run a content loop without writing the code
Brand Brain is the marketing version of a closed loop: it finds what to post, drafts it in your voice, checks it, and publishes on a schedule. You set the goal and review the output. It runs the rest.
7-day free trial. Cancel anytime.