The Anatomy of Loop Engineering: Actions, Components, and Antipatterns¶

For / Key Points

For: Developers and technical leads designing autonomous loops, scheduled runs, or multi-agent workflows with Claude Code, Codex, or similar coding agents.

Key Points:

A loop's cost is driven by how many turns a mistake survives, so loop design is mostly about shortening the distance from mistake to discovery.
One turn decomposes into discovery, handoff, verification, persistence, and scheduling; removing any one creates a specific antipattern.
The evaluator sets the floor for a loop, so self-grading should be replaced with a skeptical, structurally separate reviewer.

Imagine that one night, a loop opens 20 pull requests. Every test is green. Three of those PRs still contain bugs in paths the tests never touched. Without independent verification, those three changes merge and sit in the codebase for days.

That is the central intuition of loop engineering. The cost of a mistake is proportional to the number of turns it survives before discovery. Left alone, a loop is a machine for increasing that number.

The previous article, What Is Loop Engineering?, covered the concept. That article covers the definition, lineage, and adoption decision; this one focuses on auditing a loop already in operation. This article answers a narrower question. How should a loop be assembled, where does it fail, and how should it stop?

The Five Actions Inside One Turn¶

One turn is not just "run again." In Addy Osmani's framing, a loop finds work, isolates it, checks it, records state, and schedules the next pass¹. It is a small control system around the agent.

A morning triage loop makes the mechanics concrete. It wakes on a schedule, reads failed CI jobs, unresolved issues, and recent commits. It creates separate worktrees for items, sends one agent to draft a fix, sends another to check it against tests and project knowledge, updates PRs or tickets, sends uncertain work to an inbox, and writes a state file for the next run.

That turn splits into five actions.

Action	What it does	In a triage loop
Discovery	Finds this turn's work	Reads CI, issues, and commits
Handoff	Slices and isolates work	Creates one worktree per item
Verification	Adds a separate no-saying perspective	Evaluates against tests and specs
Persistence	Writes state outside the conversation	Updates PRs, inbox, and state files
Scheduling	Starts the next turn automatically	Runs on a timer or event

Discovery sets the ceiling. If the loop chooses low-value work, the rest of the system can only execute waste more elegantly. Verification is the only action that can say no, which makes it the easiest to skip and the most dangerous to skip.

Scheduling is what turns a run into a loop. If it runs once and stops, it is a batch job.

Six Components Support Those Actions¶

Actions describe what happens. Components describe what must exist for those actions to happen. Osmani's list has five components plus memory that survives outside the single conversation¹.

Component	What it is	Supported action
Automation	A schedule or event trigger	Scheduling
Worktree	An isolated directory for parallel agents	Handoff
Skill	Project knowledge pinned in a single file	Discovery
Connector	A way into external systems, often through MCP (Model Context Protocol)	Discovery and persistence
Subagent	A separate generator or evaluator role	Verification
Memory	Durable state on disk or in a system of record	Persistence

The easy confusion is memory versus context. Context is what the agent can see in the current turn. It can be compacted, reset, or lost. Memory is what persists across turns and days.

A loop can resume yesterday's work because the result lives in Markdown, an issue, a board, or a PR. The agent forgets. The repository does not.

Missing Actions Create Five Failure Modes¶

Loop failures map cleanly to the five actions. Remove one action and a specific antipattern appears.

Antipattern	Missing action	Symptom	Fix
Nodding loop	Verification	Hundreds of turns without one real rejection	Separate generation from evaluation
Amnesiac loop	Persistence	Every morning starts from the same point	Write durable state files
Manual loop	Scheduling	The last run was the demo day	Use a real timer or event trigger
Blind loop	Discovery	A human picks the work every morning	Put discovery logic into a skill
Tangled loop	Handoff	Parallel execution reveals edit collisions	Use one worktree per task

The most common failure is the nodding loop. The agent writes code. The same agent declares it good. There is no independent check, so plausible mistakes accumulate at machine speed.

