← Item page
Link Triage Explainer · X Article

WTF Is a Loop?

Matt Van Horn’s X Article translates the current “design loops, don’t prompt agents” discourse into an operational idea: write durable feedback loops that prompt, supervise, verify, and stop coding agents for you.

Source: Matt Van Horn on X Article title: WTF Is a Loop? Peter Steinberger vs. Boris Cherny Fetched via X API article.plain_text Public metrics at fetch: 510 likes · 1,446 bookmarks · 40k impressions

Bottom line

Definition

A loop is a small program/process that prompts an agent, checks the result, decides what to do next, and repeats until a stopping rule fires.

Why it matters

The human moves out of the prompt-by-prompt seat and into loop design: triggers, context, tools, verification, budget, and halt conditions.

Dab relevance

This is exactly the shape of Mission Control cron jobs: capture → choose one unit → execute with tools/skills → validate/render/commit → report or stay silent.

The article’s main argument

The piece starts from Peter Steinberger’s viral line: “you shouldn’t be prompting coding agents anymore; you should be designing loops that prompt your agents.” The author argues the phrase went viral partly because people repeated it before they could define it.

“The loop, not the model, is now the expensive part.”

The useful distinction: a loop is not merely a timer and not merely a prompt template. It is a recurring decision system around an agent: gather state, ask the model, run tools, inspect output, decide whether to continue, and persist state so the work can survive restarts.

Loop lineage: five layers people confuse

2022
ReAct
Reason → act/tool → observe → repeat.
2023
AutoGPT
Goal-driven self-prompting; famous for spinning.
2025
ralph
Simple repeated agent invocation with stable anchor context.
2026
/goal + /loop
Productized agent continuation with validator/stopping behavior.
Now
Orchestration loops
Loops supervising other loops/agents on schedules with durable state.

What “cron with a hat” gets right and wrong

Right

  • Many loops are literally triggered by cron or a scheduler.
  • Without a model decision body, a loop is just an ordinary scheduled script.
  • Most production value comes from mundane infrastructure: locks, retries, logs, budgets, and recovery.

Wrong

  • The agent chooses the next step from live state instead of following only hardcoded branches.
  • Loops can dispatch other loops/agents and synthesize feedback from tests, reviews, tickets, Slack, GitHub, or users.
  • Durable shared state turns a timer into a background operator that can resume work after crashes.

Practical loop anatomy

TriggerManual slash command, cron schedule, webhook, queue event, or unread capture.
Context packStable files, issue text, repo state, previous run logs, user preferences, relevant skills.
Agent callClaude/Codex/Hermes does one bounded step, not an open-ended “be useful forever” job.
Tool executionCode edits, tests, fetches, render, browser QA, GitHub comments, or Notice Board transactions.
VerifierTests, linters, validators, screenshots, HTTP checks, review model, or explicit acceptance criteria.
Stop rulesDone condition, max turns/iterations, no-progress detection, time/token/dollar ceiling, and safe failure path.
Memory/stateGit commits, issue updates, inbox audit entries, durable item pages, queue status, and crash-resume markers.

How this maps to Mission Control

Already loop-shaped
  • Capture loop: WhatsApp/Telegram input becomes canonical Notice Board state through tools/notice.py.
  • Link explainer loop: pick at most one substantial unexplored link, write an item-local explainer, call set-explainer, validate/render/commit.
  • Auto-connect loop: periodically suggests relationships between recent items.
  • Morning brief loop: turns local state into a digest without manual prompting.
What would improve the loops
  • Add explicit per-loop budgets: max fetches, max model calls, max wall time, and max changed files.
  • Store run manifests: candidate considered, why selected/skipped, verification commands, commit hash.
  • Make “no-progress” a first-class state so failed fetches do not retry forever without new evidence.
  • Promote hard-earned procedures into skills immediately after a difficult run.

Good loop vs bad loop

Good: bounded operator

  • Has a narrow goal and acceptance criteria.
  • Reads canonical state at the start and writes through the sanctioned transaction path.
  • Verifies independently with real commands/screenshots/API output.
  • Commits a clean checkpoint or leaves no mutation.
  • Reports limitations instead of fabricating missing source data.

Bad: infinite intern

  • Vague goal: “research this” / “make it better.”
  • No halt condition, retry ceiling, or budget.
  • Lets generated changes pile up without scoped commits.
  • Trusts its own summary rather than tests/render/browser checks.
  • Consumes tokens to re-discover what should be a named reusable skill.

The skill point is the durable takeaway

The article’s strongest ending is that “loop” is plumbing; the compounding asset is the skill the loop can call. A loop with weak skills re-derives everything every run. A loop with sharp skills becomes cheaper and more reliable over time.

  • Convert repeated tasks into named procedures.
  • After a hard run, save the recovery pattern.
  • Make validation commands part of the skill, not optional memory.
  • Prefer small loops with strong handoffs over one giant autonomous blob.
  • Treat budgets and halt rules as product requirements, not operational afterthoughts.

Recommended consumption path

  1. Read this explainer first; it compresses the article into operational terms.
  2. Open the original X Article if you want the discourse trail and named references.
  3. For Dab/Mission Control planning, focus on the loop anatomy and stop-rule sections, not the social-media debate.
  4. Potential follow-up item: define a standard “loop run manifest” for scheduled Dab jobs.

Source notes and limitations

Generated for Mission Control Link Triage. Backlink: item page. Source URL: https://x.com/mvanhorn/status/2063865685558903149.