Jonathon's AI Wiki

Write Loops, Not Prompts — Agent Loops Explained (Lineage, Cost Controls, 3 Starter Loops)

13 min read

Source: raw/Claude_Code_Creator_-_Write_Loops_Not_Prompts.md (YouTube EH2MMQTaPEA, ~9-min creator explainer; channel not named in the transcript — reacting to Boris Cherny’s “write loops” clip + tweet thread). 2026-07-03 research-agenda drain added: ai-research/openclaw-vision-md-primary-2026-07-03.md (Peter Steinberger’s actual OpenClaw VISION.md, primary source), ai-research/openclaw-vision-md-report-2026-07-03.md (third-party analysis), ai-research/steipete-just-talk-to-it-2026-07-03.md (Steinberger’s own blog on his agentic-coding practice) — plus wiki synthesis from agent-skills, goal` walkthrough, Should You Build a Loop?, Nate Herk, and Loop Engineering.

A beginner-friendly explainer that “susses out the middle ground” on the viral “you should be designing loops that prompt your agents, not prompting agents yourself” claim. Its value is pedagogical: it traces how we got to agent loops (ReAct → AutoGPT → Ralph Loop → /goal → agent loops), defines a loop in one sentence, gives three cost controls so loops don’t “burn billions of tokens,” and ends with three concrete starter loops anyone can run this week. A good first stop for learning the topic before the heavier references. This is the seed article for the agent-loops topic.

Key Takeaways

  • A loop is a small program that prompts the agent for you, reads what it produced, decides if it’s done, and reprompts if not. That’s the whole idea — the rest is guardrails.
  • The leverage claim: building the loop that harnesses your work is more valuable than the individual prompts you send. “My job is to write loops” (Boris Cherny).
  • Lineage matters: today’s “agent loop” is the productized descendant of ReAct (2022–23), AutoGPT, and the Ralph Loop — each fixed a specific failure of the last.
  • /goal = a Ralph Loop that stops on a completion condition instead of a max-iteration count. That single change is what made loops practical.
  • Token blowups are a configuration failure, not an inherent property. Three controls prevent them: max iterations, no-progress detection, and per-sub-agent token ceilings.
  • Skills are what make loops effective — “loops are plumbing; if you pour concrete and eggshells down there you’ll have a bad time.” A loop is not a new capability by itself.
  • Readiness gate: if you can’t already run 2–3 parallel agent sessions comfortably, building a loop is a bad idea.

The Lineage — how we got to agent loops

The explainer’s spine is a four-step evolution, each step solving the previous one’s failure:

  1. ReAct (2022–23 paper) — the first formalized agent loop: a model reasons about what to do, acts via tools, reads the output, and repeats until done. One model, one loop, a human watching the whole time. Unlocked acting on real tool output instead of hallucinating.
  2. AutoGPT — give it a goal and let it prompt itself toward completion, spawning sub-goals. Proved autonomy was possible with guardrails — but ran down rabbit holes, wasting time and tokens.
  3. The Ralph Loop — run the same exact prompt over and over until the work is complete or a max-iteration cap is hit. Its insight: discipline through forced amnesia — a fresh conversation every run means fresh eyes and an objective re-approach, instead of a history that clogs the pipes.
  4. /goal (Codex + Claude Code) — productized the Ralph Loop with one change: instead of a max-iteration count, it runs until the task and your intention for it are actually complete, judged against criteria you set. “A goal is a Ralph Loop that knows when it’s done.”

That lands at the agent loop: loops orchestrating loops — effectively a multi-agent-orchestration version of a Ralph Loop. The mental model: the loop that harnesses everything is worth more than any single prompt through it.

The Three Cost Controls

The viral backlash is mostly about money — the explainer cites Uber blowing its entire AI budget in 4 months, then capping engineers at ~$1,500 per tool per month. For those of us on a Claude Max or Codex CLI plan rather than a corporate budget, three controls keep a loop from “flying off the rails”:

  1. Max iterations — a hard cap even when you have a goal, for the case where the loop can’t reach it and would otherwise retry forever. In Claude Code workflows you set this as a variable in the workflow.
  2. No-progress detection — the real source of runaway bills: the loop hits the same issue repeatedly, or new issues keep cropping up and it wanders down weird paths without addressing the root. Detect stagnation and stop.
  3. Token ceilings — a hard financial stop; in a Claude workflow you cap the max tokens each sub-agent may spend.

Key enabler: in workflows the orchestration logic lives outside the agent (a JavaScript function). The old failure mode — “the agent was responsible for orchestrating the agent,” so it locked into bad decisions and ran with them — goes away when an external function drives the loop. Framed properly, a loop “shouldn’t burn any more tokens than you doing all those steps manually would have.”

Skills Make Loops Work

“Loops are like plumbing — but if you’re pouring concrete and eggshells down there, you’re going to have a really bad time.”

A loop is not, by itself, a new capability that turns you into a super vibe-coder. The best loops integrate skills that already exist into how they run. Encode your context, conventions, and guardrails as skills/markdown the loop reads, so the agent knows when it may decide for itself and when it must stop and check in with you — a line the explainer stresses is personal to your skill level and what you want to stay in control of, not one-size-fits-all.

Three Starter Loops You Can Run This Week

  1. Issue-backlog loop. Log every bug / feature idea / “come back to this” as a GitHub issue, then: /goal → go through the open issues, use the superpowers systematic-debugging skill, write a test case for each bug, commit it, and open a PR per bug. You don’t get the “goal achieved” notification until all of them are fixed. Cost-control caps can be added in plain natural language.
  2. Front-end verification loop. After a front-end change, kick off the Chrome extension (or an iOS simulator), snapshot the result, inspect the DOM, and cross-reference it against your specs / acceptance criteria — and especially against your designs, viewing the built UI and the Claude Design mockup side by side, iterating until near-100% fidelity. Cap the tries or wrap it in /goal.
  3. Code-review loop (Boris Cherny’s). /loop every 5 minutes with a custom /babysit command that auto-addresses code-review comments, auto-rebases, and shepherds PRs to production. Once you run parallel agents you generate far more commits and PRs; this loop is what keeps that volume from getting away from you. Note Cherny’s loops lean heavily on custom skills and slash commands.

The Readiness Gate

A blunt prerequisite: if you can’t already comfortably run 2–3 parallel agent sessions yourself — managing the context, passing it between agents, and getting output you’re happy with purely from the context you authored — building a loop is a really bad idea. If you can, the question simply becomes how to automate that process better. Verification underpins all of it: “you have to have a really strong process for verifying and reviewing what has been done” — and against what standard is the part the explainer says is still underdeveloped.

What Minimum Context Actually Resolves Ambiguity (research-agenda drain, 2026-07-03)

The topic’s oldest open question — how much markdown a loop needs before it stops guessing at business/UX decisions — turns out to have a converging answer across three independent practitioner sources, none of which propose “write more docs” as the whole fix:

  • Interview to confidence, before the loop starts. Addy Osmani’s agent-skills ships an interview-me skill: a one-question-at-a-time interview that gets the agent to ~95% confidence on what you actually want before it builds anything. This reframes “minimum context” — it isn’t a fixed document size, it’s whatever’s left after an explicit disambiguation pass. Cheapest reliability win in that bundle, by the maintainer’s own framing.
  • A strong /goal condition defines four things, plus explicit no-go zones. Per the Codex documentation Chris’s walkthrough surfaces (see goal` walkthrough): a goal needs what to achieve, what to change, how to validate progress, and when to stop — plus constraints naming files/areas that must not be touched. Chris’s own failure-mode name for skipping this: “too open-ended goal → not enough context to work correctly,” which is why he runs plan mode first and only then invokes /goal against the resulting plan.
  • Not all ambiguity should be resolved with more context. Peter Steinberger’s own account of his practice (steipete.me/posts/just-talk-to-it) draws a sharp line the topic hadn’t captured yet: he keeps a stable conventions layer in Agents.md/CLAUDE.md (naming patterns, DB-migration rules, testing/linting conventions — pruned over time as newer models internalize them without being told) strictly separate from exploratory work, where he deliberately under-specifies UI requests and lets the model surprise him, iterating on what comes back rather than pre-specifying the shape. Ambiguity is a bug for the conventions layer and a feature for exploratory loops — the fix isn’t uniformly “more context,” it’s knowing which kind of task you’re in.

