A design pattern called “loop engineering” is being formalized by agent builders as the next layer in the stack that began with prompt engineering. The core shift: developers stop triggering agents manually and instead design systems where agents discover work, execute it, verify their own output, persist state, and schedule their next run autonomously.
An in-depth framework published by Efficient Coder lays out loop engineering as a four-layer stack. Prompt engineering manages a single prompt. Context engineering manages what’s in the context window. Harness engineering manages a single run’s tooling and completion criteria. Loop engineering sits above all three, managing the scheduling and persistence that makes an agent run again and again without human intervention.
Five Moves of a Loop
The framework breaks each loop iteration into five discrete steps, each of which must work for the loop to function:
Discovery. The agent identifies what needs to be done. In a triage loop example, an automated skill reads yesterday’s CI failures, open issues, and recent commits. The agent finds the work itself rather than receiving a task list.
Handoff. Each discovered task gets isolated execution. In the example, each item gets its own git worktree, preventing the collision problems that occur when two agents write to the same file.
Verification. A separate agent with different instructions reviews the first agent’s output. The framework emphasizes that the agent that wrote code cannot reliably evaluate it because its context is already full of self-justification for its choices. A skeptical second agent catches what the first talked itself into.
Persistence. Results must survive beyond the current conversation. Changes go into pull requests, tickets get updated, and a state file tracks progress. The framework’s core insight here: “The agent forgets; the repo doesn’t.”
Scheduling. Automation triggers the next iteration without human action. Unfinished work carries over through the state file, so each iteration picks up where the last one stopped.
Six Required Components
The framework maps the five moves to six infrastructure components that a loop needs: automations (cron-like triggers, not giant prompts pasted into schedulers), worktrees for parallel isolation, skills (reusable knowledge files that agents load each iteration instead of re-receiving context), MCP connectors to external systems, sub-agents (separate generator and evaluator roles), and persistent memory stored on disk rather than in context windows.
The Generator-Evaluator Split
The framework argues that the generator-evaluator separation is the hardest part to get right. Asking an agent to evaluate code it just wrote produces consistent self-praise even when quality is mediocre, because the agent’s context is filled with its own reasoning trail. Tuning a standalone evaluator to be skeptical is described as “far more tractable than making a generator critical of its own work,” according to Efficient Coder.
Practical Implications for Agent Builders
Loop engineering addresses the scalability wall that teams hit when agentic systems work well in demos but require constant human triggering in production. The cost considerations are significant: autonomous loops can run up unpredictable bills if cost controls, observability, and fault tolerance are not built into the scheduling layer. But for teams already operating agents in production, the framework offers a structured path from “I run the agent” to “the agent runs itself.”