Loop Engineering Explained: From Prompt Engineering to Self-Prompting AI Agents

Every few months, the AI world gives us a new word. First it was prompt engineering. Then context engineering. Then harness engineering. And now we have loop engineering.

So the obvious question is: is loop engineering just marketing hype, or is there something real behind it?

The honest answer is “a bit of both.” But you can only judge that fairly once you understand why each new term showed up. So let’s walk the full ladder from prompt engineering all the way up to loop engineering and see what problem each one was actually trying to fix.

By the end, you’ll be able to explain loop engineering to a friend in one sentence.

The short version (TL;DR)

Each stage exists to fix a limit of the stage before it. Here’s the whole story in one table.

Now let’s look at each one properly.

Stage 1: Prompt engineering

This is the one everybody already knows.

Prompt engineering is simply telling the agent what to do using instructions. For example:

“You are a helpful customer service rep. Please be nice to my customers.”

That’s it. You’ve given the model a role and a rule. Now, whatever question comes in, the agent will answer as if it were a customer service rep. Simple and effective.

Prompt engineering shines when the model can answer using only what it already knows. A classic example:

“How many cheeseburgers can I fit between the Earth and the Moon?”

The agent doesn’t need to search the web or open any files. It can just reason through the numbers it already has. Pure prompt engineering.

But there’s a catch. Your prompt sits inside the agent’s context window the space where the model keeps everything it’s currently “thinking” about. And a single prompt uses only a tiny slice of that space. So a natural next thought appears: what if the agent could fill the rest of that space with useful information on its own?

That’s exactly where the next stage begins.

Stage 2: Context engineering

Context engineering is when you give the agent the freedom to fetch its own context by using tools.

Instead of you pasting in every detail, the agent can:

• Read and edit files
• Search the web
• Call APIs and databases through MCP (Model Context Protocol)
• Pull in documents or code it needs

Here’s a good example:

“What is the latest discovery that NASA made?”

The model cannot answer this from memory alone, because the information is new. So it searches the web, gathers the relevant details, and then answers. That act of going out, grabbing information, and loading it into its own context is context engineering.

If you want to go deeper on how agents pull in outside data, MCP is the key protocol behind it. (Internal link idea: your MCP primitives guide / “MCP vs function calling” article.)

Context engineering feels almost magical. So why isn’t it the final answer?

Stage 3: Harness engineering

Context engineering has no single “flaw” but it does have a real limit.

It struggles with tasks that run longer than about 5 to 10 minutes.

Here’s why. Long tasks need a lot of context. But the context window is finite. As the agent nears the limit, it starts summarizing its own context to make room. The problem is that summarizing is leaky — small but important details get dropped at every round. After a few rounds, the agent has forgotten things it needed.

So we needed something outside the agent to manage its context and keep long tasks on track. That outside system is harness engineering.

A harness manages context from the outside. It breaks a big user request into a stable list of smaller steps, then feeds the agent the right pieces at the right time so the agent never has to cram everything into one window.

Example:

“Can you clone the entire NASA website?” (asked to a coding agent like Claude Code)

The NASA site is huge and complex. Context engineering alone would choke halfway through. A harness handles this by managing the task list and the runtime from the outside, guiding the agent through a long sequence of steps without losing the plot.

The pattern nobody points out: loops inside loops

Notice something? A loop keeps showing up.

• Context engineering is a loop: the agent calls one tool, then another, then another again and again until it decides it has enough context to answer.
• Harness engineering is also a loop: the agent works through a task list stored outside the context window, finishing one task, moving to the next, until the whole job is done.

So we’re already stacking one loop on top of another loop.

Which brings us to the newest term — which is, you guessed it, yet another loop.

Stage 4: What is loop engineering?

Loop engineering stacks one more loop on top of harness engineering to guide the harness from the outside.

But here’s the important part — and it’s what makes loop engineering different from everything before it:

Every stage so far still needed a human to press “enter.”

A person had to ask “How many cheeseburgers…?”, “What’s NASA’s latest discovery?”, or “Clone the NASA site.” The human was always the one starting the loop.

Loop engineering targets exactly that step. The idea is to build a system where the agent prompts itself — deciding what needs doing and kicking off the work — instead of waiting for a human.

Addy Osmani, a director on Google’s Cloud AI team, coined the term in June 2026. His one-line definition is the cleanest anyone has written: loop engineering means you stop being the person who prompts the agent, and instead you design the system that prompts it for you.

The leverage has moved. Last year, the valuable skill was writing a great prompt. Now, the valuable skill is designing the loop that writes the prompts.

A real example: the self-updating World Cup website

Say you ask a coding agent (like Codex) to build a website that tracks World Cup scores. Using prompt + context + harness engineering, it builds you a clean site.

But there’s a problem: World Cup games happen every single day. To keep the site correct, you’d normally have to keep prompting the agent — “update the scores,” “fix this bug a user reported,” and so on. That’s a human in the loop, forever.

Loop engineering flips this. Instead, you set up:

• A scheduled task that checks for new scores every hour and updates the site automatically.
• Another routine that watches for bug reports from users and fixes them on its own.
• Sub-agents that review the first agent’s work before anything ships (a model grading its own homework always gives itself an A).
• git worktrees so the agent can fix several things in parallel without the changes stepping on each other (“runtime contamination”).
• Skills and plugins already installed, so the agent has a knowledge base to build on.

Now the loop is self-guided instead of human-guided. You went to sleep; the website kept itself alive. That is loop engineering.

The 6 components of loop engineering

In his essay, Addy Osmani breaks a working loop into five building blocks plus a sixth piece — state — that ties them together. Together, people usually list them as six:

1. Automation — scheduled tasks that start the loop on a cadence, with no human hitting “go.” This is what makes it a loop and not a one-off.
2. Worktrees — isolated, parallel copies of your project (via git worktree) so the agent can work on several fixes at once without conflicts.
3. Skills — reusable project knowledge written down (for example, a SKILL.md file) so the agent doesn’t re-learn your conventions every time.
4. Plugins and connectors — MCP integrations that connect the agent to real tools, apps, and data.
5. Sub-agents — a second agent that independently checks the first one’s work, catching mistakes the “maker” would happily approve.
6. State (memory) — an external place the agent reads at the start and updates at the end, so progress survives between runs. Models forget between sessions, so this durable memory is the glue.

Start with state it’s the cheapest win

If you want to try this, don’t start with full automation. Start with state. A simple markdown file the agent reads first and updates last will instantly make runs build on each other instead of starting from zero.

Here’s a tiny, copyable example you can drop into a project as STATE.md:

markdown

# Project State

## Done
- Built base World Cup site layout
- Connected live scores API

## In Progress
- Fixing timezone bug on match times

## Next
- Add group-stage standings table
- Set up hourly score refresh

Tell the agent: “Read STATE.md before you start. Update it before you stop.” That one habit alone makes agent work feel far less forgetful and it’s the foundation everything else in loop engineering sits on

So… is loop engineering real, or just hype?

Fair question, and you’re not alone in asking it.

Plenty of people say loop engineering is just a buzzword a way to get you to burn more tokens and generate more AI slop. That criticism has weight. So far, there aren’t many public examples where loop engineering clearly changed the game, and even Osmani himself is careful to say it’s early and that token costs can spiral fast if you’re not watching.

But here’s the balanced view. Loop engineering isn’t really a new invention so much as the next floor of the same building. Prompt, context, and harness engineering don’t disappear a sloppy prompt inside a loop just produces sloppy work faster. The lower layers still matter. Loop engineering simply adds an autonomous control layer on top of all of them.

It might turn out to be the next big shift in how we work with agents. Or it might stay mostly theoretical for a while. Right now, the truth is somewhere in the middle which is exactly why it’s worth understanding, but not worth blindly hyping.

Conclusion

The whole journey is one clean idea repeating itself:

• Prompt engineering: you tell the agent what to do.
• Context engineering: the agent gathers its own information.
• Harness engineering: an outside system keeps long tasks stable.
• Loop engineering: the agent prompts itself and runs on its own.

Each stage is just agents growing in scope and building on top of the one below it. The skill that matters most keeps moving up from writing the prompt, to designing the system that writes the prompts for you.

Frequently asked questions (FAQ)

What is loop engineering in simple words? Loop engineering is building a system where an AI agent prompts itself on a schedule and without a human starting it instead of waiting for you to type a request each time.

Who coined the term loop engineering? Addy Osmani, a director on Google’s Cloud AI team, named and structured the idea in an essay published in June 2026.

What is the difference between harness engineering and loop engineering? A harness manages the context and steps around one running task. Loop engineering wraps a layer around the harness adding scheduling, memory, and self-prompting so the whole thing runs repeatedly on its own.

Does loop engineering replace prompt engineering? No. The lower layers still matter. A weak prompt inside a loop just creates bad output faster. Loop engineering adds an autonomous layer on top; it doesn’t remove the layers below.

What are the components of loop engineering? Automation, worktrees, skills, plugins and connectors, sub-agents, and state (memory).

Is loop engineering just hype? It’s early. Some call it a buzzword that burns tokens, and clear real-world wins are still rare. But it fits a genuine pattern of agents taking on bigger scope, so it’s worth learning even if you stay skeptical.

References

• Addy Osmani’s blog (source post): https://addyosmani.com/blog/loop-engineering/
• Model Context Protocol (MCP)
• Git worktree — official documentation
• Anthropic on sub-agents in Claude Code

Popular Posts

• Loop Engineering Explained: From Prompt Engineering to Self-Prompting AI Agents
• Build Your First MCP Server with FastMCP: A Complete Python Tutorial
• MCP vs Function Calling: Key Differences Explained (2026)
• What Is Model Context Protocol (MCP) – A Complete Guide for AI Developers
• MCP Primitives Explained: Tools, Resources, and Prompts With Real Examples