The symptom is clear. If a loop runs for hundreds of turns and never tells itself no, it probably has no real inspection. The previous article's example of a PR-monitoring loop that produced 43 commits in a day and had almost everything rejected fits this pattern⁶.

The other four failures are just as readable. An amnesiac loop stores the result only in context, then rediscovers the same work tomorrow. A manual loop depends on a person to start it and is eventually forgotten. A blind loop waits for a human to hand it the next task. A tangled loop lets multiple agents edit the same working directory.

The practical danger is that these failures cluster. A team that skips verification often skips persistence too. Loose loops tend to build the visible parts, such as discovery and handoff, while skipping the safety-producing parts: verification, persistence, and scheduling discipline.

How to Build Verification That Can Say No¶

Self-evaluation is lenient. In Anthropic's long-running application harness work, Prithvi Rajasekaran observed that agents asked to grade their own output often confidently praised mediocre work².

This is not an intelligence problem. It is the structure of the assignment. The author can still see the chain of reasons that led to the code, so the output is filtered through its own self-justification.

The effective move is not to make the generator more self-critical. The effective move is to introduce a skeptical evaluator as a separate agent. Anthropic's harness used a planner, generator, and evaluator architecture inspired by generative adversarial networks².

Reading code is not enough. For frontend work, Anthropic gave the evaluator Playwright MCP so it could open the page, click buttons, take screenshots, and inspect the DOM. That moves the basis of judgment from "the JSX looks plausible" to "the user action produced the expected behavior."

The evaluator instruction can be short.

File: .claude/agents/reviewer.md
Role: adversarial code reviewer.
Assumption: the code is broken until proven otherwise.
Do not praise. Find failure modes.
Check in order:
1. Run it before reading it.
2. Run tests and paste output.
3. Probe skipped edge cases.
4. Compare behavior with the ticket.
For UI work, use Playwright MCP to open, click, screenshot, and inspect DOM.
Verdict: PASS only if all checks pass; otherwise REJECT with reasons.

Claude Code's /goal packages a related idea around stopping conditions. You provide a completion condition, and after each turn a small fast model checks whether the condition holds; if not, Claude starts another turn³. The worker and the stopper are not the same decision point.

Codex's /goal templates separate continuation behavior, token budget, evidence-based completion audit, and budget-limited wrap-up behavior⁴. For the Codex-specific anatomy, see the earlier /goal deep dive. The key distinction is simple: do not confuse a goal that runs until a condition is met with a loop that merely re-runs on an interval.

Generator-evaluator separation costs money. Anthropic's comparison showed a solo run taking 20 minutes and $9, while the full harness took six hours and $200, more than 20x the cost². This is a structure for work where quality matters.

The evaluator sets the floor of the loop. The generator determines what can be made. The evaluator determines what must not ship.

What Supports Stripe's 1,300 PRs per Week¶

At enterprise scale, Stripe's internal "Minions" are the most useful example. In Steve Kaliski's walkthrough, Minions are triggered from Slack reactions and produce roughly 1,300 PRs per week⁵. Humans are still present, but they are reviewing rather than typing the implementation.

The reliability story does not end with a model name. Stripe forked and adapted the open-source Goose agent harness, then connected it to Stripe's internal tools, code search, tests, and cloud development environments⁵. The important work happens before the model starts.

The loop assembles context from the Slack message, target repository, code search, internal docs, and tickets. The more deterministic a step is, the less reason there is to hand it to a probabilistic model. The design principle is straightforward. Do not give probabilistic models work that deterministic logic can handle.

Disposable cloud development environments matter too. Each Minion runs in a fresh branch and environment, producing isolated changes in parallel. CI, test coverage, blue-green deployments, and human code review form the safety rail⁵.

The human did not disappear. The human moved desks. From writing to reviewing.

Four Quiet Debts Accumulate¶

A self-running loop is also a self-running mistake generator. Four debts accumulate without sounding alarms.

