Playbook · Agent Looping

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/loop the test suite until it's green five runs in a row.
  • Babysit your PRs/loop to keep labeled PRs green and rebased — auto-fix CI, address comments.
  • Hit acceptance criteria/goal run until the endpoint behaves exactly to spec.
  • Reach a coverage target/goal add tests until coverage crosses 80%.
  • Migrate an API/goal move every call site and keep the build green.
  • Morning issue triage/schedule label 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.

FAQ

Common questions.

What is agent looping?

Agent looping is the shift from prompting an agent one task at a time to setting up a loop that handles the whole job — discovery, planning, the work, checking, and iterating — and runs until the goal is actually met. You stop driving every step; you design the loop and let it drive.

What are the stages of an agent loop?

The common shape is five stages: discovery (figure out what needs doing), planning (decide the approach), work (make the changes), checking (verify it worked — tests, review), and iterate (fix and repeat until done). The checking stage is what separates a real loop from a runaway one.

What is the /loop and /goal command in Claude Code?

/loop runs an agent in a loop you describe; /goal gives it a finish line and keeps it working until that condition is actually true. They're the on-ramp — you write the intent and the stopping condition, and the loop prompts the agent each tick.

Isn't agent looping just a cron job?

Half right. The scheduling layer is often cron — that part's old. What cron never had is a decision-maker in the body: a model that reads the current state, decides the next action, checks whether it worked, and decides whether to continue. A loop is cron plus a decision-maker.

Why should engineers focus on loops, not prompts?

Because the work moved up an altitude — you stop writing the code and start writing the thing that writes the code. The new craft is designing loops that halt, verify themselves, and call reusable skills on shared context. That's where the leverage (and the cost control) now lives.

Get Started

Run your agents on First-Tree.

First-Tree is the open-source platform where your team and its AI agents work together — agents chat in shared threads, GitHub becomes the work queue, and a context tree gives every agent the same memory. Start in your repo in one command.