Most people use an AI agent like a vending machine. They put in one prompt, they get one answer, and if the answer is wrong, they shrug. The agent workflow that actually finishes hard tasks looks nothing like that. It is a loop.
I am a solo developer building in public under softDev23, and I lean on AI agents for real work, not demos, including the MCP servers I actually use with Claude. Over the last few weeks, I have settled on a way of running them that I have started calling loop engineering, and it has been the difference between an agent who gives up and one who gets the job done.
This is what it is, why one-shot prompting fails on anything hard, and the two rules that make the loop actually work.
Why one-shot prompting falls apart
A single prompt works fine for a single, well-defined ask. Write this paragraph. Rename these files. The trouble starts when the task has many steps, hidden unknowns, or a definition of done that you cannot fully specify up front.
On those tasks, a one-shot prompt forces the agent to guess. It cannot check its own work against reality, so it produces something plausible and stops. Plausible is not the same as correct, and on a hard task, the gap between them is where all the pain lives.
The fix is not a longer prompt. It is a different shape of work. Instead of asking once and accepting whatever comes back, you put the agent in a loop where it tries, checks against the real world, and adjusts until the task is genuinely done.
What loop engineering means
Loop engineering is just taking that idea seriously and building a structure around it. The agent does not get one chance. It gets a cycle. Act, observe the real result, compare against the goal, and repeat until the goal is met or proven impossible.
The general principle behind capable agents is well covered in Anthropic’s own guidance on building agents, but the practical version I use comes down to two rules that I learned the hard way. A loop without these two rules just spins.
The first rule is memory. The second rule is that nothing counts as done until it is tested against reality. Together, they turn a chatty assistant into something that closes tasks.
Rule one: give the loop a memory
An agent that forgets what it learned on the last pass is doomed to repeat the same mistakes. So the first thing I do is give the loop a persistent memory, usually a plain file that the agent reads and writes as it goes.
That file holds the goal, what has been tried, what worked, and what is still open. At the start of each pass, the agent reads it. At the end of each pass, it updates it. The memory is what lets the loop make progress instead of wandering in circles.
This is the same reason my whole setup lives in plain text files. I wrote about connecting an AI to an Obsidian vault for exactly this, because an agent can read a folder of notes directly and treat it as working memory. The loop and the memory are two halves of the same idea.
Without memory, every pass starts cold. With it, the agent compounds what it learns, and a task that would never finish in one shot slowly converges.
Rule two: test, never assert
The rule that changed everything for me is simple to state. The agent is not allowed to claim that something works. It has to prove it.
It is incredibly easy for an agent to write a confident sentence like the field was set successfully and move on. That sentence is worthless. The only thing that counts is reading the value back from the real system and seeing that it is actually there.
I learned this when an agent told me a capability was impossible, I pushed back, and a real test proved it was not only possible but already working. The agent had asserted instead of testing, and it was confidently wrong. Now the loop has a hard rule. No capability is marked done without a live check that reads the result back.
This single rule removes most of the lies. An agent that must test cannot fool itself, and if it cannot fool itself, it cannot fool me. The loop stops being a story the agent tells and becomes a record of what is verifiably true.
When to end the loop
A loop needs an exit, or it runs forever. Mine has two. It ends when the goal is met and proven, or when the agent has genuinely established that the goal is impossible on the current setup.
That second exit matters more than it sounds. A lot of wasted effort comes from an agent flailing at something that cannot be done, or from a human assuming something is impossible without checking. By making impossibility a real, tested conclusion rather than a guess, the loop either finds a way or tells me honestly that there is not one.
Either outcome is useful. A proven yes gives me a working capability. A proven no saves me from chasing it again next month. The waste is in the unproven middle, and the loop is designed to squeeze that out.
Guardrails that keep a loop honest
A loop is powerful, which means it can also do damage at speed if you let it run unchecked. So the loop has guardrails, not just a goal.
The first is that side effects need a human, yes. The agent can read, search, and test freely, but anything that changes the real world in a way that is hard to undo waits for my approval. Reading my site is fine on its own. Publishing to it is not something I let a loop decide alone.
The second is a step budget. A loop that has not converged after a sensible number of passes is usually stuck, not close. Rather than let it burn time and money spinning, it stops and reports what it learned. I would rather get an honest I am stuck after ten passes than a fake success after fifty.
The third is the memory itself, which doubles as an audit trail. Because every pass writes down what it tried and what happened, I can read back exactly how the agent reached a conclusion. If it ever does something surprising, the reasoning is on the page, not lost in a chat window.
These guardrails are what make me comfortable letting a loop run on real work. Speed without them is just a faster way to make a mess.
How this looks in practice
The most recent place I used this was building my publishing system, which I describe in my post on n8n WordPress automation. I did not assume any part of the WordPress API worked the way the docs implied. The agent set each field, read it back from the live site, and only then recorded it as proven.
When something failed, the memory file captured exactly why, and the next pass tried a different approach. The agent worked through broken image models, awkward tag handling, and a field that everyone online said was impossible to set, and it closed each one by testing rather than hoping.
The result was a system I actually trust, because every capability in it was earned in a loop, not asserted in a sentence. That trust is the real product. The automation is just what the trust let me build.
An AI agent workflow is not only for code
I keep describing this with technical examples, but the loop is not really about code. It is about any task where you cannot fully specify the answer in advance and have to discover it.
Research works this way. So does writing, planning, and most of the messy real work that does not fit a neat prompt. In each case, the same shape helps. Make an attempt, check it against something real, keep a record of what you learned, and go again. The subject changes. The loop does not.
That is why I think loop engineering is worth naming, even though the idea is old. Naming it makes me use it on purpose instead of stumbling into it. When a task feels too big or too vague for one prompt, that is the signal to stop prompting and start looping.
The mindset shift
The hardest part of loop engineering is not technical. It is giving up the fantasy of the perfect prompt. There is no magic wording that makes an agent reliably finish a hard task in one go, and chasing it is its own kind of procrastination.
What works is humbler and more durable. Accept that the agent will be wrong on the first pass, give it a memory so it learns, and force it to prove its claims against reality. Do that, and an ordinary agent starts finishing tasks that a clever prompt never could.
If you are building anything serious on top of AI agents, stop optimizing the single prompt and start engineering the loop. Give it memory, make it test everything, and define what done and impossible actually mean. That is the workflow that turns an agent from a confident guesser into something that genuinely gets the job done.