Practical synthesis: minimum context = (1) whatever’s stable and recurring, written once into CLAUDE.md/a skill (the intent-debt cure Loop Engineering already documents); (2) explicit “don’t touch X” constraints scoped to the specific loop run; (3) an upfront interview or plan-mode pass for anything genuinely undetermined; and (4) permission to not pre-specify when the task is exploratory and surprise is welcome. This resolves the original question’s practical form — it does not produce a universal token count, because none exists.

Does a Vision Doc Reduce Decisions? Peter Steinberger’s Actual VISION.md (research-agenda drain, 2026-07-03)

This article’s prior framing — “Peter Steinberger uses a vision.md per project (per Grok: core problem, intended solution, key goals, technical principles, success criteria)” — needs a correction. That five-part structure was Grok’s paraphrase, not a verified quote, and it doesn’t match what Steinberger actually ships.

The primary source is public: github.com/openclaw/openclaw/blob/main/VISION.md — the real VISION.md he wrote for OpenClaw before joining OpenAI (archived in full at ai-research/openclaw-vision-md-primary-2026-07-03.md). It is not a per-task planning artifact. It’s a one-time project constitution: a one-line mission (“OpenClaw is the AI that actually does things”), current priorities, contribution rules (PR size caps, one-PR-one-topic), a security-tradeoff philosophy (“strong defaults without killing capability”), and — the load-bearing part — an explicit “What We Will Not Merge” section with seven named exclusions: no new core skills that could live on ClawHub, no agent-hierarchy frameworks (“no manager-of-managers, no nested planner trees as default architecture”), no heavy orchestration layers duplicating existing infrastructure, and four more.

