Most teams still treat agent reliability as a prompt problem. Write better instructions. Add another bullet. Hope Task B does not break when Task A finally passes.
That loop breaks the moment your agent runs longer than one chat turn.
Loop engineering is the shift from editing prose to designing control systems: verifiable goals, external oracles, durable state, halt conditions, and background optimizers that update skill files when live trajectories fail. The leverage point moved. Prompt engineers become loop architects.
This is the frame behind Microsoft's SkillOpt, the Sunday deep dive in Alpha Signal's June digest, and a growing stack of production tooling from Cursor, Claude Code, and Codex.
Prompt engineering vs loop engineering
Prompt engineering asks: "What should the model read once?"
Loop engineering asks: "What system repeats until an external truth says stop?"
| Layer | Prompt engineering | Loop engineering |
|---|---|---|
| Unit of work | Single completion | Cycle until gate passes |
| Success signal | Human thumbs up | Automated verifier |
| State | Chat window | Repo files, boards, tags |
| Failure mode | Wrong answer once | Silent drift across runs |
| Operator role | Typist | Control-system designer |
Addy Osmani puts it plainly: loop engineering replaces you as the person who prompts the agent. You build the machinery that prompts, checks, and resumes.
IBM's definition matches: agent loops dynamically act, observe, decide, and iterate until a recursive goal is satisfied, with explicit stopping criteria to control token burn.
The five blocks I actually ship
Every production loop I deploy converges on the same skeleton. Names vary by tool; the physics does not.
1. Recursive goal with halt conditions
The agent needs a testable target, not "make it better." Break work into subtasks with clear done states. Cap iterations and token spend so a stuck loop cannot drain the budget overnight.
Claude Code exposes /goal and /loop. Codex has Automations with schedules and triage inboxes. Same idea: fire on a cadence, stop on a condition.
2. External oracle (not self-grade)
A loop earns its cost only when something objective can fail the work without you in the room: test suite, type checker, linter, build, schema validator.
Anthropic's Building Effective Agents calls this the evaluator-optimizer pattern: one model generates, another critiques, repeat. The critique only works when the signal is real. A second LLM told to "review this" with no ground truth just adds a second optimist.
If your gate is vibes, you are not loop engineering. You are automating hope.
3. Durable state (the spine)
Agents forget. Repos do not.
Osmani's rule: externalize progress to markdown, Linear, or a tracker the next run reads cold. Carrying full transcripts forward makes cost quadratic and reintroduces context rot. A state file keeps resume cheap.
Alpha Signal's companion piece, Most Developers Do Not Need Agent Loops Yet, recommends the smallest viable stack: one automation, one skill file, one state file, one gate. Get a manual run reliable before you schedule it.
4. Maker-checker and subagents
Split roles when complexity warrants it: explorer reads, implementer patches, verifier runs the gate. Codex subagents live in .codex/agents/; Claude Code uses .claude/agents/ and agent teams.
Each subagent burns its own tokens. Use them when parallel specialization beats one bloated context, not by default.
5. Background skill optimization
The outer loop runs production tasks. An inner loop (SkillOpt, GEPA, EvoSkill) watches failures, proposes bounded skill edits, and promotes changes only after validation.
That is how text-space optimizers fit: they are training loops for markdown, not replacements for your test suite.
When loops are worth it (four gates)
Run this checklist before you schedule anything overnight:
| Gate | Question |
|---|---|
| Repetition | Will this task run again next week? |
| Automated check | Can tests/types/build fail bad output without you? |
| Token budget | Can you afford 3 to 10 retries per run? |
| Tool access | Does the agent have the same tools a senior dev would? |
Miss any gate and you are back in the chair reading every diff. That is fine for exploration. It is not a loop.
A 2026 study on async coding agents cited in the Alpha Signal piece got gains from git worktree isolation plus verification, not from adding more agents. Isolation and gates beat headcount.
Anti-patterns I see in the wild
Self-grading loops. The model marks its own homework passed. Capability drift follows.
No rejected-edit memory. SkillOpt's rejected-edit buffer exists because plausible-sounding fixes often hurt held-out scores. Production loops need the same discipline: log failed attempts, do not repeat them.
Unbounded recursion. Without max iterations, a loop optimizes for motion, not outcome.
Optimizing before you can measure. SkillOpt, GEPA, and EvoSkill all require verifiable feedback. Subjective copywriting tasks are the wrong target.
A minimal loop you can ship this week
If you have never run an unattended agent cycle, start here:
# 1. One SKILL.md with project context (paths, commands, non-negotiables) # 2. One STATE.md (done / next / blocked) # 3. One npm test / pytest / tsc gate that exits non-zero on failure # 4. One scheduled automation or /loop with max 5 iterations
Manual run first. Watch where it lies about success. Fix the gate. Then schedule.
When failures cluster around one workflow (pagination, CRM field mapping, voice handoff rules), that is when I attach a text-space optimizer to the skill file and let validation pick the winner.
Where this goes next
The era of tweaking individual phrases in a system prompt is closing. Engineers who win the next cycle design feedback systems: metrics, memory, exit conditions, and safe promotion paths for optimized skills.
Models will keep getting stronger. Loops determine whether that strength compounds or evaporates across sessions.
If you are standing up agent loops for ops (voice, CRM, internal tools) and want help picking gates and skill structure before you burn a month of API spend, book a free discovery call. The first question I ask is always the same: what fails objectively when the agent gets it wrong?