Field guide · Free · Operator-built
Loops are what come after prompts.
A prompt asks once. An agent finishes one task. A loop keeps operating until the goal is met, the budget runs out, it hits a blocker, or it reaches a boundary only a human should cross. This is the short version of how I run them, and where to copy 43 you can use.
What an AI loop actually is
Most people stopped at prompts. You type a request, the model answers, and the work is whatever fit in one reply. Agents pushed that further: hand the model some tools and it can finish a whole task, not just talk about it. A loop is the next step. It is a bounded operating cycle that keeps an agent working until a clear condition tells it to stop.
The reason loops matter is that most real work is not one task. It is the same task, repeated against a moving target, until something is actually true. Tests pass. The docs match the code. The backlog of flaky tests is empty. A prompt cannot hold that. An agent does one lap. A loop runs the laps and proves each one before it takes the next.
The trap is the runaway. A loop told to "make it better" has no idea when it is done, so it spends your budget chasing a feeling. A good loop is the opposite of that. It says what started the work, what goal to chase, how to prove progress, what it is allowed to touch, and exactly when to quit.
The anatomy of a loop
Every loop worth running has the same seven parts. Miss one and you get either a runaway or a loop that quits before the work is real.
- Trigger. What kicks it off: a schedule, an event, a new file, a failed check, or a person asking.
- Goal. The outcome it pursues, stated so a machine can tell whether it got there.
- Bounded repeat. One coherent move per pass: act, check, keep or revert, then continue.
- Verification. The proof a pass helped: tests, timings, coverage, a screenshot, a source table, a rubric.
- Stop condition. The explicit line that ends it: goal met, budget spent, blocker hit, or approval needed.
- Budget. The ceiling on tokens, time, or passes, so it cannot run forever.
- Safe output. What it is allowed to touch, with publishing, sending, deleting, money, and legal kept behind a human.
When a loop earns its keep
Loops are best aimed at work that is repetitive, evidence-backed, and annoying enough that a person keeps putting it off. The job has a finish line you can measure, and skipping it has a slow cost rather than a loud one. That is exactly the work that rots quietly.
- CI that is slow enough to change how the team behaves
- Documentation that drifts out of sync with the code
- A knowledge base full of captures nobody can find again
- Pre-publish fact checks against the original source
- Dependency and CVE triage by real exposure, not scanner noise
- Customer follow-up that should not fall through the cracks
When a loop is the wrong tool
Loops fail in predictable ways. The goal is vague, so the agent cannot tell progress from motion. The stop condition is emotional, so it never ends. Or the agent can change production with no leash, so a bad pass becomes a bad outage. If a job needs taste, negotiation, or a judgment call that carries real consequences, that part stays with a person. The loop can prepare the decision. It does not get to make it.
Four rules I do not break
These are the difference between a loop that compounds and one that burns a budget.
- Prefer measurable goals. Tests, timings, coverage, screenshots, retrieval checks, and explicit rubrics beat "looks good."
- One bottleneck at a time. A loop makes one coherent move, verifies it, keeps or reverts, then continues. It does not rewrite everything at once.
- State survives the run. Long work needs progress files, evidence logs, branches, or notes. Chat memory is not infrastructure.
- Humans own judgment. Publishing, sending, deleting, shipping, money, legal, and reputation stay approval-gated. Always.
The library: 43 loops, ready to copy
I keep a working library of the loops I actually run, written so you can copy them. Each one names its use case, the cadence it runs on, the verification that proves it worked, and the prompt you paste into a capable agent. They span coding and non-coding work, from repo readiness and CI tuning to source QA, pre-publish checks, and customer follow-up.
The rest are adapted from public agentic patterns and credited as such. Browse, search by use case, and filter to the originals on the full site.
Questions people ask
What is the difference between an AI loop and an agent?
An agent completes one task and stops. A loop wraps an agent in a trigger, a goal, a verification step, and a stop condition, so it keeps operating until the goal is met, the budget runs out, it hits a blocker, or it reaches a boundary only a human should cross.
Do I need to write code to run one?
No. Many of the most useful loops are non-coding work: inbox triage, pre-publish fact checks, source-library QA, customer follow-up. Each loop is a plain-language prompt you can paste into a capable agent. Coding loops exist too, but they are not the requirement.
How do I stop a loop from running forever?
Give it a stop condition and a budget before you start it. A good loop ends when the goal is verified, the token or time budget is spent, or it hits a blocker it cannot clear. A stop condition based on feeling, like "make it better," is how loops run away.
Where are the actual loops?
On the full site. The AI Loop Library has all 43, searchable by use case and filterable to the originals, each with a prompt you can copy.
Related
Keep going
Loops are how I run agents in practice. If you want the safety and cost side, the agents course is the companion read.
If this is useful, Field Notes is where I write up the operator lessons behind tools like this one. Free, occasional, no pitches.