Most people still use AI manually.
They type one prompt. They wait for one answer. They review the output themselves. They notice what is wrong. They write another prompt. Then they repeat the whole process again.
It feels like the AI is doing the work.
But if you look closely, the human is still the engine.
The human decides what to ask next. The human checks the answer. The human remembers what failed. The human drives every new step.
That is the old way of working with AI.
The new way is different.
You do not just prompt the agent. You design the loop around the agent.
A loop gives the AI a goal, the right context, a way to act, a way to verify the result, and a rule for what to do next. If the result fails, the loop sends it back for another pass. If the result passes, the loop stops.
That shift is called loop engineering.
Prompting gives the AI an instruction. Loop engineering gives the AI a job.
A prompt produces one answer.
A loop keeps working until the result passes.
That is the entire idea.
Not one perfect prompt. Not one lucky output. Not one long conversation where you manually push the model forward.
A loop is a repeatable system that moves from attempt to verified result.
What a loop actually is
A loop is a feedback cycle for AI agents.
The basic shape is simple:
Discover. Plan. Execute. Verify. Iterate.
First, the system figures out what needs to be done. Then it plans the next step. Then the agent takes action. Then the result is checked. If the result is good enough, the loop stops. If not, the output goes back into the system and the next iteration begins.
This is how AI stops being a passive tool and starts becoming a workflow.
A normal prompt says:
“Write this for me.”
A loop says:
“Work toward this goal. Check your result. Fix what failed. Keep going until the result meets the bar, or stop when you hit the limit.”
That last part matters.
A real loop does not run forever. It needs a stop condition.
Without a stop condition, you have built a machine that can burn tokens all night and still produce nothing useful.
A good loop always knows two things:
What success looks like. When to give up.
That is what separates a productive AI loop from an expensive mess.
Why loops matter now
For the last few years, the main skill was prompt engineering.
Better prompt, better answer.
That made sense when AI mostly worked one step at a time. You gave the model a task, and the model gave you a response.
But agents are different.
Agents can read files. Use tools. Run code. Search sources. Open pull requests. Write drafts. Check results. Call other agents. Continue across multiple steps.
Once AI can do more than one step, the highest-leverage skill is no longer just writing better prompts.
The leverage moves one level up.
The new question is not:
“How do I ask the model better?”
The new question is:
“How do I design a system that makes the model work, check itself, improve, and stop correctly?”
That is loop engineering.
A prompt engineer improves a single instruction.
A loop engineer designs the feedback system around the agent.
The difference looks small at first, but it changes everything.
A prompt engineer says:
“Write a function.”
A loop engineer says:
“Read the issue, inspect the code, write the smallest fix, run the tests, fix failures, stop when the suite is green, and summarize what changed.”
Same model. Same tools. Different system.
And the system is where the leverage is.
Do you actually need a loop?
This is where most people get it wrong.
Loops sound powerful, so people try to loop everything.
That is a mistake.
Not every task deserves a loop. In fact, most tasks do not.
A loop is worth building only when the task passes a simple test.
There are four questions.
First: does the task repeat?
If the task happens once, a good manual prompt is usually faster. A loop has setup cost. It only makes sense when the task comes back regularly: every day, every week, every pull request, every new ticket, every new report, every new email.
Second: can the result be verified automatically?
This is the most important condition.
For code, verification can be tests, lint, type checks, or builds.
For research, it can be source checks, claim validation, or conflicting-source comparison.
For content, it can be a strict rubric.
For operations, it can be a measurable condition: ticket created, email sent, report generated, number above a threshold, alert resolved.
If there is no way to reject a bad result automatically, the human is still the real verifier. And if the human still has to inspect every output from scratch, the loop is not saving much.
Third: can the agent act end-to-end?
A loop needs the agent to actually do the work.
If the agent needs to ask you for permission or missing context every two minutes, it is not really running a loop. It is still manual work with AI assistance.
Fourth: is “done” objective?
“Tests pass” is objective. “The build is green” is objective. “The 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 you miss one of these boxes, keep the task manual.
Do not build loops just because they sound advanced.
Build them when the work is repeated, verifiable, actionable, and bounded.
The building blocks of a good loop
A loop is not just an agent repeating itself.
A loop is the system around the agent.
The agent is only one part.
A working loop usually needs six building blocks.
The first block is automation.
Automation is the heartbeat. It starts the loop without you manually remembering to run it.
That trigger can be a schedule, an event, or a condition.
Every morning. Every Friday. When a pull request opens. When CI fails. When a new email arrives. When a new Linear ticket appears. When a file changes. When a report is due.
Without automation, the loop only runs when you start it. That is still useful, but it is not the full version.
The second block is context.
The agent needs to know what matters.
For a coding loop, context might include architecture docs, repo rules, test commands, coding conventions, and files it must never touch.
For a writing loop, context might include audience, tone, examples, structure, and quality criteria.
For a research loop, context might include the question, source requirements, confidence threshold, and how to handle conflicting information.
Without reusable context, every loop starts cold.
With reusable context, the loop becomes smarter over time.
The third block is action.
A loop should not only suggest what to do. It should be able to do the work.
That might mean editing code, running tests, opening a pull request, creating a ticket, updating a document, sending a summary, or drafting a message.
This is the difference between an assistant and an agent.
An assistant says:
“Here is what I would do.”
An agent loop says:
“I did it, checked it, and here is what happened.”
The fourth block is verification.
This is the heart of the loop.
Without verification, repetition is not progress. It is just the agent agreeing with itself again and again.
The verifier can be a test suite, a type checker, a linter, a build, a rubric, a fact-checking pass, or a separate reviewer agent.
The important thing is that bad work can fail.
A loop needs a gate.
No gate, no real loop.
The fifth block is state.
The model forgets. The file does not.
A long-running loop needs to remember what happened before.
What did it try? What failed? What passed? What is still open? What should it avoid next time? What needs human review?
That memory can live in a markdown file, a project log, a GitHub issue, a Linear ticket, a database, or a shared document.
The exact format matters less than the principle.
State must live outside the model.
If the loop does not write state somewhere, every run starts from zero.
The sixth block is a stop condition.
Every serious loop needs a rule for when to stop.
There are two types of stop conditions.
Success stop:
“All tests pass.” “The report is complete.” “The draft scores 8/10 or higher on every criterion.” “The ticket is created and linked.” “The source check passed.”
Failure stop:
“Stop after 5 iterations.” “Stop after 30 minutes.” “Stop after this token budget.” “Stop if permissions are missing.” “Stop if the same error happens twice.”
A good loop knows when to continue.
A great loop also knows when to stop and ask for help.
Single-agent loop vs fleet loop
There are two basic sizes of loops.
A single-agent loop and a fleet loop.
A single-agent loop uses one agent to run the whole cycle.
It discovers what needs to be done, plans the work, executes, verifies, and improves.
This is best for focused tasks with a small scope.
Examples:
Rewrite a draft until it passes a rubric. Fix one failing test. Summarize a research topic. Clean up a small code file. Triage a simple issue. Generate a weekly report.
One agent. One loop. One focused job.
A fleet loop is bigger.
One orchestrator owns the main mission. It breaks the work into parts and sends those parts to specialist agents.
For example:
A research agent finds sources. An engineering agent writes code. A QA agent tests the output. A reviewer agent checks edge cases. A summarizer agent writes the final report.
This is closer to a small AI team than one AI worker.
Fleet loops are powerful, but they are also more expensive and harder to control.
Every extra agent spends tokens. Every extra role adds coordination cost. Every extra branch creates more results to verify.
So the rule is simple:
Start with a single-agent loop.
Move to a fleet loop only when the task is large enough to justify specialists.
Do not build a swarm when one good loop can do the job.
Maker and checker should not be the same agent
One of the most important loop patterns is the maker-checker split.
The agent that creates the work should not be the only agent that verifies it.
Why?
Because models are often too generous when judging their own work.
The model writes code and convinces itself the change is correct.
The model writes an article and misses the weak argument.
The model summarizes research and overlooks the source conflict.
The model drafts a plan and assumes the vague parts are clear.
This is not because the model is useless.
It is because self-review is weak.
Humans have the same problem.
The person who wrote the thing is often not the best person to review the thing.
A stronger loop separates roles.
Maker:
Creates the output.
Checker:
Reviews the output against the goal.
The checker can be a separate model, a stricter prompt, a different tool, a test suite, or a human approval 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 every claim against sources.
For operations, the checker might confirm that the task actually happened in the external tool.
This separation improves quality because the loop no longer depends only on the model grading its own homework.
But there is a trade-off.
Maker-checker loops cost more.
Two agents means more tokens. More verification means more time. More context means larger runs.
So use this where quality matters.
Do not spend reviewer-agent tokens on tasks where a simple gate is enough.
Open loops vs closed loops
There is another important distinction: open loops and closed loops.
An open loop gives the agent a broad goal and lets it explore.
Example:
“Find ways to improve this product and implement the best ideas.”
That sounds exciting.
But open loops are messy.
They can explore too many paths. They can drift away from the goal. They can burn tokens quickly. They can produce lots of output that still needs human review. They can confuse activity with progress.
Open loops are useful for exploration, but they are not the best place to start.
A closed loop is bounded.
The path is clear. The checks are defined. The stop condition is explicit. The scope is limited.
Example:
“Every Monday, check dependency updates. For each safe update, open a PR. Run tests. If tests pass, leave the PR for review. If tests fail, record the failure and stop.”
That is a closed loop.
It is less glamorous, but much more practical.
Closed loops are cheaper. Closed loops are easier to debug. Closed loops are safer. Closed loops produce cleaner results.
Start with closed loops.
Once your verification is strong, your permissions are controlled, your state is reliable, and your token costs are understood, then you can open the loop more.
Reliability first.
Autonomy later.
The minimum viable coding loop
Code is where loops became obvious first.
The reason is simple: code can be checked.
A test passes or fails. A build succeeds or fails. A type checker passes or fails. A linter returns clean or dirty.
That 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 the tests. Read the failures. Fix the root cause. Run the tests again. Stop when the tests pass. Summarize what changed.
That is not magic.
It is just a feedback loop.
But it is powerful because the human no longer has to manually push every step.
The old workflow:
You ask the agent to 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.
The new workflow:
The loop reads the error, fixes the code, runs the tests, and repeats until the gate passes or the loop hits a limit.
The human still reviews the final result.
But the human is no longer the person manually carrying every failure from one step to the next.
That is the leverage.
Real examples of useful loops
The best first loops are boring.
That is a good thing.
Boring loops are easier to verify.
A CI triage loop:
Every morning, scan failed CI jobs. Classify each failure as environment, flaky test, real bug, dependency issue, or infrastructure issue. Draft fixes for simple deterministic failures. Escalate the rest.
A dependency update loop:
Every week, check for safe package updates. Apply one update at a time. Run tests. Open a pull request if everything passes. Record failures if anything breaks.
A lint-and-fix loop:
When a pull request opens, run the formatter and linter. Apply safe style fixes. Run the check again. Stop when clean.
A research loop:
Start with a research question. Search for sources. Extract claims. Verify claims against sources. Compare conflicting information. Write a summary only after the key claims are checked.
A content loop:
Start with a topic, audience, and goal. Draft the piece. Critique it against a rubric. Rewrite the weakest sections. Score again. Stop when the article clears the bar or hits the iteration limit.
An inbox loop:
Every morning, read new important emails and calendar events. Identify urgent messages, meetings that need preparation, and follow-ups that are overdue. Send one short briefing.
A sales outreach loop:
Find leads that match the ideal customer profile. Enrich each company. Qualify against clear criteria. Draft personalized messages. Review for quality. Send only if the message passes the gate or route to a human.
The skeleton is always the same:
Goal. Context. Action. Verification. State. Next move. Stop condition.
Once you see that pattern, loops become much easier to design.
The cost nobody wants to talk about
Loops are not free.
Every iteration costs tokens. Every retry costs tokens. Every verifier costs tokens. Every sub-agent costs tokens. Every context refresh costs tokens.
And the cost compounds.
A loop that runs ten times is not just ten normal prompts.
Each pass may include the original task, the current state, previous failures, tool results, code snippets, logs, and the next instruction.
The context grows.
The bill grows with it.
This is why token budgets matter.
A single medium coding loop can burn a lot of tokens.
A fleet loop with multiple agents can burn much more.
A scheduled loop that runs every day can quietly become a recurring cost center.
The metric that matters is not:
“How many loops did we run?”
The metric that matters is:
“How much did each accepted result cost?”
Cost per accepted result is the real number.
If your loop produces ten outputs and you reject seven of them, the loop is not saving you work. It is creating review debt.
If your loop opens five pull requests and you only merge one, the loop might be more expensive than manual work.
If your loop generates a daily report that nobody reads, it is just automated noise.
A good loop should reduce human load.
A bad loop produces more things for humans to clean up.
The silent failure mode
Bad loops often do not fail loudly.
They fail quietly.
The agent says it is done when it is not done. The verifier is too soft. The loop repeats the same mistake. The state file does not get updated. The output looks plausible but is incomplete. The system keeps spending tokens while producing little value.
This is one of the most dangerous things about agent loops.
A normal script crashes.
A bad loop may continue confidently.
That is why hard gates matter.
A test suite is better than “review this.” A type checker is better than “looks good.” A strict rubric is better than “make it better.” A human approval step is better than silent deployment.
Loops need friction in the right places.
The point is not to remove humans completely.
The point is to remove humans from repetitive steering while keeping them in control of judgment, review, and irreversible actions.
The hidden risk: comprehension debt
There is another cost beyond tokens.
Comprehension debt.
The faster a loop produces work, the easier it is for your understanding to fall behind.
This is especially true in code.
If an agent loop opens pull requests every day, and the team merges them without reading carefully, the codebase starts moving faster than human understanding.
At first, this feels like productivity.
Later, it becomes a problem.
A bug appears. Nobody knows why the code is shaped that way. The agent changed five files that nobody fully read. The tests passed, but the architecture got worse. The system works, but the team does not understand it.
That is comprehension debt.
The loop saved time upfront and created a future debugging bill.
The fix is not to avoid loops.
The fix is to design them with limits.
Read the diffs. Keep loops on small tasks. Use objective gates. Block sensitive areas. Review permissions regularly. Do not let agents make architecture decisions alone. Do not automate judgment calls just because you can.
Loop engineering does not mean surrendering your thinking.
It means deciding where thinking is needed most.
What not to loop
Some tasks are bad first loops.
Architecture rewrites. Auth logic. Payments. Production deploys. Legal advice. Medical advice. Company strategy. Hiring decisions. Brand taste. Anything where “done” is mostly a judgment call.
AI can still help with these tasks.
But the human should stay close.
A loop is strongest when the work is narrow, repeated, and checkable.
A loop is weakest when the work is vague, high-risk, and subjective.
That is the line.
Do not use loops to avoid thinking.
Use loops to stop manually repeating steps that can be safely checked.
How to build your first loop
Do not start with a giant system.
Start with one small loop.
One repeated task. One source of context. One action. One verifier. One state file. One stop condition.
The order matters.
First, run the task manually.
Make sure you understand the steps.
Then turn the instructions into a reusable skill or saved prompt.
Then add a verification gate.
Then add state.
Then add automation.
Do not schedule something before one manual run works reliably.
That is how loops blow up while you sleep.
The minimum viable loop is boring by design.
For example:
Task:
Fix one failing test.
Context:
Read the issue, relevant files, and test output.
Action:
Make the smallest code change.
Verifier:
Run the test.
State:
Record what failed, what changed, and what still needs review.
Stop condition:
Stop when the test passes or after five attempts.
That is enough.
You do not need ten agents.
You do not need a complex orchestrator.
You need a tight loop that can produce one accepted result.
Then you can expand.
A simple self-checking loop you can use manually
You can feel the loop pattern inside any LLM with one prompt.
This is not a full automation, because you still start it manually.
But it teaches the structure.
Use something like this:
That is the simplest version of a loop.
It does not need tools. It does not need scheduling. It does not need multiple agents.
It just changes the pattern from:
“Answer once.”
to:
“Work, check, improve, and stop.”
That mental shift is the important part.
The real job of a loop engineer
A loop engineer is not someone who makes AI run forever.
That is not the goal.
The goal is controlled autonomy.
A 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 fails the work. What state must be saved. When the loop should stop. When a human must review. What the loop must never touch.
This is why loop engineering is more than prompting.
It is closer to workflow design.
You are not just writing instructions.
You are designing the environment where an agent can safely produce useful work.
That means the best loop engineers are not the people who blindly automate everything.
They are the people who know what not to automate.
The mindset shift
The old mindset:
“I need a better prompt.”
The new mindset:
“I need a better loop.”
A better prompt improves one output.
A better loop improves the process that creates outputs.
That is why this skill matters.
The future is not just people writing clever prompts into chat boxes.
The future is people designing systems that repeatedly turn messy attempts into verified results.
The loop is the product.
The prompt is only one part of it.
Final thought
Loop engineering is the shift from manual prompting to automated feedback cycles.
It does not mean humans disappear.
It means humans stop manually driving every small step.
The human defines the goal. The human sets the boundaries. The human designs the verifier. The human reviews high-risk work. The loop handles the repetition.
Bad loops burn tokens and create noise.
Good loops save attention.
A good loop knows what to do, how to check itself, when to retry, when to stop, and when to call a human.
That is the real unlock.
Stop trying to write one perfect prompt.
Build the loop that makes imperfect outputs better.
A reliable loop beats a perfect prompt.
If you read this far:
- BOOKMARK THIS.
- Follow @LunarResearcher
- Follow my Private Telegram Channel