Most people still use AI manually.
They input a prompt.
They wait for an answer.
They review the output themselves.
They notice where things went wrong.
They write another prompt.
Then they repeat the whole process again.
It feels like AI is doing this work.
But if you look closely, humans are still the engine.
Humans decide what to ask next.
Humans check the answers.
Humans remember where failures occurred.
Humans drive every new step.
That is the old way of working with AI.
The new way is different.
You are not just a prompt agent. You design loops around the agent.
A loop provides artificial intelligence with a goal, the correct context, a method of action, a way to verify results, and rules for what to do next. If the result fails, the loop returns it for reprocessing. If the result succeeds, the loop stops.
This transformation is called loop engineering.
A prompt gives AI an instruction.
Loop engineering gives AI a job.
A prompt produces an answer.
A loop continues to run until the result passes.
This is the whole idea.
There is no perfect prompt.
There is no lucky output.
There is no long conversation that you manually push the model forward.
A loop is a repeatable system, the process from trying to verifying results.
What exactly is a loop
A loop is a feedback loop of an AI agent.
The basic form is simple:
Discover.
Plan.
Execute.
Verify.
Iterate.
First, the system determines what needs to be done.
Then it plans the next step.
Then the agent takes action.
Then it checks the results.
If the results are good enough, the loop stops.
If not, the output goes back to the system, and the next iteration begins.
This is how artificial intelligence turns from a passive tool into a workflow.
Ordinary prompts would say:
"Help me write this."
A loop would say:
"Strive toward this goal. Check your results. Correct the failing parts. Keep moving forward until the results meet the standard, or stop when you reach the limit."
The last part is very important.
A real loop does not run forever. It needs a stopping condition.
Without a stopping condition, you have built a machine that can consume tokens all night and still achieve nothing.
A good loop always knows two things:
What success looks like.
When to give up.
This is why it differs from high-cost, chaotic AI loops to efficient AI loops.
Why loops are important now
In the past few years, the main skill was prompt engineering.
The better the prompt, the better the response.
This made sense when AI mainly handled one step at a time. You give the model a task, and it gives you a response.
But agents are different.
Agents can read files.
Use tools.
Run code.
Search sources.
Open pull requests.
Draft content.
Check results.
Call other agents.
Continue operations across multiple steps.
Once artificial intelligence can perform multiple steps, the highest leverage skill will no longer be just writing better prompts.
Leverage goes up a level.
The new question is not:
"How do I ask the model better questions?"
The new question is:
"How do I design a system that makes the model work, perform self-checks, improve, and stop correctly?"
That is loop engineering.
Prompt engineers improve single instructions.
Loop engineers design feedback systems around agents.
At first, the difference seemed small, but it changed everything.
The prompt engineer said:
"Write a function."
A loop engineer said:
"Read the problem, check the code, write the minimal fix, run tests, fix failures, stop when the test suite passes, and summarize the changes made."
Same model.
Same tools.
Different system.
The system is where the leverage lies.
Do you really need a loop?
This is where most people go wrong.
Loops sound powerful, so people try to loop everything.
That is a mistake.
Not every task is worth using a loop. In fact, most tasks do not need it.
A loop is only worth setting up if the task passes a simple test.
There are four questions.
First: Will this task repeat?
If the task only happens once, a good manual prompt is usually faster. Loops have a setup cost. They only make sense when a task occurs regularly: daily, weekly, every pull request, every new ticket, every new report, every new email.
Second: Can the result be automatically verified?
This is the most important condition.
For code, validation can be testing, code review, type checking, or building.
For research, it can be source checking, argument verification, or comparing sources of conflict.
For content, it can be a strict scoring criterion.
For operations, it can be a measurable condition: work order created, email sent, report generated, number above threshold, alert resolved.
If there is no way to automatically reject wrong results, humans are still the true validators. If humans still have to check each output from scratch, then this loop does not save much.
Third: Can agents perform end-to-end operations?
A loop requires the agent to actually complete the work.
If the agent needs to request your permission or missing context every two minutes, it is not actually running the loop. It is still manual work assisted by AI.
Fourth: Is "completion" objective?
"Tests passed" is objective.
"Build is green" is objective.
"Summary includes all required fields" is objective.
"The article feels good" is not objective.
"The design is beautiful" is not objective.
"The strategy is correct" is not objective.
Loops work best when success can be clearly measured.
If one of the steps is missed, please keep the task manual.
Do not build loops just because they sound advanced.
Only build loops when the work is repetitive, verifiable, actionable, and bounded.
A building block of a good loop
A loop is not just an agent repeating itself.
A loop is a system around the agent.
The agent is only a part of it.
An effective loop usually requires six building blocks.
The first building block is automation.
Automation is key. It can start the cycle without you having to trigger it manually.
That trigger can be a schedule, an event, or a condition.
Every morning. Every Friday. When a pull request is opened. When continuous integration fails. When new mail is received. When a new Linear issue appears. When a file changes. When a report is due.
Without automation, the cycle only runs when you start it. This is still useful, but it’s not the full version.
The second block is context.
The agent needs to know what is important.
For coding loops, the context may include architectural documentation, repository rules, test commands, coding standards, and files it must never touch.
For writing loops, the context may include audience, tone, examples, structure, and quality standards.
For a research loop, the context may include the problem, source requirements, confidence thresholds, and how to handle conflicting information.
Without reusable context, each loop starts from scratch.
With reusable context, loops become smarter over time.
The third module is action.
Loops should not only suggest what to do. They should also be able to complete the work.
That could mean editing code, running tests, opening pull requests, creating tickets, updating documentation, sending summaries, or drafting messages.
This is the difference between an assistant and an agent.
The assistant would say:
"This is what I will do."
The agent loop would say:
"I did it, checked it, here are the results."
The fourth module is validation.
This is the core of the loop.
Without validation, repetition is not progress. It’s just the agent continually agreeing with itself.
Verifiers can be test suites, type checkers, code inspection tools, build tools, scoring criteria, fact-checking processes, or an independent review agent.
It is important that bad work can fail.
A loop needs a gate.
Without a gate, there is no real loop.
The fifth module is state.
Models forget. Files don’t.
A long-running loop needs to remember what happened before.
What did it try?
What failed?
What succeeded?
What is still unfinished?
What should be avoided next time?
What needs manual review?
That memory can exist in markdown files, project logs, GitHub issues, Linear tickets, databases, or shared documents.
The specific format is less important than the principles.
State must exist outside of the model.
If the loop does not write the state somewhere, each run starts from zero.
The sixth block is a stopping condition.
Every serious loop needs a stopping rule.
There are two types of stopping conditions.
Successful stop:
"All tests passed."
"Report completed."
"Draft scored" 8 / 10 or higher on each standard."
"Work order has been created and linked."
"Source check passed."
Failure stop:
"Stop after 5 iterations."
"After 30 minutes."
"Stop after this token budget is used."
"Stop if permissions are missing."
"Stop if the same error occurs twice."
A good loop knows when to continue.
An excellent loop also knows when to stop and seek help.
Single-agent loop vs fleet loop
There are two basic scales of loops.
Single-agent loops and fleet loops.
A single-agent loop uses one agent to run the entire cycle.
It discovers what needs to be done, plans the work, executes it, verifies, and improves.
This is best suited for smaller, focused tasks.
Examples:
Rewrite a draft until it meets the scoring criteria.
Fix a failed test.
Summarize a research topic.
Clean up a small code file.
Sort out a simple problem.
Generate a weekly report.
One agent.
One loop.
One focused task.
A fleet cycle is larger.
A coordinator is responsible for the main tasks. It breaks the work into parts and sends these parts to specialized agents.
For example:
A research agent is responsible for finding sources.
An engineering agent is responsible for writing code.
A quality assurance agent is responsible for testing outputs.
A review agent is responsible for checking edge cases.
A summarization agent is responsible for writing the final report.
This is more like a small AI team rather than a single AI worker.
Fleet cycles are powerful, but they are also more expensive and harder to control.
Each additional agent consumes tokens.
Each additional role increases coordination costs.
Each additional branch produces more results that need to be verified.
So the rules are simple:
Start with a single-agent loop.
Only switch to a fleet loop when the task is large enough to require experts.
Do not build a crowd when a good loop can get the work done.
Creators and checkers should not be the same agent.
One of the most important loop patterns is the separation of maker and checker.
The agent who creates the work should not be the only one to verify it.
Why?
Because models are often too lenient when evaluating their own work.
The model writes code and convinces itself that the modifications are correct.
The model misses weak arguments when composing articles.
The model overlooks source conflicts when summarizing research content.
The model drafts plans and assumes that vague parts are clear.
This is not because the model is useless.
But because its self-review capability is weak.
Humans have the same problem.
The person writing something is often not the best person to review it.
A stronger loop differentiates roles.
Creator:
Generates output.
Checker:
Reviews output according to objectives.
The checker can be an independent model, a stricter prompt, a different tool, a test suite, or a human review step.
For code, the checker might be automated tests.
For writing, the checker might score clarity, structure, specificity, and originality.
For research, the checker might verify each statement against sources.
For operations, the checker may verify that the task actually occurs in an external tool.
This separation improves quality because the loop no longer solely relies on the model grading its own work.
But there is a trade-off.
The make-check loop is more costly.
Two agents mean more tokens.
More verification means more time.
More context means larger runs.
So use it where quality matters.
Don’t spend reviewer agent tokens on tasks that only require simple gating.
Open loop vs closed loop
Another important difference: open loop versus closed loop.
An open loop gives the agent a broad goal and allows it to explore.
Example:
"Find ways to improve this product and implement the best idea."
It sounds exciting.
But unfinished loops are chaotic.
They may explore too many paths.
They may deviate from the goal.
They may quickly consume tokens.
They may produce a large amount of output that still requires human review.
They may confuse activity with progress.
Open loops are useful for exploration, but they are not the best starting point.
A closed loop is bounded.
The path is clear.
Checks are explicit.
Stopping conditions are explicit.
The scope is finite.
Example:
"Every Monday, check for dependency updates. For each security update, submit a PR. Run tests. If the tests pass, keep the PR for review. If the tests fail, record the failure and stop."
This is a closed loop.
It is less glamorous, but much more practical.
Closed-loop systems are cheaper.
Closed-loop systems are easier to debug.
Closed-loop systems are safer.
The results from closed-loop systems are cleaner.
Start with a closed-loop system.
Once your verification is strong enough, your permissions are controlled, your state is reliable, and the cost of your tokens is understood, then you can use loops more openly.
Reliability first.
Autonomy second.
Minimal viable coding loop
Code is the first place that makes loops obvious.
The reason is simple: code can be inspected.
Tests pass or fail.
Build succeeds or fails.
Type checks pass or fail.
Code style checker returns clean or unclean.
This gives the agent a real signal.
A basic coding loop looks like this:
Read the context.
Plan the smallest useful change.
Edit the code.
Run tests.
Read the failure cases.
Fix the root cause.
Run the tests again.
Stop when the tests pass.
Summarize the changes made.
This is not magic.
It is just a feedback loop.
But it is powerful because humans no longer need to manually push every step.
Old workflow:
You let the agent fix something.
It gives you code.
You run tests.
You paste the error back.
It tries again.
You run tests again.
You paste another error.
It tries again.
New workflow:
Loop: read errors, fix code, run tests, and repeat until the gate passes or the loop limit is reached.
Humans still review the final results.
However, humans are no longer the ones manually moving each failure from one step to the next.
That is leverage.
Real examples of useful loops
The best initial loops are boring.
And that is a good thing.
Boring loops are easier to verify.
CI classification loop:
Every morning, scan failed CI jobs. Categorize each failure as an environmental issue, flaky test, real bug, dependency issue, or infrastructure problem. Draft a fix plan for simple and deterministic failures. Escalate the remaining issues.
Dependency update cycle:
Check for security package updates weekly. Apply one update at a time. Run tests. If everything goes well, open a pull request. If issues occur, document the failures.
A lint and fix cycle:
When a pull request is opened, run formatters and code check tools. Apply safe style fixes. Run checks again. Stop when cleanup is complete.
A research cycle:
Start with a research question. Search for sources. Extract arguments. Verify arguments based on sources. Compare conflicting information. Only write a summary after checking key arguments.
A content cycle:
Start with a topic, audience, and goal. Draft an article. Critique according to scoring criteria. Rewrite the weakest parts. Score again. Stop when the article meets the standards or reaches the iteration limit.
Inbox cycle:
Every morning, read new important emails and calendar events. Identify urgent messages, meetings that require preparation, and overdue follow-ups. Send a brief summary.
A sales outreach cycle:
Find potential customers that match the ideal customer profile. Enrich the information for each company. Conduct qualification screening based on clear criteria. Draft personalized messages. Conduct quality checks. Only send information when it has passed review or is handed over to a human.
The framework is always the same:
Target.
Background.
Action.
Verification.
Status.
Next steps.
Stop conditions.
Once you see that pattern, designing loops becomes much easier.
The cost that no one wants to talk about
Loops are not free.
Every iteration consumes tokens.
Every retry consumes tokens.
Every validation consumes tokens.
Every sub-agent consumes tokens.
Every context refresh consumes tokens.
And the cost increases compoundly.
Running a loop ten times is not just ten ordinary prompts.
Each iteration may include the original task, current state, previous failures, tool results, code snippets, logs, and the next instruction.
The context is growing.
The bill grows accordingly.
This is why token budgeting is important.
A medium-sized coding loop can consume a large number of tokens.
A loop with multiple agents can consume more.
A periodic loop that runs daily can quietly become a continuous cost center.
The important metric is not:
"How many times did we run the loop?"
The important metric is:
"What is the cost per accepted result?"
The cost per accepted result is the real number.
If your loop produces ten outputs and you reject seven of them, the loop has not saved you work. This is creating review debt.
If your loop opens five pull requests and you only merge one, this loop may be more expensive than manual work.
If the daily report generated by your loop is not read by anyone, it is just automated noise.
A good loop should reduce the burden on humans.
A bad loop creates more things that need to be cleaned up manually.
Silent failure mode
Bad loops often don’t loudly report errors.
They fail quietly.
The agent claims to have completed, but in reality, it has not completed.
The validator is too lenient.
The loop repeats the same mistakes.
The state file has not been updated.
The output looks reasonable, but it is incomplete.
The system generates little value while consuming a large number of tokens.
This is one of the most dangerous things in agent loops.
An ordinary script would crash.
A bad loop may continue confidently.
This is why hard gating is important.
Test suites are better than ‘just comment’.
Type checkers are better than ‘looks good’.
Strict grading criteria are better than ‘improve it’.
Human approval steps are better than silent deployment.
Loops need friction in the right places.
The focus is not on completely removing humans.
The focus is on removing humans from repetitive operations while keeping them in control of judgment, review, and irreversible actions.
Potential Risk: Understanding debt
Besides tokens, there is another cost.
Understanding liabilities.
The faster a loop generates work, the more easily your understanding falls behind.
This is especially true in code.
If an agent loop opens pull requests every day, and the team merges them without carefully reading them, the update speed of the codebase will exceed human understanding.
At first, this feels productive.
Later, it becomes a problem.
An error occurs.
No one knows why the code was written that way.
The agent modified five files, and no one has fully read them.
Tests passed, but the architecture worsened.
The system can run, but the team doesn’t understand it.
That is knowledge debt.
The loop saves time in the early stages, but will generate debugging costs in the future.
The solution is not to avoid using loops.
The solution is to set limits for them in the design.
Read the differences.
Keep loops for small tasks.
Use objective gating.
Block sensitive areas.
Regularly review permissions.
Do not let agents make architectural decisions alone.
Do not automate judgment decisions just because you can.
Loop engineering does not mean giving up your thinking.
It means deciding where thinking is most needed.
Which should not be looped
Some tasks are bad first loops.
Architecture rewrite.
Authentication logic.
Payments.
Production deployment.
Legal advice.
Medical advice.
Company strategy.
Hiring decisions.
Brand taste.
Any "completed" task that mainly relies on judgment.
Artificial intelligence can still help handle these tasks.
But humans should stay close.
Loops are strongest when work is narrow, repetitive, and checkable.
Loops are weakest when work is ambiguous, high-risk, and subjective.
That is the boundary.
Do not use loops to avoid thinking.
Use loops to avoid manually repeating steps that can be safely checked.
How to build your first loop
Don’t start with a huge system.
Start with a small loop.
A repeated task.
A source of context.
An action.
A validator.
A state file.
A stopping condition.
Order is important.
Run the task manually first.
Make sure you understand these steps.
Then turn these instructions into a reusable skill or saved prompt.
Then add a validation mechanism.
Then add state.
Then add automation.
Do not schedule any tasks until a manual run works reliably.
This is how loops crash while you sleep.
A minimally viable loop is inherently boring by design.
For example:
Task:
Fix a failing test.
Context:
Read the problem, related files, and test outputs.
Action:
Make minimal code changes.
Validator:
Run the test.
Status:
Record failed content, changes made, and content that still needs review.
Stop conditions:
Stop when the test passes, or after five attempts.
That’s enough.
You don’t need ten agents.
You don’t need a complex coordinator.
You need a tight loop that can produce an accepted result.
Then you can scale up.
A simple self-check loop that you can use manually
You can feel the looping patterns in any large language model through a single prompt.
This is not fully automated, because you still need to start it manually.
But it can teach you structure.
Use something like this:
That is the simplest version of a loop.
It doesn’t need tools.
It doesn’t need scheduling.
It doesn’t need multiple agents.
It just changes the pattern from:
"Answer only once."
To:
"Work, check, improve, then stop."
This shift in thinking is a key part.
The real work of a loop engineer
A loop engineer is not someone who makes artificial intelligence run forever.
That is not the goal.
The goal is controllable autonomy.
The loop engineer decides:
What starts the loop.
What context the agent gets.
What tools it can use.
What actions are allowed.
What counts as success.
What will cause the work to fail.
What state must be saved.
When the loop should stop.
When human review is required.
What the loop must never touch.
This is why loop engineering is more than just prompting.
It is closer to workflow design.
You are not just writing instructions.
You are designing an environment in which agents can safely produce useful work.
This means that the best loop engineers are not those who blindly automate everything.
They are the ones who know what should not be automated.
A shift in mindset
Old mindset:
"I need a better prompt."
New mindset:
"I need a better loop."
Better prompts can improve a single output.
Better loops can improve the process of creating outputs.
This is why this skill is important.
The future is not just about people typing clever prompts into a chat box.
The future is about people designing systems that repeatedly turn messy trials into validated results.
The loop is the product.
Prompts are only part of it.
The final idea
Loop engineering is the shift from manual prompting to automated feedback loops.
This does not mean that humans will disappear.
This means humans no longer manually drive every small step.
Humans define goals.
Humans set boundaries.
Humans design validators.
Humans review high-risk work.
Loops handle repetition.
Bad loops consume tokens and create noise.
Good loops save attention.
A good loop knows what to do, how to self-check, when to retry, when to stop, and when to call a human.
That is true unlocking.
Stop trying to write a perfect prompt.
Build loops that make imperfect outputs better.
A reliable loop is better than a perfect prompt.
Keep the first loop small: one input, one checkable output, and one explicit limit. Expand the scope only after that loop is stable.
Turn the loop into a handoverable local process
A reliable loop should at least answer: what to read this round, what changes are allowed, what to use for checking, how to fix if it fails, how many retries at most, and when to hand over to a human. Predetermined workflow paths and dynamically selecting processes and tools with agents are not the same, so you don’t have to wrap all automation into an ‘intelligent agent.’
Claude Code’s Stop hook can call check logic before completion, such as running tests; the HTTP hook can send event data to a specified endpoint. These mechanisms can handle verification and notifications, but they cannot define for you what counts as completion. Codex’s harness is also responsible for coordinating the agent loop between the user, model, and tools.
Independent subtasks can run in parallel, while steps with dependencies still need to be ordered and share state.High-risk tasks without reliable automated acceptance are not suitable for fully unattended operation.
When running locally for testing, please restrict permissions to the dedicated working directory, set a fixed budget and a maximum number of rounds, and save the input, modifications, command outputs, and inspection results for each round. The loop should stop as long as the inspector cannot provide a clear pass, rather than using the model’s own "completed" as evidence.