If you've spent any time with a modern AI coding assistant, you've used it the obvious way: ask a question, get an answer, ask the next one. That back-and-forth is useful, but it keeps a human in the critical path for every single step. The agent does a little work, stops, and waits for you. Multiply that pause across a day of development and you start to see the bottleneck — the model isn't the slow part anymore, you are.
Loops are the pattern that removes that bottleneck. They're emerging as one of the most important techniques for getting real leverage out of autonomous AI, and they're surprisingly simple to understand once you strip away the jargon. This article explains what an AI agent loop actually is, the two ingredients every loop needs, a set of concrete use cases you can adopt immediately, and the honest limitations you should know before you turn one loose on your codebase.
What Is an AI Agent Loop?
A loop is a way to let an AI coding agent work autonomously toward a specified goal. Instead of doing one unit of work and handing control back to you, the agent keeps going — assessing its own progress, making changes, re-checking, and repeating — until the goal is met. The defining characteristic is that it takes the human out of the inner loop, which lets the agent move toward the target far faster than it could if it had to stop and ask after every step.
That's the whole idea in one sentence, but the implications are big. A loop can run for ten minutes or ten hours. It can grind through a problem overnight while you sleep, or fire automatically every time a teammate opens a pull request. It turns your agent from a fast assistant into something closer to a tireless junior engineer working a defined shift. If the concept of agents acting on their own is new to you, our primer on what AI agents are is a good place to start before going deeper here.
The Two Ingredients: A Trigger and a Goal
Every loop is built from exactly two parts. Get both right and the loop works; get either wrong and it either never starts or never stops. Those parts are a trigger (what kicks the loop off) and a goal (the condition that tells it when to stop).
Triggers: Three Ways to Start a Loop
There are three ways to kick off a loop, and choosing the right one is really a question of how much you want to remove yourself from the process.
Manual. You tell the agent, directly, to start the loop. This is the simplest option and the right one when a task is occasional, sensitive, or expensive enough that you want to be watching while it runs.
Scheduled. You set the loop to run at a fixed time or on a repeating cadence — nightly, weekly, every morning at 6am. Scheduling is where loops start to feel genuinely autonomous, because the work happens whether or not you remember to ask for it.
Action-based. The loop fires in response to an event, such as a pull request being opened. This is the most powerful trigger because it weaves the loop directly into your existing workflow: every new change automatically gets checked against the goal without anyone lifting a finger.
The point of the whole exercise is to remove the human, so you generally don't want to rely on manual triggers for routine work. But there's no shame in starting manual while you build trust in a loop, then graduating it to a schedule or an event once you've seen it behave.
Goals: Verifiable vs. LLM-as-Judge
The goal is the harder half, and it comes in two flavours. Understanding the difference between them is the most important thing in this entire article, because it predicts how reliable your loop will be.
A verifiable goal is something concrete and deterministic — a number you can measure or a test you can run that returns a clean true or false. "Every page in the app loads in under 50 milliseconds" is verifiable. "100% test coverage across the codebase" is verifiable. The agent never has to guess whether it's done; it just runs the check. Verifiable goals make loops dramatically more reliable, because the stopping condition isn't a matter of opinion.
An LLM-as-judge goal hands the decision to the model itself. "Refactor until you're happy with the architecture" is an LLM-as-judge goal — there's no script that returns true when the code is "clean enough," so the model has to apply its own taste and judgment. These loops are far more flexible, but also more brittle, precisely because you're delegating a subjective call to the AI. You can tighten them up with explicit guidance ("be very strict about simplicity," "make sure every line is DRY"), but you can never make them as crisp as a verifiable check.
The single best predictor of whether a loop will succeed is the goal. If you can express success as a number or a passing test, a loop will be reliable. The moment success becomes a matter of taste, the loop gets brittle — useful, but no longer guaranteed.
In practice, the loop is expressed as a prompt that ends with a stopping condition — literally "continue until every page loads in under 50 milliseconds." Some coding agents now expose this as a first-class command rather than something you phrase by hand; Claude Code's /loop is one example of a built-in loop primitive. Either way, the mechanics are the same: describe the work, define the finish line, and let it run.
Seven Loops You Can Use Today
Theory only goes so far. Here are seven concrete loops, drawn from real-world use, that show the range of what's possible. Notice how each one names its trigger and its goal — and whether that goal is verifiable or judged.
1. The sub-50ms page load loop (verifiable). "Keep optimizing the code for speed. After each significant change, measure page-load performance across every page under the same repeatable conditions. Continue until every page loads in under 50 milliseconds." The agent walks through every window, page, and modal, measures each one, and keeps optimizing anything over the threshold before moving on. Because the goal is a hard number, this loop is about as reliable as they come — in real use it has run for the better part of an hour, methodically tuning page after page.
2. The overnight docs sweep (LLM-as-judge). "Each night, review the codebase in full and make sure all documentation reflects the previous day's changes. Update the docs as needed, then open a pull request." Scheduled to run nightly, this keeps your documentation from rotting. There's no deterministic test for "complete documentation," so the model judges what needs updating — a classic LLM-as-judge goal, paired with a scheduled trigger.
3. The architecture satisfaction loop (LLM-as-judge). "Refactor until you are happy with the architecture. After each significant step, live-test the system, run a review, and commit. Track progress in a markdown file." Trigger and goal sit in a single sentence. The markdown progress file is a nice touch — the loop documents its own reasoning as it goes, which makes it far easier to audit afterward. Run it manually, or nightly to clean up whatever the day's deploys left behind.
Want Loops Working Safely in Your Stack?
The hard part isn't writing the prompt — it's choosing the right goals, triggers, and guardrails so an autonomous agent helps instead of quietly burning your budget. That's exactly the work we do with clients.
Book a Consultation4. The logging coverage loop (LLM-as-judge). "Review the system's logging and add missing coverage until every important path produces useful, tested logs." Because "important" is non-deterministic, the model decides what matters — judge again. On its own it's handy; its real power shows up when you pair it with the next one.
5. The production error sweep (verifiable). "Every night, review the production logs for errors. For any actionable issue, trace it to root cause, fix it, verify the fix, and open a pull request. Then message me on Slack with the findings and PR link — or tell me if there were no actionable errors." This is where loops start compounding: loop #4 ensures you have good logs, and loop #5 acts on them. The goal — no unaddressed errors in the logs — is concrete, and the Slack ping keeps a human informed without keeping a human in the loop.
6. The SEO / GEO visibility loop. "Run an SEO and GEO audit across crawlability, indexation, page intent, titles, internal links, structured data, source citations, and answer-first content. Rank the gaps, fix the highest-leverage issues, re-run the same crawl, and repeat until no critical technical issues remain." Note the new term: GEO (generative engine optimization) is the practice of making your content surface well inside AI answers, not just classic search results. Run weekly, this loop keeps a site technically healthy on both fronts — the kind of disciplined, repeatable SEO hygiene we treat as a baseline across our own pages.
7. The full product evaluation loop (LLM-as-judge). "Create N realistic scenarios covering every major capability. Define clear success criteria and a consistent evaluation method — pass/fail checks or a scoring rubric. Run every scenario under the same conditions, record evidence, fix the underlying cause of anything that fails, re-run the affected scenarios, then re-run the complete test. Continue until every scenario meets the original quality bar." This sounds like a test suite, and in a sense it is — but a non-deterministic one, where the model invents the scenarios and judges the outcomes. It can run for twelve hours or more, and it genuinely surfaces good improvements. It's easy to specialise, too: an AI answering questions with sources might get "generate 100 wide-ranging questions and judge whether each response is accurate and well-cited; iterate until it is."
Look at these together and a pattern emerges. The most powerful setups aren't single loops — they're loops that feed each other, and loops with verifiable goals doing the heavy lifting while judged loops handle the fuzzier work. This is the same composition principle behind multi-agent systems, and loops are a natural companion to the open-source agent harnesses we covered in our roundup of open-source AI agent projects.
Where Loops Break Down: Two Honest Caveats
Loops are powerful, but they are not a universal answer, and it's worth being clear-eyed about the two places they struggle.
1. They're not for every problem — yet. Designing a loop is mostly about designing the goal, and that's hard. Verifiable goals are a perfect fit; LLM-as-judge goals are workable but brittle, because you're leaving taste to the model. Where loops genuinely struggle today is building new features from scratch. You can't reliably say "loop until you've built a complete permissions system," because you can't predict which direction the agent will take, which features it will judge worthwhile, or when it will decide it's done. One memorable experiment set a goal of "clone Excel to feature parity" — the agent opened Excel, used computer control to click through it, and ran for days before being stopped manually. Instructive, but not a recommendation. Loops shine at improving, hardening, and maintaining systems with a clear definition of done — not at open-ended invention.
2. They're expensive. A loop churns through tokens autonomously until it hits its goal. Some finish in ten minutes; some run for days. If you have a generous token budget, that trade is fantastic — you're converting compute into completed work while you sleep. If you're cost-constrained, an unattended loop can quietly become a very large bill, especially a judged loop with a fuzzy stopping condition that lets it wander. Keep a close eye on any loop until you trust both its goal and its appetite. Understanding this trade-off is really an extension of the broader question we explore in how much AI implementation actually costs.
What Loops Mean for Your Business
Step back from the individual recipes and the strategic shift is clear: loops change what "using AI" means. The first wave of AI tooling made individual tasks faster. Loops make entire categories of work continuous — your documentation stays current, your error logs stay clean, your performance budget stays enforced, your SEO stays healthy, all without anyone scheduling the work each time. That's a different kind of leverage, and it accrues to teams that adopt it deliberately.
The organisations that win with loops won't be the ones that run the most of them. They'll be the ones that pick the right goals — favouring verifiable targets, sandboxing the judged ones, and putting cost ceilings and human checkpoints exactly where the risk lives. Setting up that balance, so autonomous agents reliably help instead of quietly drifting or overspending, is precisely the kind of work we do with clients. If loops sound like the unlock your team has been missing, that's a conversation worth having.