Agent loops, for software engineers

A real AI loop needs a trigger.

Loops are not magic persistence. A useful loop wakes up from a real work surface, does a bounded action, leaves receipts, and knows when to stop.

Working definition

TriggerWhat wakes the loop up.

ActionWhat the agent does next.

CheckHow the loop evaluates progress.

ReceiptWhat artifact proves what happened.

StopWhen it finishes or asks a human.

How loops work

A loop is a small operating system for recurring work.

The agent is not the loop. The loop is the system around the agent: it watches for work, gives the agent a bounded task, checks the result, writes a receipt, and decides whether to stop.

Work appears

An issue, PR, error, stale doc, customer report, or scheduled review enters the surface.

Loop selects a task

The loop chooses a bounded next action instead of asking a human to keep prompting.

Agent uses tools

The agent reads, edits, tests, searches, or comments within a defined permission boundary.

Verifier checks it

A test, reviewer, rubric, screenshot, or checklist decides whether the work helped.

Receipt is written

The loop leaves a diff, log, report, comment, or checkpoint so a human can inspect it.

Stop or continue

The loop finishes, escalates, or picks the next task only if the trigger still has valid work.

The shift

Prompting is manual. Looping is delegated control.

The useful jump is not “the prompt repeats.” The useful jump is that the system can notice work, hand it to the agent, and preserve enough evidence for a human to trust or reject the result.

Human-driven

Prompting

You notice the work.
You write the next prompt.
You decide if the answer is useful.
You remember what happened.

System-driven

Looping

A real surface creates the trigger.
The loop hands out bounded work.
A verifier checks progress.
Receipts preserve the decision trail.

Receipts to show on screen

The source stack

Start with the public artifacts, then explain the missing nuance: loops need real triggers, reviewable output, and bounded judgment.

The quote

Peter Steinberger tweet

Stop prompting agents directly. Design loops that prompt them.

The library

Loop Library repo

Reusable loop prompts with checks, next steps, and stop conditions.

The fuzzy evaluator

Architecture satisfaction loop

Useful, but the stopping rule depends on judgment.

The real trigger

ClawSweeper

Issues and PRs create a recurring surface for an agent to scan.

The simple model

Trigger, action, check, receipt, stop.

Trigger

What wakes the loop up.

Action

What the agent does next.

Check

How the loop evaluates progress.

Receipt

What artifact proves what happened.

Stop

When it finishes or asks a human.

Where loops work

Production creates real triggers.

Peter Steinberger's OpenClaw/ClawSweeper setup makes sense because issues, PRs, stale work, and review queues keep appearing. The loop has a real reason to wake up.

Where loops are overkill

Fake triggers are procrastination.

If you are an individual builder and you already know the next step, you probably do not need a loop. You need to do the work. The loop becomes useful when similar work keeps returning.

The hard part

Evaluators are still fuzzy.

A lot of loops stop when the result feels good enough. That can work for architecture and creative review, but it is not the same as a production metric.

Talking outline

Seven beats for the video.

Everyone is saying: build loops, not prompts.
The useful definition: trigger -> action -> check -> receipt -> stop.
Peter's setup works because production repos generate real work surfaces.
Individual builders should be careful: fake triggers become procrastination.
The hard part is letting AI find useful work without inventing busywork.
The unsolved part is evaluators: many loops still stop subjectively.
Practical rule: build loops only where the work recurs and the receipt is reviewable.