Loop engineering: from prompting one message at a time to systems that run until proven done

The anatomy of a loop that deserves to run unsupervised: triggers, deterministic verifiers, memory outside the chat, budgets, and terminal states like DONE_WITH_EVIDENCE.

17 Jul 2026 15 min read

Loop Engineering Coding Agent Automation

Coding agents are usually introduced through a conversation. An engineer assigns a task, reads the result, corrects the direction, and sends another prompt until the change looks finished. That workflow is useful, but the person still acts as scheduler, memory, reviewer, and stop condition. Loop engineering moves those jobs into a repeatable system with explicit limits.

The name became popular in mid-2026, although the mechanism is older. An agent already cycles through context, tool calls, observations, and another model decision. Patterns such as Geoffrey Huntley's Ralph and Anthropic's progress files showed how that cycle could continue across tasks and context windows. Loop engineering turns those practices into an operational layer.

An agent loop is not automatically loop engineering

Every coding agent has an internal loop. The model receives a prompt, requests a tool, reads the tool result, and chooses what to do next. That machinery lets an agent test and revise its work instead of producing text once. Loop engineering operates one level above it by deciding when work starts, how it is divided, what evidence counts, which state survives, and when the system must stop.

A while true block is not enough. Without a verifier, the loop repeats the model's confidence. Without persistent state, it can rediscover the same failed approach. Without a budget and terminal states, it can consume tokens or alter more files simply because nothing tells it to stop.

Prompt, context, harness, and loop solve different problems

Layer	Question	Main artifact
Prompt engineering	What instruction governs this step?	Prompt, rubric, task instruction
Context engineering	What information must the model see now?	Files, retrieval, tool results, compacted history
Harness engineering	What environment lets one agent work safely?	Tools, sandbox, conventions, permissions
Loop engineering	How does work start, repeat, verify, persist, and stop?	Trigger, state machine, verifier, memory, budget

A strong loop still fails when its prompt is vague or its environment hides the test command. More context does not help if the verifier measures the wrong outcome. The unit of analysis changes from one answer to system behavior across many steps and runs.

The anatomy of an accountable loop

A practical loop needs a trigger, a testable goal, an executor, a verifier, persistent state, isolation, a budget, and a path back to a person. The parts do not need to be complicated. They do need to be named before the agent starts making changes.

Component	Purpose	Design question
Trigger	Starts a run from a schedule, event, issue, or request	What is important enough to start work?
Goal	Defines the required outcome	Can it be checked rather than described?
Verifier	Tests output against evidence	What must pass before completion?
Memory	Stores progress, failures, and decisions	What must survive after context is discarded?
Isolation	Stops runs from overwriting each other	Does each task have its own branch or sandbox?
Stop condition	Ends successfully, unsuccessfully, or through escalation	When must the agent stop even if the goal remains open?
Budget	Limits time, tokens, calls, cost, and scope	What is the maximum price of one result?

Named terminal states such as DONE_WITH_EVIDENCE, BLOCKED, NEEDS_HUMAN, and BUDGET_EXCEEDED are more useful than a model writing "task completed." The verifier must also inspect the latest artifact. A test run before the final edit does not prove the final edit is safe.

The verifier is the center of the loop

Output volume is not progress. A verification loop compares the result with a rubric or deterministic gate and returns concrete feedback when it fails. For code, that can include unit tests, type checks, security scans, browser tests, and a scope check on the diff. For documentation, it may be link validation, formatting, and source traceability.

Mechanical checks should stay mechanical. Status codes, schema validation, checksums, and database invariants are more consistent than asking another model whether something looks correct. A model reviewer can help with framing or prose quality, but it should not replace tests that already exist. Separating maker and checker also reduces the chance that an agent will rationalize its own work.

Memory belongs outside the conversation

A context window is not a project database. When a session ends or is compacted, decisions and failed attempts can disappear. A useful progress artifact records completed work, the next task, failed approaches, test results, limitations, and the last stable commit. Git history provides recovery, while repository instruction files preserve rules that should outlive any chat.

Not every note deserves permanent storage. Architecture decisions can remain for years; raw logs and scratch output should be filtered. A loop that keeps everything becomes expensive and buries the signal its next run needs.

Parallel agents need isolation

Several agents can reduce elapsed time when work separates cleanly. One can explore, another can implement, and a third can review. The benefit disappears when two agents edit the same migration or depend on an unfinished result. Worktrees, branches, containers, and sandboxes make ownership visible and keep one run from corrupting another.

Parallel output still needs integration. Someone must know which branch is authoritative, which checks ran, and how conflicts were resolved. OpenAI's Symphony case study used an issue tracker as that control plane after engineers found themselves managing several interactive sessions at once.

A regression repair loop

A narrow loop is easier to trust than automation for an entire development lifecycle. Consider a loop triggered by a failed main-branch test. An explorer collects the relevant commit, stack trace, and affected tests. An executor works in an isolated tree. The verifier reruns the original failure, the relevant regression suite, linting, and a diff-scope check.

The state file records the current hypothesis, attempted fixes, commit, and test evidence. Only DONE_WITH_EVIDENCE may open a pull request for review. An external dependency produces BLOCKED; a product choice produces NEEDS_HUMAN; exhausted time or tokens produce BUDGET_EXCEEDED.

Regression repair loop from a CI trigger through isolated work and deterministic verification to named terminal states — A regression loop repeats until its gates pass. Only DONE_WITH_EVIDENCE opens a pull request.

Automation changes the risk

A human-triggered loop for one task has a different risk profile from an event-driven system that reacts to schedules, webhooks, or new issues. Automatic triggers require idempotency, deduplication, retry policy, and stricter permissions. A loop that modifies its own prompts or graders is riskier again because it can improve its score by weakening the test.

Changes to a verifier should be reviewed like production code, with versioning, held-out evaluations, and rollback. Database migrations, financial operations, production deployment, permission changes, and data deletion should retain explicit human approval even when local tests pass.

The costs demos tend to hide

A loop turns one inference into many inferences, tool calls, tests, and reviews. Verification improves reliability but adds latency and cost. The useful economic measure is cost per accepted task, not the price of one prompt or the number of tool calls.

Teams also face comprehension debt. Agents can generate changes faster than engineers can understand them. That debt surfaces during maintenance and incidents. Connector access adds a security cost because instructions hidden in issues, email, documents, or web pages can try to redirect the agent. Least privilege, sandboxes, allowlists, approval gates, and audit trails need to exist from the start.

When loop engineering is worth using

Good candidates are repetitive jobs with outcomes that can be tested: CI triage, dependency updates, link-checked documentation, migrations with invariants, reconciled data cleanup, and bug fixes with a reproducer. Product positioning and architectural negotiation are less suitable because their goals change while people discuss them.

Start with one narrow workflow, one source of truth, one deterministic verifier, one budget, and one escalation path. Expand the trigger, parallelism, or scope only after failures are visible and reproducible. The aim is not an infinite loop. It is a system that can keep working until it has evidence to stop.