The Claude Code Loop
For two years we prompted agents one task at a time. That's changing. The new pattern — agent looping — is to set up a loop that handles discovery, planning, the work, and the checking, and runs until the goal is actually met. Here's what it is, where it came from, and why the loop, not the model, is now the expensive part.
The most repeated idea in AI coding right now has a name: agent looping. The thesis, as the people living it put it, is that you shouldn't be prompting coding agents anymore — you should be designing loops that prompt them. Instead of asking an agent to build the landing page and then driving every step yourself, you set up a loop that handles the whole job. This page is what that actually means: the stages of a loop, the lineage behind it, the honest "it's just cron" objection, and why the durable advantage is the context your loops run on.
The shift: from prompting to looping
For about two years, the workflow was one-shot: you prompt, you read the result, you prompt again — you are the thing inside the loop. Agent looping inverts that. You become the author of the loop; the model becomes the subroutine it calls. Boris Cherny, who built Claude Code, describes the ladder in three rungs: a year ago, writing code by hand with autocomplete; then running several agent sessions in parallel and prompting each; now, not prompting at all — writing the loops that prompt the agent while a fleet reads the repo, the issues, and the chat and decides what to build next. The job didn't vanish. It moved up an altitude, from writing the code to writing the thing that writes the code.
The five stages of an agent loop
Strip away the hype and a loop is a repeatable cycle with a shape:
- DiscoveryThe loop figures out what actually needs doing — reads the issue, the failing test, the comment thread.
- PlanningIt decides the approach before touching code.
- WorkIt makes the changes across the repo.
- CheckingIt verifies — runs the tests, reviews the diff, confirms the goal. The stage that matters most.
- IterateIf checking fails, it corrects and goes again, until the condition is met.
You wrote the intent and the stopping behavior. The loop ran the five stages on its own. Notice that two of the five — discovery and checking — are entirely about context: knowing what to do and knowing whether it's right. Hold that thought.
Where it came from: a five-year lineage
"Loop" hides several different things. The ladder, oldest to newest:
- 2022 · ReActThe academic while-loop. Reason, call a tool, read the result, repeat. One model, one loop, a human watching.
- 2023 · AutoGPTThe goal loop. Gave the loop a goal and let it prompt itself — and became infamous for spinning forever doing nothing. That failure seeded years of "agents are a toy."
- 2025 · RalphThe origin of the modern idea. Pipe the same prompt file into the agent over and over. Its innovation was discipline — every iteration resets context to a fixed set of anchor files instead of letting the conversation sprawl. The historical root; no longer the headline.
- 2026 · /goal · /loopCondition-terminated commands. Give the agent a finish line and it keeps working until the condition is actually true, validated by a small checker.
- Now · OrchestrationThe genuinely new layer. The loop is the unit of work; loops supervise other loops concurrently and on a schedule; scheduling replaces the human kickoff; state is durable (git-backed, crash-recoverable). Ralph assumed your terminal stayed open — the 2026 version assumes it doesn't.
"Isn't this just a cron job?"
The best skeptic line in the discourse, and it's half right. The
scheduling layer often is cron — /loop can run on
cron under the hood. If your whole definition is "a thing on a timer," we
invented that in 1975.
What cron never had is the part in the middle. A cron job runs a fixed script. A loop runs a model that reads the current state, decides the next action, does it, checks whether it worked, and decides whether to keep going. The decision is the agent's, not a hardcoded branch. A loop is cron plus a decision-maker in the body — and the real engineering is everything you wrap around that decision so it doesn't run off a cliff.
The on-ramp is one line
Claude Code shipped /loop and /goal. The
canonical starter is to paste this and change the nouns:
/loop babysit all my PRs. Auto-fix build issues, and
when comments come in, use a worktree agent to fix them.
The practitioner's recipe for running an agent autonomously for hours:
auto-approve permissions so it doesn't stall, let it orchestrate many
sub-agents, use /goal or /loop to keep it going
until done, run it in the cloud so you can close your laptop — and the
tip everyone serious obsesses over, make sure it can verify its
own work end to end. That's the checking stage again. A loop is
only as trustworthy as its ability to check itself.
Common loops people actually run
The fastest way to learn looping is to copy a working one and change the
nouns. These are real recipes — drawn from
awesome-agent-loops,
a curated list of /loop, /goal, and
/schedule commands sourced from practitioners — grouped by
the three loop types:
- Kill flaky tests
/loopthe test suite until it's green five runs in a row. - Babysit your PRs
/loopto keep labeled PRs green and rebased — auto-fix CI, address comments. - Hit acceptance criteria
/goalrun until the endpoint behaves exactly to spec. - Reach a coverage target
/goaladd tests until coverage crosses 80%. - Migrate an API
/goalmove every call site and keep the build green. - Morning issue triage
/schedulelabel and summarize new issues every day.
Notice the pattern: /loop repeats on an interval,
/goal runs until a condition is true, and
/schedule puts it on cron in the cloud. The full collection
of recipes lives in
awesome-agent-loops.
The twist: the loop is now the expensive part
Once the model writes the code for almost nothing, the cost moves to the loop running it. Teams are capping per-engineer agent spend after burning annual AI budgets in a single quarter. The failure mode everyone in production fears is the loop that doesn't stop — and the bill behind it. Which is why every serious 2026 write-up converges on the same three hard stops:
- Max itersA hard cap on how many times the loop can run.
- No-progressDetect when iterations stop changing anything, and stop.
- $ ceilingA token or dollar budget the loop can't exceed.
The romantic version is that a thousand agents build your company overnight; the production version is that you write the loops, and most of your job is making sure they halt and that the feedback inside them keeps them honest.
It's not just loops. It's the skills — and the context — they call.
Here's the part the hot takes miss. The loop is plumbing. The
asset is what it calls. A loop with nothing reusable inside it is
a while-true around a stranger. A loop that calls a library
of sharp, named skills — and
reasons from your team's actual decisions — compounds. The durable half of
the agent-looping idea is exactly this: if you do something more than
once, turn it into a skill so next time is free.
And remember the five stages — discovery and checking are pure context. The loop has to know what your team decided to discover the right work, and know your conventions to check its output. On a team, that context can't live in one person's local config; it has to be shared, or every loop discovers and checks against a different idea of "right" and drifts.
First-Tree is the context your loops run on.
It's an owned, versioned context tree of your team's decisions and ownership that every loop reads on every iteration (via a SessionStart hook). So the skills your loop calls operate on what your team actually decided — the discovery stage finds the right work and the checking stage measures against the right bar — instead of re-guessing each tick. A whole fleet of loops, across everyone's machines, stays pointed the same way. The loop is the engine; First-Tree is the memory that keeps it from drifting. Open source and free.
The takeaway
Agent looping isn't a hot take about prompt engineering dying. It's this: stop being the thing in the loop. Write the loop once, give it skills worth calling and feedback so it can check itself, cap it so it halts, and give it shared context so its discovery and checking stay on target — then let it run while you go decide what to build. That's the move from prompting to agentic coding, and at team scale it's how you run a real AI agent team. The on-ramp is a single slash command; the durable advantage is the context underneath it.