Loop engineering is the practice of designing a system that prompts and manages an AI agent for you instead of requiring you to micromanage each turn. In the simplest terms, you stop asking the model one question at a time and instead build a loop that discovers work, assigns it, checks it, records what happened, and decides what to do next.
That makes loop engineering different from ordinary prompt engineering, context engineering, and harness engineering. Prompt engineering shapes one interaction. Context engineering helps the agent gather its own information. Harness engineering helps manage longer executions. Loop engineering sits above those layers and adds a recurring control loop that can keep working without a human re-prompting every step.
What loop engineering is
A loop in this context is a recursive goal: define a purpose, let the agent iterate, then stop when the system believes the goal is complete. Addy Osmani describes loop engineering as replacing yourself as the person who prompts the agent and instead designing the system that does the prompting.
A practical loop usually does four things:
- Finds work
- Breaks work into tasks
- Executes or delegates tasks
- Verifies results and records state
The key idea is not “more AI” for its own sake. It is an external structure that makes agent work repeatable, monitored, and less dependent on live human intervention.
How loop engineering differs from adjacent patterns
| Pattern | Main job | Typical limit |
|---|---|---|
| Prompt engineering | Tell the agent what to do in one interaction | Requires manual re-prompting |
| Context engineering | Let the agent gather needed information | Can get leaky on longer tasks |
| Harness engineering | Manage long-running agent execution from outside the context window | Still usually depends on a human to initiate work |
| Loop engineering | Run a self-sustaining system that keeps prompting, checking, and continuing | Can be costly and can drift without controls |
The important distinction is that loop engineering is not just a longer agent session. It is a supervising system around the agent that decides what happens next.
The core components of a loop
Based on the reference material, a useful loop has six parts:
-
Automations
Scheduled runs that discover work or perform triage automatically. -
Worktrees
Isolated branches or working directories so parallel tasks do not collide. -
Skills
Written project knowledge that reduces repeated explanation and keeps the agent aligned with your conventions. -
Plugins and connectors
Integrations that let the loop interact with real tools, such as repositories, issue trackers, or other external systems. -
Sub-agents
Separate agents that can draft, critique, verify, or specialize in different parts of the job. -
State
A persistent record of what happened, what is done, and what comes next. This can live in markdown, a board, or another durable store outside the chat.
Why each component matters
- Automations turn a one-off agent session into a recurring process.
- Worktrees reduce contamination when multiple tasks run at once.
- Skills preserve project-specific intent.
- Connectors let the loop take action in the real world instead of only describing actions.
- Sub-agents separate creation from verification.
- State prevents the loop from forgetting every time it restarts.
A concrete example: maintaining a World Cup website
The reference material gives a useful example.
Imagine an AI builds a website that tracks World Cup scores. That initial build can be handled by prompt, context, and harness engineering. But the site now needs ongoing updates because games happen daily and bugs will appear over time.
A loop-engineered system could do the following:
- Run on a schedule
- Check for new score updates
- Review user-reported bugs
- Open isolated worktrees for each fix
- Use sub-agents to draft and review changes
- Use connectors to open a pull request or update a tracking board
- Store progress so the next run knows what has already been tried
That is loop engineering in practice: the system keeps prompting itself to maintain the project.
The maker-checker principle inside loops
One of the strongest ideas in loop engineering is separating the agent that makes the change from the agent that checks it.
Why this matters:
- The model that wrote the code is often too lenient when reviewing its own work.
- A second agent can catch mistakes the first agent rationalized away.
- A verifier can use different instructions, different tool access, or even a different model.
This is the same old engineering principle of independent review, applied to autonomous AI work.
When loop engineering is useful
Loop engineering is most useful when work is:
- Repetitive
- Ongoing
- Easy to triage
- Easy to verify
- Spread across multiple small tasks
- Tied to external state that changes over time
Good examples include:
- Daily issue triage
- CI failure summaries
- Routine bug fixing
- Periodic content or data updates
- Scheduled maintenance tasks
- Multi-step repository work that can be checked against clear criteria
When loop engineering is a bad fit
Loop engineering is not automatically better. It can be the wrong choice when:
- The task is one-off and simple
- The outcome is hard to verify
- The cost of extra iterations is high
- The environment is noisy or unstable
- The work requires deep human judgment at every step
- The loop would create more token spend than value
The reference material is explicit about token cost risk. Long-running or overly broad loops can become expensive fast, especially if they repeat work, over-summarize, or keep investigating without a clear stopping condition.
Failure modes to watch
1. Token drift
The loop keeps running even though the task is no longer producing useful progress.
Mitigation: use clear stopping criteria and review the actual output.
2. Leaky summarization
Important details disappear when a long task tries to compress its own history.
Mitigation: store durable state outside the context window.
3. Self-approval bias
The same agent that wrote the work claims it is correct.
Mitigation: use a separate verifier sub-agent.
4. Over-automation
The loop starts doing work the team does not understand well enough to trust.
Mitigation: keep humans in the review path for high-risk outputs.
5. Context sprawl
The system keeps gathering information but never turns it into a decision.
Mitigation: require a clear triage output and a next action.
A simple design checklist
Before you build a loop, ask:
- What recurring job am I trying to automate?
- How will the system discover new work?
- What is the stopping condition?
- Where will the state live?
- How will parallel tasks be isolated?
- Which step verifies correctness?
- What tool integrations are required?
- What should still require human approval?
If you cannot answer those questions, the loop is probably premature.
A practical loop design template
A reliable starting shape looks like this:
-
Trigger
A schedule, event, or manual start. -
Triage
The agent inspects the repo, issues, logs, or source of truth. -
Plan
The loop decides whether there is work worth doing. -
Execute
A sub-agent or worker makes the change in an isolated worktree. -
Verify
Another agent checks tests, diffs, or criteria. -
Persist
State is written to disk or a tracking system. -
Repeat or stop
The loop either continues or exits based on the stopping condition.
This structure is simple on purpose. Complexity should come from the work, not from the control logic.
What loop engineering is really changing
Loop engineering does not eliminate prompt engineering, context engineering, or harness engineering. It builds on them.
The bigger shift is that the unit of work changes:
- From “ask the agent a question”
- To “design the process that repeatedly asks, checks, and continues”
That is why loop engineering is often described as moving the leverage point upward. You are no longer only writing prompts. You are writing the operating system around the prompts.
The trade-off in one sentence
Loop engineering gives you more autonomy and scale, but it also increases the need for verification, durable state, and cost discipline.
Sources
Frequently Asked Questions
Is loop engineering the same as agentic automation?
Not exactly. Agentic automation is broader. Loop engineering specifically emphasizes a recurring system that prompts, checks, stores state, and continues until a goal is met.
Do I still need prompt engineering if I use loop engineering?
Yes. The loop still depends on good instructions. The difference is that the instructions live inside a larger system that can run repeatedly without constant human re-prompting.
What is the most important part of a reliable loop?
Verification and state. Without a trustworthy check and durable memory, a loop can repeat mistakes or forget what it already did.
Should every AI workflow become a loop?
No. Use loops for recurring, modular, or long-running work. For short, high-context, or judgment-heavy tasks, direct prompting may be better.