Does it measurably reduce the decisions you’d otherwise make by hand? No controlled or quantified measurement exists anywhere — this is not a study anyone has run, on this or any other vision doc. But there is a demonstrated mechanism, not just an assertion: the “What We Will Not Merge” list is explicitly a pre-decided boundary. A contributor (or, by extension, a PR-triage loop / Routine reading the repo) can self-reject a scope-violating proposal by checking it against seven written lines, instead of escalating to Steinberger for a fresh judgment call every time. That is “reduces the decisions you’d otherwise make by hand,” made concrete and citable — just not measured in any quantified sense. Treat the quantification clause as still genuinely open; treat the mechanism as confirmed.

Where the Human Steps Back In (research-agenda drain, 2026-07-03)

The wiki’s sources converge on three named axes rather than one universal line — and the L0→L3 readiness ladder (Loop Engineering) is the answer’s actual shape, not a single fixed rule:

  • Token budget. Should You Build a Loop?’s four-condition test names this explicitly: whether a loop’s waste is tolerable is “obvious to people with effectively free tokens, reckless to people on a $20 consumer plan — both groups are right.” Your budget sets how much unattended run you can afford before you must step back in to check.
  • Hands-on engineering comfort. This article’s own readiness gate: if you can’t already comfortably run 2-3 parallel agent sessions yourself, building a loop is a bad idea — the operational floor for stepping out is being able to step in competently first.
  • Role and stakes. Nate Herk’s explicit counterweight: Steinberger’s always-on multi-agent fleets are “a hardcore coder at OpenAI” — cargo-culting that “doesn’t mean it applies to you and your use case.” A knowledge worker’s solo loop (Herk’s own default: ~35 minutes to a couple hours, human reviews the output) sits at a different rung than a systems engineer’s unattended fleet, by design, not by deficiency.

These three axes jointly set which rung of the L0→L3 ladder you’re honestly ready for — and the rung is the answer to “where do you step back in”: L1 (report-only) means the human reviews every output before anything ships; L2 (assisted) means the human is out of the small-fix loop but still gates merge/deploy through a separate verifier; L3 (unattended) means the human only steps back in on a denylist hit, a budget-cap breach, or an explicit escalation. There is no context-free single line — but there is a named, checkable ladder, and your position on it is a function of the three axes above, not a personality trait.

Open Questions

The explainer originally flagged three things as lacking clean answers. All three were drained from the topic research agenda on 2026-07-03 — see the three sections above (“What Minimum Context Actually Resolves Ambiguity,” “Does a Vision Doc Reduce Decisions?,” “Where the Human Steps Back In”) for the resolutions:

  • How do loops handle ambiguity? — resolved.
  • Where does planning live? Does a vision doc reduce decisions? — resolved, with a correction to the original framing (the five-part “core problem/intended solution/key goals/technical principles/success criteria” structure was Grok’s paraphrase, not verified against Steinberger’s actual VISION.md).
  • Where does the human step back in? — resolved.

Residual open question: would a formal comparison (same loop, with vs without a written vision doc) actually measure a decision-reduction effect, or is the mechanism real but too diffuse to isolate in a controlled test? No source in this wiki has attempted that study.

Graph View

Backlinks