Loop engineering is the practice of designing an autonomous system that repeatedly finds work, assigns it to agents, checks the result, stores state, and decides what happens next. In the reference material, it is framed as “replacing yourself as the person who prompts the agent” and instead building the loop that prompts the agent.
If you are looking for the practical answer: loop engineering in Codex means combining recurring automations, isolated worktrees, project skills, connectors, and sub-agents so an agent system can operate with less direct hand-holding. The goal is not to eliminate human review. It is to move from one-off prompting to a repeatable workflow that can discover, act, verify, and remember.
What loop engineering means
Traditional agent use is interactive: you prompt, inspect the response, then prompt again. Loop engineering shifts that burden into a system that can:
- discover work on a schedule
- triage what matters
- isolate parallel changes
- apply project-specific knowledge
- use external tools
- verify results with a separate checker
- persist state outside the conversation
That last point matters. Long-running agent workflows fail if memory only lives in the current chat. The repo, a markdown file, or a project board has to hold what was done, what passed, and what remains.
This is why loop engineering is different from prompt engineering. Prompt engineering tunes a single turn. Loop engineering designs the repeated process around many turns.
The core pieces of a reliable loop
The reference material identifies five recurring primitives plus one persistent state layer:
| Primitive | Job in the loop | Why it matters |
|---|---|---|
| Automations | Run discovery and triage on a schedule | Creates the “loop” instead of one manual run |
| Worktrees | Isolate parallel work | Prevents agents from stepping on each other |
| Skills | Capture project knowledge | Reduces repeated explanation and guesswork |
| Plugins/connectors | Reach real tools | Lets the loop act, not just advise |
| Sub-agents | Separate maker from checker | Improves verification and reduces self-confirmation |
| State | Remember what is done and next | Keeps the system from forgetting between runs |
The products discussed in the source material, Codex and Claude Code, expose these ideas with different names and surfaces, but the architectural pattern is the same.
1) Automations: the heartbeat of the loop
Automations turn a one-time agent task into a recurring process. In the Codex app, the reference describes an Automations tab where you choose:
- the project
- the prompt
- the cadence
- the environment
Runs that produce findings go to a triage inbox. Runs that find nothing archive themselves.
In Claude Code, the reference describes scheduled tasks, cron-based workflows, hooks, and GitHub Actions as ways to keep the loop running.
When automations are useful
Use automations for work that is:
- repetitive
- easy to triage
- safe to review asynchronously
- tied to a clear schedule or trigger
Examples from the source material include:
- daily issue triage
- CI failure summaries
- commit briefings
- bug hunting on recent changes
When not to automate
Do not automate work that lacks a clear stopping condition or that requires nuanced human judgment at every step. If the loop cannot decide what counts as “done,” it will drift, waste tokens, or create noise.
Good automation rule
A good automation should produce one of two outcomes:
- a concrete finding that requires action
- a clean archive entry that says nothing needed doing
That keeps the loop from becoming a background source of ambiguity.
2) Worktrees: stop agents from colliding
The source material is blunt about the failure mode: once more than one agent runs, file collisions become the problem.
A git worktree solves that by giving each agent a separate working directory on its own branch while sharing repository history. That means two agents can work in parallel without editing the same checkout.
Use worktrees when
- two or more agents may modify code at the same time
- you want isolated feature exploration
- you expect one agent to draft and another to review
Avoid worktrees when
- the task is too small to justify the overhead
- the change must happen in one shared working copy for a specific reason
- your team has not agreed on branch hygiene
Practical guidance
If you are building a loop that spawns parallel tasks, treat isolation as a default, not an optimization. Parallel agents without isolation are a common source of silent damage.
3) Skills: write the project rules down once
A skill is a reusable instruction package that captures project knowledge the agent would otherwise have to infer. In the reference material, skills use a SKILL.md file plus optional scripts, references, and assets.
Skills help encode things like:
- build steps
- conventions
- project-specific constraints
- “we do not do it this way because…” rules
That matters because agent sessions start cold. Without documented project knowledge, the loop re-derives your intent every time.
Why skills improve loops
Skills reduce “intent debt,” meaning the gap between what the agent assumes and what the project actually wants. The more often a loop runs, the more expensive that gap becomes if the instructions are not written down.
Best practice
Write skills in plain, boring language. A tight skill description is better than a clever one. The loop should be able to reuse it without interpretation.
Skills vs. plugins
The reference material makes an important distinction:
- a skill is the authoring format
- a plugin is how you distribute or package it
That distinction helps when you want to share the same project knowledge across repositories.
4) Plugins and connectors: make the loop useful in the real world
A loop that can only write suggestions is limited. Connectors and plugins are what let it act inside your working environment.
According to the source material, this is how a loop can:
- open a pull request
- link a Linear ticket
- update a board or inbox
- notify a channel after CI passes
That is the difference between an agent saying “here is what to do” and a loop actually doing the administrative work around the change.
Use connectors when
- your process lives across multiple systems
- you need the loop to update state outside the repo
- handoff friction is slowing work down
Be careful with connectors when
- the loop can take destructive actions
- permissions are too broad
- external systems become a source of unrecoverable errors
A connector should make the workflow smoother, not remove the need for review.
5) Sub-agents: separate the maker from the checker
One of the strongest patterns in loop engineering is splitting generation from verification. The source material argues that the model that wrote the code is too inclined to approve its own work.
Sub-agents help by assigning different roles to different agents, such as:
- explorer
- implementer
- reviewer
- verifier
In Codex, the reference material describes subagents defined as TOML files in .codex/agents/. In Claude Code, it describes task subagents in .claude/agents/ and agent teams that pass work between them.
Why this matters
Verification is what makes unattended work credible. If the same agent writes and judges its own output, the loop can become self-confirming rather than reliable.
Recommended split
A practical loop often uses:
- one sub-agent to find or draft work
- one sub-agent to check against the spec and tests
- a human to review the final risk, especially for important changes
Trade-off
Sub-agents cost more tokens because each one does its own model and tool work. Use them where the cost of a false positive is higher than the extra compute.
6) State: store progress outside the conversation
The source material treats state as the spine of the loop. The memory has to live on disk or in a persistent external system, not only in context.
Examples include:
- markdown progress files
- AGENTS.md
- Linear boards
- other durable project state
What state should record
At minimum, keep track of:
- what was tried
- what passed
- what failed
- what is still open
- what should happen next
Why state matters
Without state, every run starts from scratch. With state, the loop can resume rather than repeat itself.
A practical loop pattern
Here is a simple shape based on the reference material:
- A scheduled automation runs each morning.
- A skill reads recent CI failures, open issues, and recent commits.
- Findings are written to a persistent state file or project board.
- The loop opens an isolated worktree for each item worth addressing.
- One sub-agent drafts a fix.
- Another sub-agent reviews the draft against project rules and tests.
- A connector opens the PR and updates the ticket.
- Anything unresolved goes to a triage inbox for human review.
That is a loop: not one prompt, but a repeatable process with discovery, action, verification, and memory.
Decision table: should you use loop engineering here?
| Situation | Good fit? | Why |
|---|---|---|
| Daily triage of CI failures | Yes | Repetitive, bounded, and easy to review |
| Parallel feature exploration | Yes | Worktrees and sub-agents reduce collisions |
| One-off bug fix with unclear scope | Maybe | A simple direct prompt may be faster |
| High-risk production change | Cautiously | Use strong verification and human approval |
| Work requiring deep judgment every turn | No | Automation can amplify uncertainty |
| Tasks with no clear done condition | No | The loop needs a stopping rule |
Failure modes to watch for
Loop engineering gives you leverage, but it also sharpens some risks.
1. Verification drift
A loop that runs unattended can make unattended mistakes. The fix is not more confidence. It is better verification: a different checker, clear tests, and human review where needed.
2. Comprehension debt
The faster a loop ships code you did not personally read, the bigger the gap between the system and your understanding. If you do not inspect the output, your comprehension degrades.
3. Cognitive surrender
It is easy to stop forming an opinion and accept whatever the loop returns. That is dangerous. The loop should assist judgment, not replace it.
4. Token cost growth
The reference material specifically warns to be careful about token costs. Loops can consume much more than expected, especially when they spawn multiple sub-agents or run frequently.
When loop engineering is the right choice
Use loop engineering when you want to:
- offload repetitive discovery and triage
- scale agent work safely across parallel tasks
- encode project knowledge into reusable instructions
- keep a durable record of progress
- verify work with a separate checker
It is especially useful when the work is recurring and the process can be standardized.
When direct prompting is still better
Direct prompting is still effective when:
- the task is small
- the desired output is immediate
- the scope is unclear
- you need exploratory back-and-forth
- the overhead of a loop would exceed the value of automation
The reference material is explicit that this is not an all-or-nothing choice. Good practice is finding the right balance.
Bottom line
Loop engineering is not just “agent automation.” It is a workflow design discipline for autonomous AI systems that need to run repeatedly and safely.
In Codex and similar tools, the pattern is consistent:
- automations surface the work
- worktrees isolate it
- skills define the rules
- connectors let the system act
- sub-agents verify it
- external state preserves memory
That combination is what makes an agent loop reliable enough to trust for recurring work.
Sources
Frequently Asked Questions
What is loop engineering in AI agents?
Loop engineering is the practice of designing a repeatable system that finds work, assigns it to agents, checks results, and remembers progress outside the chat.
How is loop engineering different from prompt engineering?
Prompt engineering improves a single interaction. Loop engineering designs the repeated workflow around many interactions, including scheduling, verification, and state.
Why are worktrees important in agent loops?
Worktrees let multiple agents work in parallel without colliding in the same checkout. They reduce file conflicts and keep edits isolated.
Do sub-agents replace human review?
No. Sub-agents improve verification by separating the maker from the checker, but important changes still need human judgment and review.