# Loop Engineering: From Writing Prompts to Designing Manageable Work Loops

The core of Loop Engineering isn’t “writing better prompts” — it’s designing the repeated human act of driving AI into a closed loop that is repeatable, recoverable, verifiable, and governable.

The Shifting Focus Across Four Engineering Layers

Layer	Focus	Typical artifacts
Prompt Engineering	A single model response	prompt, system message
Context Engineering	Attention budget	rules, skills, retrieval
Harness Engineering	Agent execution environment	sandbox, hooks, permissions
Loop Engineering	Cross-turn work loop	trigger, verifier, handoff, eval

In one sentence: Loop Engineering turns the Agent from an “interaction target” into a “manageable workflow unit.”

The Loop Contract: Eight Questions You Must Answer

Designing a loop requires defining, at minimum:

1. Trigger — what event starts it: a schedule, an issue change, a CI failure, a PR comment?
2. Workspace — which isolated environment: worktree, container, remote sandbox?
3. Context — what’s injected by default, what’s retrieved on demand?
4. Executor — who executes: the main Agent, a subagent, a script?
5. Verifier — what’s the stop condition: tests, lint, an independent evaluator?
6. State — what state is left behind for the next round?
7. Budget — what are the token, time, and retry limits?
8. Handoff — when does it escalate to a human?

Discover task → Assign environment → Inject context → Agent executes
        → Independent verification → Record state → Human review/escalation → Next round

The Essential Difference Between Loops and Prompts

A prompt optimizes a single turn of conversation: is the instruction clear, is the format stable.

A loop optimizes a category of ongoing work:

• Which work is worth turning into a loop?
• Is every execution run in an isolated environment?
• Can the result be verified programmatically or semi-programmatically?
• At which point does human intervention have the most leverage?

A poorly designed loop automatically amplifies errors, drift, cost, and permission risk.

Four High-Leverage Points for Humans in a Loop

Loop Engineering isn’t about removing humans entirely — it’s about moving humans to high-leverage positions:

Point	Role
Designing the loop	Defining the contract, permissions, verifier
Reviewing exceptions	Handling cases the verifier can’t automatically resolve
Improving the verifier	Turning repeated manual judgment into a sensor
Governance and metrics	Tracking completion rate, intervention rate, cost

Relationship to Inner / Middle / Outer Loop

• Inner Loop: a human pairing with an Agent inside the IDE (a loop within a single session)
• Middle Loop: PR, review, CI fixes (a loop across sessions)
• Outer Loop: release, metrics, organizational learning

Loop Engineering provides a contract language common across all three layers; see Inner / Middle / Outer Loop and Harness Engineering.

Pilot Metrics

When introducing a loop, it’s recommended to track:

• Completion rate — the share of runs the verifier passes without human intervention
• Human intervention rate — the share requiring escalation
• Cost per completed task — full cost including retries and review
• Time to verified output — from trigger to verifier passing

Five Common Anti-Patterns

1. A loop with no verifier — only generation, no verifiable stop condition
2. Parallel loops sharing a workspace — multiple loops contaminating each other
3. A prompt masquerading as a loop — using a long prompt in place of trigger/state/handoff design
4. A verifier that’s too weak — passing lint is treated as done
5. No escalation path — the only option when an Agent gets stuck is a manual kill

References

• Addy Osmani, Loop Engineering (2026)
• OpenAI Codex: Automations, Goals, Worktrees, Skills
• Anthropic Claude Code: scheduled tasks, subagents, hooks