This single-author position paper from the Instituto Federal de Goiás in Brazil sets out to give the mid-2026 practitioner slogan behind Loop Engineering — stop prompting the coding agent at every step and design the loop that prompts it — a reviewable account. It notes that the concept arrived through threads, talks and blog posts rather than through any reviewable account, and asks what exactly is being built, how it relates to the loops that already exist inside an agent, what a corpus of real loops looks like, and which practitioner claims survive contact with the scientific literature.
Its central move is to fix the object of study as the Loop Specification: an external, bounded, reusable artifact — trigger, goal, verification, stopping rule and memory — that a human designs and hands to an agent harness such as Claude Code or Codex. This is kept separate from an ordinary programming loop and from the internal cycle in which the model runs tools over a stop condition, which the paper treats as plumbing of the Agent Harness: “the harness supplies the engine; loop engineering writes the pilot.” It places loop engineering as a fourth layer after Prompt engineering, Context engineering and Harness Engineering, each subsuming the previous one, and argues against the strongest headlines that loops do not make prompt engineering obsolete.
The paper then gives an anatomy and taxonomy of loop specifications, codes the fifty loops of the public Loop Library catalogue by hand, distils design principles and anti-patterns, and releases an authoring skill, sandeco-loop, as an accompanying deliverable. It explicitly runs no loops under a measured budget and claims no benchmark result.
Key Points
- The paper defines a loop specification as a bounded, reusable artifact of five parts — a trigger (a person, a schedule or an event), a preferably verifiable goal, an execution phase ideally calling proven named skills, a real verification, and a stopping rule driving the loop to a named terminal state — plus a memory of progress and decisions kept on disk rather than in the conversation.
- It holds that the central skill of the practice is designing the check that decides when the work is done, not writing a better prompt, and that a loop is justified over a bare scheduled prompt only when the result of one turn changes the next action.
- Its taxonomy classifies loops by trigger, goal type (verifiable, judged by a model against a rubric, or mixed), a five-level Verification Ladder, architecture (solo, maker–checker, or manager orchestrating helpers) and named terminal states (success, no-op, blocked, stalled, exhausted), with an error or exhausted budget never counting as success.
- In its hand-coding of the fifty Loop Library loops, half verify deterministically and seventy percent verify in the ladder’s autonomous zone; seventy-four percent name their terminal states and sixty-six percent set a verifiable goal.
- The same corpus is least developed where loops would run without a person: the trigger is manual in seventy-eight percent of loops, seventy-eight percent run a single agent, only twenty percent call named reusable skills, and only thirty-two percent develop persistent memory — which the paper calls a maturity mismatch.
- Of the eleven loops whose dominant check is a model judge, most pair it with a maker–checker architecture or a separate critic.
- It organizes design principles into four families — define “done” before anything else, act without breaking what works, earn trust in the result, and sustain the loop over time — and names five anti-patterns: the while-true around a stranger, the self-approving loop (reward hacking), specification gaming, pretending level 4 is level 1, and the unattended runaway.
- It proposes cost per accepted change — tokens or money spent divided by the number of changes that survived verification — as the headline metric for the empirical study it does not itself run.
- Its limits for the practice include the verification burden, Comprehension Debt and Cognitive Surrender; it argues that the loop automates the typing, not the judgment, and lists cases where a loop is the wrong tool.
Notes
The author describes the fifty-loop coding as a qualitative reading of a single public catalogue that another coder might code differently, not a random sample of loops in the wild, and states that the transfer of lessons from research on the internal agent cycle to the external loop is an argued analogy rather than a measured result. No usage data is reported for the released skill. Among its illustrations, it presents the Ralph Loop as the purest case of keeping all state in files while replaying the same prompt with a fresh context each turn. The paper draws its operational anatomy of a loop system from a practitioner post, Loop Engineering, and cites Designing agentic loops among its practitioner sources.