Loop Engineering: Designing Systems That Prompt
Get the free AI Agent Building Blocks ebook when you subscribe:
Many engineers still use AI like a very fast intern sitting next to them.
They write a prompt. Wait. Read the answer. Add more context and re-run. Paste the error back and ask again.
At some point, the limiting factor is not the model. It is you sitting there as the person who keeps the agent alive, one message at a time.
This is what the new AI fancy word, Loop Engineering, is about
Loop engineering is the practice of designing AI systems that repeatedly find work, prompt agents, call tools, observe results, evaluate progress, remember state, and stop when a condition is met.
Instead of prompting every step yourself, you design the process that prompts the agent for you.
This changes your work. You’re not the entrepreneur operating the company, but designing systems for the company to work without you.
In this post, you’ll learn
What loop engineering is and why it comes after prompt engineering and agentic engineering
How loop engineering changes work
The evolution from GPT-2 to today
What a good AI agent loop needs
Why human judgment still matters
What Is Loop Engineering?
Loop engineering is what happens when you stop treating AI as a chat window and start treating it as a recurring system.
We started telling AI, “Do this thing.”
Nowadays, most people tell, “Do this thing, use the tools, inspect the result, and continue.”
A loop says, “Every morning, check this source of work. Run certain actions. Verify the result. Write down what happened. Escalate anything ambiguous.”
Prompt engineering optimizes the instruction.
Agentic engineering gives the model hands and tools.
Loop engineering designs the machine that keeps those hands working.
This is why Addy Osmani’s framing in his blog clicked for so many engineers. The job is moving from prompting the agent to designing the system that prompts the agent.
I had agents who could review CRs and address comments. But I was still starting the workflow and gluing the system together.
At that point, the next productivity gain was obvious. Remove myself from the start button and frontload the work with AI so I just review the result.
The Pattern Behind Loop Engineering: More AI Work Per Human Input
The evolution of LLMs is usually described as “models got smarter.” We see it all the time, a lab releases a new model, the most shared screenshot is the table of benchmarks.
This isn’t what’s most useful for engineers.
Our real benefit is getting more AI work from the same amount of human input.
This is the timeline and where Loop Engineering fits:
Phase 1: Base LLMs Were One Prompt, One Answer
The first useful pattern was simple request-response. You wrote a prompt. The model predicted the continuation. You read the answer.
This was the GPT-2 era. The model was impressive because it could generate coherent text from raw input without task-specific training. But the unit of work was tiny.
One human prompt. One model response.
The model generated text. The human operated the workflow.
Phase 2: Reasoning Models Added More Compute Behind One Prompt
The next shift was not only bigger models. It was models that spent more compute at inference time.
With reasoning models, the interface is hte same. But the model now does more work before responding. It can break down the problem internally, evaluate options, and spend more tokens on hard tasks.
Still, the human remained the operator.
You had to decide the next prompt.
Phase 3: Agentic Engineering Turned One Prompt Into Many Actions
Agents changed the shape of the work. The model stopped being only a text generator and became a decision-maker inside a runtime.
It could inspect files, search the codebase, run commands, and try again.
One prompt became many actions.
And we could design different agents for different jobs: An agent to implement, and an agent for code review, etc.
But the work done was still limited to one task, the one we indicated in the input text
A useful next step is my breakdown of how I moved from manual prompting to autonomous agents that handle tickets, code, and reviews:
Phase 4: Loop Engineering Turns One Design Into Many Agent Runs
Loop engineering starts when you stop launching the workflow by hand.
Instead of saying, “Agent, implement this ticket,” you define the system
That is the loop.
For example, imagine a loop that runs every morning: It checks the backlog, filters ready tickets, sends one to a developer agent, validates the change, opens a PR, and writes back to the ticket. If the requirements are vague, it asks for clarification instead of guessing.
The important part is not that the agent can do one ticket. The important part is that the system can keep finding the next ticket without you sitting there.
This is why loop engineering feels different from agentic engineering. An agent is a worker. A loop is the workflow that decides when the worker should act.
That is also why loops need memory. A single model run forgets. A loop needs a place outside the conversation to store what happened.
Your role as a human isn’t anymore to input every unit of work, but to create an input once for the system, and the system will run that input in each unit of work. You still have to review a final output, but you will find the output without having written an input for this unit of work.
Read more about how harness engineering uses guardrails, state, and feedback loops to make AI coding agents reliable:
How To Start With Loop Engineering Without Breaking Everything
The best way I found to build loops is the same way I built my agents: do the work manually first.
You cannot automate what you cannot describe. So pick one boring workflow your team already does often, for example, Ticket triage. Do that work yourself a few times and write down the decisions you make without noticing.
Then automate the smallest useful version with an agent that does all the steps with one of your inputs: “Triage ticket JIRA-1234 and write the output in a comment in the ticket itself“
Only after you’re happy with its output, you add the loop. Then you have a system that works without you on jira tickets.
The human is left for higher leverage work.
This connects with my three-level AI productivity framework, where the real leverage comes from improving the system around the agent, not only the prompt inside it:
Conclusion: Build The Loop, Stay The Engineer
At some point, the best AI skill was to write better prompts.
Then it became about giving agents better tools.
Now the skill is moving again.
Now it’s all about designing loops: recurring systems that find work, run agents, verify progress, remember state, and stop when they should.
Think about the era before AI. As engineers, we were not only operating the system by coding tickets and reviewing PRs.
We were setting shared templates for technical designs, quality criteria checklist for PRs, and setting up tools like linters and formatters in our code.
Loop engineering is all about applying engineering principles to AI.
You are not replaced.
You become the person designing the system.
If you want to go deeper, I’d recommend following these 10-step guide to create your first Agent in a Loop