Verification debt: unverified output remains in the codebase
Understanding decay: the human mental model falls behind the change set
Cognitive surrender: smooth automation makes people stop reading
Token blow-up: retries and helper agents inflate cost

Return to the 20 PR example. Three hidden bugs merging is verification debt. Approving 20 changes without reading them creates understanding decay. Skipping the next morning's batch is cognitive surrender. Retrying all night with extra helper agents is token blow-up.

These are not independent risks. One failure shows four faces and each face strengthens the others. The more unverified output accumulates, the harder it becomes to understand the codebase; the less humans understand, the more they surrender judgment; the less they watch, the longer the loop runs.

Three Operating Disciplines¶

The defense against understanding decay is not reading every output. That would erase the value of automation. Read representative samples every day and check whether you can explain what changed and why in your own words.

If you cannot explain a change, your mental map has fallen behind the codebase. It is cheaper to notice that in a quiet sample PR than in a production incident.

The defense against token blow-up is a hard budget before the first unattended run. Set per-run budget, daily budget, and max retry count before the first surprising bill. This is less about saving money than installing a circuit breaker.

The defense against cognitive surrender is structural. Keep at least one pause point for humans inside the loop. Not because humans must always intervene, but because humans must remain in a position where intervention is possible.

Build the First Loop Today¶

Stripe's pipeline is an endpoint, not a starting point. The first loop can be small enough to feel almost silly: a timer that checks something every morning. The following is design pseudocode, not an executable GitHub Actions workflow.

trigger: "every day at 06:00"
discovery: "read failed CI jobs and unresolved issues"
isolation: "create one worktree per item"
verification: "evaluate until tests and lint pass"
persistence: "write results to a PR and state file"
human_gate: "wait for review instead of auto-merging"

Even this small design sheet exposes missing parts. During implementation, map each field to the product's supported mechanisms, such as schedules, skills, worktrees, and /goal.

Use this checklist before implementation.

Element	Question
Discovery entry	What does the timer read: CI, issues, commits, or inbox?
State file	Which file or system remembers across turns?
Evaluator	Is there an independent check that can say no?
Isolation	Does each parallel agent have its own worktree?
Token cap	What is the spending limit, and who stops runaway work?
Human review	Where does the loop stop before full automation?

Parallelism should come last. Before increasing how many agents run, increase the quality of what they discover. Before coordinating many agents, prove that one bad agent can be stopped by the evaluator.

Summary¶

Loops make generation cheap. Code, plans, PRs, and fixes become easy to produce. Judgment remains scarce.

Which plan is right? Which line should be stopped? Which output works locally but is wrong in principle? A loop can produce a hundred options, but it cannot truly choose.

The same tool widens the gap between two kinds of engineers. If the value came from mechanical labor, that value evaporates. If the value came from judgment, the loop amplifies it. A loop does not lift everyone equally. It multiplies what each person brings into it.

Amplifiers cut both ways. Bad judgment is also repeated faithfully, at scale, hundreds of times. In the older world, a bad decision was slowed down by manual execution. In the new world, the slow gear is gone.

Building a loop is no longer the hard part. The hard part is deciding which judgments you will keep before the loop starts running. The loop multiplies the designer. Bring understanding and it multiplies understanding. Bring laziness and it multiplies laziness.

Addy Osmani, Loop Engineering, June 7, 2026. ↩↩
Prithvi Rajasekaran, Harness design for long-running application development, Anthropic Engineering Blog, March 24, 2026. ↩↩↩
Claude Code Docs, Keep Claude working toward a goal. ↩
openai/codex, continuation.md and budget_limit.md. ↩
Claire Vo, How Stripe built "minions": AI coding agents that ship 1,300 PRs weekly from Slack reactions, Lenny's Newsletter, March 25, 2026. ↩↩↩
MAKE A CHANGE, inc., Loop Engineering: Concepts and Operational Lessons (Japanese). ↩