Loop engineering is the practice of designing a system that can repeatedly find work, execute it, verify it, record state, and decide what happens next with minimal human prompting. In simple terms, you stop manually steering an AI agent turn by turn and instead build the loop that steers the agent for you.
That does not mean humans disappear from the workflow. It means the human role shifts from “prompt every step” to “design the system, set the guardrails, and review the output.” The core idea is already visible in tools and workflows that support scheduled runs, isolated worktrees, project-specific skills, connectors to external systems, and sub-agents for checking work.
What loop engineering means
“Loop engineering” is an emerging term, and attribution is still fluid. In the supplied material, Addy Osmani describes it as replacing yourself as the person who prompts the agent and designing the system that does it instead. Other builders have made similar comments about moving from prompting agents to designing loops around them. The common thread is the same: the leverage point moves from single prompts to recurring autonomous systems.
A useful way to think about it is this:
- Prompting is one-off control.
- Loop engineering is system design for repeated, self-directed agent work.
The loop does not just answer a question. It:
- discovers work,
- assigns or starts the work,
- checks results,
- stores progress,
- chooses the next action.
That makes it especially relevant for long-running coding and operations tasks where the same kind of work happens again and again.
The five core building blocks
The reference material points to five practical pieces that make loop engineering work.
1) Automation
Automation is the heartbeat of the loop. It schedules the agent to run without a human starting each turn.
Examples include:
- daily issue triage,
- checking CI failures,
- summarizing recent changes,
- hunting regressions,
- opening tasks that need attention.
Without automation, you have a useful agent session. With automation, you have a loop.
2) Worktrees
Worktrees isolate concurrent work so one agent does not overwrite another agent’s changes. This matters when multiple tasks run in parallel.
Why it helps:
- separate task contexts,
- less file collision risk,
- cleaner parallel execution,
- safer autonomous changes.
If two agents share the same checkout, they can easily step on each other. A worktree reduces that risk by giving each run its own workspace.
3) Skills
Skills are written project knowledge the agent can load when needed. The material describes them as markdown-based instructions that capture project-specific know-how, conventions, and procedures.
Skills help because they:
- reduce repeated explanation,
- preserve team conventions,
- encode “how we do things here,”
- make recurring tasks more consistent.
In loop engineering, skills are valuable because recurring work should not have to relearn the project every time.
4) Plugins and connectors
Plugins and connectors give the agent access to external systems such as project tools, issue trackers, databases, or communication platforms.
This is what turns a loop from “here is a suggestion” into “here is a system that can act.”
Examples of what connectors can enable:
- updating tickets,
- opening pull requests,
- reading project state from external tools,
- sending results to a shared workspace.
The important distinction is that skills teach the agent, while connectors let the agent act in the real environment.
5) Sub-agents
Sub-agents are smaller agents used to split work into parts or independently verify another agent’s output.
In a loop, sub-agents are useful for:
- review,
- verification,
- parallel exploration,
- task decomposition.
The maker-checker split is especially important. If the same model that wrote the code also grades it, mistakes are easier to miss. A second agent helps reduce that risk.
The missing piece: state and memory
The core five pieces usually need a sixth supporting layer: durable state.
Long-running agent systems cannot rely on conversation context alone. The model forgets between runs, so the loop needs memory stored outside the chat, such as:
- markdown files,
- a progress log,
- a board or issue system,
- repository state files.
This is not a glamorous part of the design, but it is essential. If the loop cannot remember what it already tried, it will repeat work or lose track of unfinished tasks.
How a loop works in practice
A simple loop for a codebase might look like this:
- A scheduled automation runs every morning.
- It reads CI failures, open issues, and recent commits.
- It writes the findings into a shared state file.
- For each item worth acting on, it opens an isolated worktree.
- A sub-agent drafts the fix.
- Another sub-agent checks the draft against tests and project rules.
- If the work passes, the loop updates the ticket or creates a pull request.
- If the work fails or is unclear, the loop sends it to a triage queue for human review.
That workflow is the point of loop engineering: design the process once, then let the system repeat it.
A decision table: when loop engineering helps
| Situation | Loop engineering fit? | Why |
|---|---|---|
| Repeated triage work | Yes | The task is recurring and structured |
| Daily CI failure review | Yes | The loop can surface and categorize work |
| Parallel feature work | Yes | Worktrees reduce collisions |
| Project-specific coding conventions | Yes | Skills preserve context |
| High-risk production changes | Use carefully | Strong verification is required |
| Ambiguous product decisions | Usually no | Humans still need to make the call |
| One-time exploratory work | Maybe | A simple prompt may be enough |
What loop engineering is not
Loop engineering is not a promise that agents can run forever without oversight.
It is also not a replacement for judgment. The system can automate repetition, but it does not understand your goals, risk tolerance, or product priorities unless those are explicitly encoded and reviewed.
Most importantly, it is not a license to stop verifying work. A loop can create errors just as efficiently as it can create value. The better the loop, the faster mistakes can compound if no one checks the output.
Common failure modes
1) Unattended errors compound
If the loop is allowed to run without verification, it may keep amplifying the same mistake.
Mitigation:
- use a verifier sub-agent,
- add tests and stop conditions,
- review outputs before merging,
- keep rollback paths simple.
2) Token or compute usage grows too fast
The supplied source material warns that recurring loops can consume far more tokens than a one-off prompt.
Mitigation:
- keep task scope tight,
- use concise skills,
- avoid unnecessary retries,
- prefer automation only where the recurrence is justified.
3) The loop becomes a black box
If humans stop reading the output, understanding can decay over time.
Mitigation:
- keep state files readable,
- require summaries,
- review sampled runs,
- document why the loop exists.
4) The agent checks its own work too much
A single agent doing both creation and validation can miss its own mistakes.
Mitigation:
- separate maker and checker roles,
- use different instructions for review,
- use a fresh verifier where possible.
5) Parallel runs collide
Two tasks touching the same files can interfere with each other.
Mitigation:
- isolate with worktrees,
- limit shared-write paths,
- define clear ownership for state.
When not to use a loop
Do not build a loop just because you can.
A loop may be the wrong tool when:
- the task changes every time,
- the risk is high and the acceptance criteria are fuzzy,
- the work depends on human judgment at every step,
- the ongoing maintenance cost outweighs the value.
If the task is simple and one-off, direct prompting may be faster and safer. Loop engineering is best when the work is recurring, structured, and worth automating carefully.
A practical checklist before you build one
Before you create a loop, ask:
- Is this work recurring?
- Can I define a clear stop condition?
- What state needs to persist between runs?
- How will the loop avoid file collisions?
- What skill documents the project rules?
- What system verifies the work?
- What happens when the loop cannot decide?
- How will I review or audit the output?
If you cannot answer these clearly, the loop is probably too early.
The real shift: from prompting to designing systems
The biggest change in loop engineering is not technical novelty. It is a change in responsibility.
With ordinary prompting, the human keeps the agent moving one turn at a time. With loop engineering, the human designs the environment in which the agent works. That includes task discovery, execution, verification, memory, and escalation.
This is why loop engineering is more demanding than prompt engineering. You are not just writing instructions. You are creating a system that can act repeatedly, and that system must remain understandable, safe, and useful over time.
Used well, loop engineering reduces repetitive work and increases leverage. Used carelessly, it can accelerate confusion and errors. The difference is not the loop itself. The difference is whether the loop has real guardrails.
Sources
Frequently Asked Questions
Is loop engineering the same as agent automation?
Not exactly. Automation is one part of loop engineering. Loop engineering adds the broader system design: discovery, work isolation, verification, and persistent state.
Do I always need sub-agents?
No. Sub-agents are useful when you need parallel work or independent verification. For small, low-risk tasks, a single agent may be enough.
What is the most important part of a loop?
Verification. A loop that cannot check its own output safely is just unattended work, which can be risky.
Should I use loop engineering for every coding task?
No. Use it for recurring, structured, and reviewable work. For one-off or highly ambiguous tasks, direct human prompting is often better.