Loop engineering
Loop engineering is the practice of designing an agent's iterative workflow — the loop it runs to make and check progress — rather than crafting a single prompt. The unit of work shifts from prompt → loop: instead of phrasing one request well, you define a goal, a stop condition, and a feedback signal, and let the agent iterate against its own prior work (files, tests, git history) until the condition is met. Named and popularized in 2026 around Claude Code / OpenAI Codex usage (agent-loops-verification, arjun-iyer).
Relationship to the rest of the wiki
- The Ralph technique (Geoffrey Huntley) is the canonical concrete instance: feed the same prompt repeatedly, the agent sees its previous work each pass and improves until a completion promise fires. Loop engineering is the general discipline; Ralph is one pattern. auto-company is Ralph with the stop condition removed: a daemon re-invokes the CLI every 30s against a company charter, indefinitely. With no completion promise to fire and no external feedback signal to terminate on, the author had to legislate the phases instead (cycle 1 ideate → cycle 2 GO/NO-GO → cycle 3+ build; "pure discussion is forbidden"). Useful negative result about what an unbounded loop does when nothing external can tell it it's done.
- It is the authoring-time complement to the agentic-coding-harness (the structure the loop runs in) and to agent-orchestration (how loops fan out across subagents). spec-driven-development is loop engineering with a reviewable spec as the goal artifact.
- self-improving-agents is a loop whose output is new skills — the loop turned on the agent's own capabilities.
A runtime built for the discipline (2026-09-01)
inferoa is the first source here that builds a harness around the loop rather than adding a loop
to a harness. /loop "carries an objective across loop tasks, verification, decisions, recovery, and
completion evidence instead of stopping after the next answer" — Ralph's completion promise renamed
completion evidence and given independent feedback surfaces to rest on (plans, tests, tool
results, research metrics), which is exactly the gap auto-company fell into when it removed the
stop condition and had to legislate phases instead.
Its distinctive claim is about cost rather than correctness: a long loop is an inference workload, and prefix-cache reuse, mutable-context growth and model routing all degrade as turns accumulate. So the harness exposes serving to the loop — prompt epochs and deterministic tool schemas to protect cacheable prefixes, bounded history and tool output, routing by cost/privacy/capability. Unevaluated: the project publishes no measurements, and it has not been touched since 2026-06-18.
The verification corollary
Loop engineering's central consequence (agent-loops-verification): when the loop generates faster
than a human can review, the binding constraint moves from generation to verification. A loop is
only as good as its feedback signal — "feedback is only as truthful as the system that generates it."
So the value migrates to the verification layer: cheap, faithful checks the loop can run every
iteration. This is why the wiki's output-grounded-verification pattern (ai-job-search compiling and
reading its PDF; watch-skill watching the rendered video of its own work; renwei-writing's
checklist) and the containment discipline of agent-guardrails matter more, not less, as loops replace
prompts. Anthropic's own verification-loops-skills gives this its concrete floor: author the check as a
skill (.claude/skills/…/SKILL.md) so Claude runs the verification, and the fix, on
itself every iteration — the reusable form of "a cheap faithful check the loop can run" — and why, for cloud-native code, verification becomes a
runtime problem (the platform-ops cross-spoke seam).
The feedback-signal point has first-party backing. Anthropic (building-effective-agents) frames the loop's competence as reading "'ground truth' from the environment at each step (such as tool call results or code execution)," and recommends explicit stopping conditions ("such as a maximum number of iterations") to keep a self-directed loop bounded — the generation-side counterpart to the verification constraint.
When the loop edits the agent itself
A loop whose output is the agent's own capabilities is the self-evolving case (self-evolving-agents-survey): the survey models any such system as a feedback loop over four parts — System Inputs, the Agent System, the Environment, and Optimizers (what drives the change). Loop engineering is that frame applied to a task; self-improving-agents applies it to the agent's skill set. Both stand or fall on the same thing — a feedback signal truthful enough to optimize against.
Related
agent-loops-verification · agentic-coding-harness · agent-orchestration · self-improving-agents · spec-driven-development · agent-guardrails · ai-job-search · watch-skill · verification-loops-skills · agent-evals · building-effective-agents · self-evolving-agents-survey