Well, here we are again with yet another term called loop engineering. And it wasn't even that long ago we had harness engineering.
So, is this just marketing hype or is there actually something substantial behind loop engineering?
Let's walk down from prompt engineering all the way to loop engineering to see why we need it each step of the way.
We all know by now what prompt engineering is. Let's say I start with the prompt, you are a helpful customer service rep. Please be nice to my customers.
This is prompt engineering because you are prompting the agent by implicitly telling the agent what to do. And we can then ask AI any question and the agent will impersonate a customer service rep based on the prompt we just generated.
That makes sense and it is super simple. So why do we need context engineering?
Turns out this prompt that we just created lives inside of the agent's context window and we still have a lot of room left in our context to do something more useful.
So what if we gave the agent autonomy to invoke tools to start filling up its own context based on what the prompt actually needs?
This was the beginning of context engineering, where the agent could now access files to load and make changes or even use MCP to start interacting with databases and external applications to load its own context.
Cool. Context engineering makes sense. So then why do we need harness engineering?
Well, there's actually no inherent flaw in context engineering, but rather it has limitations.
Context engineering is not really good at tasks that take longer than 5 to 10 minutes. And here's why.
Tasks that take long tend to require more context than what the agent can handle. And while it could keep summarizing its own context as it approached the limit, it was extremely leaky, where important details started to get lost in each step of the summarization.
So essentially we needed a system outside of context engineering to better manage its own context from the outside in, and this very external system is what we call harness engineering.
Harness engineering manages the context from the outside and helps the agent runtime to work on tasks that help break down the user's requirement into a more stable execution.
Let's look at a few examples to make sure that we understand this more concretely, using ChatGPT and Claude Code since it's something that we all have hands-on experience with.
Asking ChatGPT the question, how many cheeseburgers can I fit between the Earth and the Moon? This is solely using prompt engineering because it doesn't need anything external to answer a very simple question. It can just reason through what it already knows to answer my question.
Now asking ChatGPT what is the latest discovery that NASA made. This now has to use context engineering because it has to search the web and gather relevant information from NASA to help answer my question. So context engineering helps bring information from the web autonomously.
Now when I ask Claude Code, can you clone the entire NASA website? This is all done by harness engineering, because the NASA website, as you can imagine, is really complex, and simply relying on context engineering on tasks like this will start to choke midway through.
So harness engineering provides an external mechanism to help manage the context and the runtime for the agent to work through a long list of tasks.
Now you might have noticed a pattern that emerges from this, and that pattern is the concept of loops.
For context engineering, there's a loop where the agent recursively calls tool after tool autonomously until it thinks that it has enough context to answer your question.
And for harness engineering, there's also a loop where the agent has a list of tasks outside of the context window to keep iterating task after task until the entire operation is finished.
So what we find is that we are essentially stacking loop on top of another loop.
Now we get to loop engineering, which is yet another loop in itself. I know, is there even an end to this?
So loop engineering stacks another loop outside of the harness engineering layer to guide the harness externally.
But why? Why do we even need yet another scaffolding?
Again, at the heart of loop engineering, it targets the human interaction in actually prompting the agent to do something.
Everything that we have seen so far involves a human asking the agent questions like, how many cheeseburgers can I fit between Earth and the Moon? What is the latest news on NASA? Or even clone NASA's website.
These are prompts that require me to actually prompt the agent.
But what if we built a scaffolding outside of this so that the agent can also prompt itself on what it thinks it needs to do?
That is the heart and the spirit of what loop engineering tries to target.
And if all of this sounds hokey pokey to you, you're probably not alone. There's a lot of people saying loop engineering is just a buzzword that's trying to encourage people to just burn more tokens and create more AI slop.
And so far, we have really yet to see loop engineering in action that really makes a huge difference. But it could be the next evolution in our engineering philosophy as agents expand their scope in what they can help us with.
And it does raise a really interesting debate and discussion around all of this. So what exactly is loop engineering and how does all of it work?
Addy Osmani wrote a blog describing loop engineering with six components. But instead of boring you with details, I'm going to give you a potential use case of loop engineering to help you wrap your head around what loop engineering could look like.
Let's say I built a website that keeps track of the World Cup scores. And when I ask Codex to build me a World Cup website, Codex will use prompt, context, and harness engineering to build this beautifully written website.
Now, there's one problem here, and that problem is that the World Cup games are happening every single day.
And that means in order to maintain the website that I just created through Codex, I have to keep prompting the agent to frequently update the site and also work on bug fixes that people might find on the website.
But what if I just created a scheduled task inside of Codex to check every hour for updates as new information becomes available?
And what if I do the same for bug fixes, where the agent just checks autonomously for bugs that are reported by users and fixes them?
What you're seeing here is that we are beginning to create this loop outside of harness engineering where it's self-guided rather than human-guided to maintain my website.
And because I have skills and plugins already installed on my Codex environment, the agent can access an existing knowledge base to keep building and improving its knowledge along the way.
And the agent can also use subagents to verify its own work, plus the ability to work on multiple fixes at the same time by using what's called a worktree to prevent runtime contamination along the way.
All of these that I just mentioned are essential ingredients to what makes loop engineering what it is. And that is the six components that Addy Osmani wrote in his blog.
Automation, worktrees, skills, plugins and connectors, subagents and state are the components of loop engineering.
And while this World Cup website that I just created is just an example of what loop engineering could look like, the true potential of what loop engineering could really be is still somewhat theoretical.
And one thing to keep in mind is that loop engineering doesn't necessarily mean that all the engineering philosophy underneath is less important or even less needed than before.
It's just agents growing in scope and building on top of each other.
Antonioni Nascimento
Software, cybersecurity, data & AI. Building advanced systems at KRX. Writing about technology, venture capital, and how software shapes markets.