Loop Engineering

Introduction

For the past two years, most of our time has been spent learning how to prompt AI: how to write prompts, how to supplement context, and how to make it output in a specific format.

But in recent months, another term has started to be frequently discussed in the Silicon Valley AI circle: Loop Engineering.

It doesn't mean prompts are no longer important, nor is it just a new name for Agent. More accurately, it answers a more practical question: when an Agent is no longer just an assistant in a single conversation but needs to be placed into long-running tasks, how should the system be designed?

---

Starting with a Common Problem

Many people have an "Aha Moment" the first time they use a coding agent or workflow Agent: it can actually get things done.

You give it a goal, and it reads files, researches, writes code, runs tests, and fixes errors. Even if it makes mistakes along the way, you're watching and can always add a comment: "This part is wrong, try again."

At this point, the Agent is like a very smart intern. It might not always get things right, but as long as you watch it, it can keep moving forward.

The real problem arises in the next step: you don't want to sit beside it every time, but you still want the Agent to deliver results 24/7.

You want it to wake up daily on its own, check for new tasks; handle problems it finds; suspend if it can't handle them; call you when human approval is needed; and record its status after execution so it can pick up where it left off next time.

At this point, it becomes a different problem. It's no longer about "how well did the model answer this time," but about:

• Who triggers the next round of tasks;
• What context should the Agent receive this time;
• Who checks the results;
• What to do after an error: retry, skip, or stop;
• Where to store the state;
• Which actions cannot be performed directly by the AI;
• After 1000 runs, can the system still know what it's doing.

If a human is monitoring, they can correct these issues promptly, or at worst, clear the context and restart the task. But once you truly put an Agent into a continuous, uninterrupted workflow, you'll find that no matter how beautifully you write the prompt, you can't avoid these problems:

• The model output occasionally misses a field;
• An external API occasionally times out;
• Context left by one failure pollutes the next judgment;
• The Agent evaluating its own results tends to be overly lenient;
• A task is interrupted halfway, and the next round doesn't know where to resume;
• Side-effect actions have already occurred, and retrying causes duplicate sending, writing, or charging.

These are not problems that can be solved by "adding another prompt."

This is where Loop Engineering proves its value.

---

Why Loop Engineering is Exploding in Popularity

Loop Engineering isn't a new concept that suddenly emerged from a research paper. It's more like several existing threads converging and being renamed.

Earlier, Andrew Ng talked about agentic workflows, emphasizing that models shouldn't just answer once but should be able to reflect, plan, use tools, and collaborate with multiple agents. That layer was about: how to make Agents perform better.

Around May 2026, people had already started talking about longer-cycle Agents: memory, cron, skills, self-improvement loops, and continuous maintenance. These all point to the same shift: Agents are no longer just chat windows; they are starting to resemble background processes.

What truly brought the term "Loop Engineering" to the forefront was Peter Steinberger's post on X in early June, suggesting that instead of prompting coding agents line by line, we should design loops that can prompt agents. Addy Osmani then wrote "Loop Engineering," breaking down a loop into automation, worktrees, skills, plugins/connectors, sub-agents, plus a layer of memory.

These individuals express it slightly differently, but they point in the same direction: human work is shifting from "personally giving the Agent step-by-step instructions" to "designing a system that allows the Agent to work repeatedly, continuously, and uninterrupted."

This is also why I think Loop Engineering isn't an academic concept. It's more like a term that frontline engineers arrived at through practical experience with Agents.

---

The Four-Layer Progression from Prompt to Loop

Actually, the progression from Prompt to Loop is a layered one:

prompt → context → harness → loop

A Prompt is a one-time instruction. You tell the Agent what to do, and it answers once or executes a segment of a task.

Context is context management. You feed it project rules, history, files, memory banks, and retrieval results so it doesn't have to start from scratch every time.

Harness is the equipment layer for a single Agent execution. It enables the Agent to read files, run commands, call tools, access APIs, and complete a task within certain permission boundaries.

Loop is the next level up. It's not just concerned with "how this Agent runs this time," but also with:

• How tasks are discovered;
• Which Agent or tool should be called;
• How outputs are verified;
• How failures are categorized;
• How state is saved;
• How the next round connects;
• When to stop or escalate to a human.

Many so-called "AI automation" systems only reach the harness layer. They can run a single task, but the outer layer still relies on human oversight: humans discover tasks, judge failures, decide on retries, and record status.

What Loop Engineering aims to add is precisely this outer loop layer.

---

A Loop Isn't About Running Forever, But About Closing the Agent's Loop

The term "Loop" can easily be misunderstood as: make the Agent run continuously until it finishes the job.

That's actually too simplistic.

A truly usable Loop isn't a simple while loop; it's closer to this:

Observe → Classify → Route → Act → Verify

First, observe the current system state, such as logs, databases, queues, or external API returns. Then, classify what kind of signal this is: normal, warning, error, or a risk that requires immediate stopping. Next, decide which Agent, script, or tool to route it to. After execution, you can't just let the Agent say "I think it's done"; you must verify the result in a deterministic way.

This is also the difference between Loop Engineering and a regular Workflow.

A Workflow is more about defining "in what order things happen": A to B, B to C, C to D. It certainly has value, and mature Workflows can also handle branches and retries.

But in real long-running tasks, the trouble usually isn't on the success path:

• Node A returns a null value, but Node B continues its judgment;
• The model output format is non-compliant, but subsequent nodes still parse it;
• An external service rate limits, and the system immediately retries, amplifying the problem;
• The previous attempt succeeded in sending, but the next retry sends it again;
• Quality checks are just the model self-evaluating, and it tends to be lenient with itself;
• Manual approval lacks a suspension mechanism, forcing reliance on human monitoring outside the process.

A Workflow is the skeleton. A Loop adds feedback, state, verification, retry logic, stop conditions, and human handover onto that skeleton.

---

Memory Isn't About Never Losing a Conversation

Here's a point that's easy to get wrong in both implementation and understanding: Loop Engineering certainly needs memory, but it doesn't need "to keep all conversation context forever."

Long conversation context is very useful, but it's not reliable business memory.

The reason is simple: context grows, gets mixed with failed attempts, gets filled with temporary judgments, and can also be incorrectly amplified in the model's next round of reasoning. You can't rely on a single conversation to hold state like "which step has the system reached," "what was the reason for the last failure," "is a retry allowed this time," or "has a certain action already produced side effects."

A more reasonable approach is to separate two things:

• Working Context: The materials, constraints, and local history the Agent needs to see for this execution. It can be reconstructed and discarded after the task ends.
• Long-term State / External Memory: Task progress, structured results, failure reasons, approval status, retry counts, records of external side effects. This should reside in databases, files, task boards, queues, or other recoverable media.

Therefore, "context can be discarded" and "memory must persist" are not contradictory.

What should truly be discarded is temporary conversational noise; what should truly be saved is structured, recoverable, auditable state.

This is also something I discovered in actual implementation: models forget, conversations break, contexts fill up, but files and databases don't forget. Long-running Agents must write state externally; they cannot keep it only in the context.

---

A Functional Loop Typically Needs These Components

A usable loop generally cannot do without these six parts.

First is automation. Without automatic triggers, it's still a person manually starting tasks. It can be scheduled tasks, webhooks, event queues, or some background heartbeat.

Second is isolation. In coding agents, a worktree is common; in other scenarios, it might be an independent task space, independent cache, independent browser environment, or at least an independent context for each round of tasks. Without isolation, multiple agents running in parallel can easily pollute each other.

Third is skills. Here, a skill is not just a prompt template; it's more like a project knowledge package: rules, boundaries, SOPs, common pitfalls, build methods, and acceptance criteria. Every time an agent cold-starts, it can first read stable knowledge, rather than relying on residual context from the previous session.

Fourth are plugins and connectors. An agent that can only write documents is still far from production. A real Loop needs to connect to tools: databases, CI, GitHub, Feishu, email, logging systems, monitoring systems. Connectors determine whether it's a toy or something that can enter a real work environment.

Fifth are sub-agents. The value of multiple agents lies not in being lively, but in division of labor. Especially the separation of maker / checker: the agent generating results shouldn't score its own results alone. Use rules for verification first; what rules can't judge, then hand it over to an independent Checker or a person.

Sixth is memory. Not the memory in the model's "brain," but external long-term state: what has been done, what has failed, what's next, which issues need human handling, which rules need to be solidified back into skills.

These components aren't meant to make the architecture diagram complex, but because without them, the Loop will quickly expose problems in real operation.

---

The Most Underestimated is Risk

Loop Engineering sounds enticing: write fewer prompts, let the Agent push tasks forward on its own.

The risk is also here: once a Loop runs unattended, errors will also continue to occur unattended.

In practice, Loop Engineering also has issues:

First is verification debt. You know the system has problems, but you haven't written verification into the closed loop. Known problems accumulate, eventually becoming "if no one asks, pretend nothing's wrong."

Second is comprehension rot. The system runs more and more automatically, but people understand less and less why it runs. Documentation is scattered, state is scattered, logs are scattered; newcomers can only guess from a pile of historical traces.

Third is uncontrolled token and API costs. Once a Loop runs unattended, without budget caps, stop conditions, and backoff strategies, abnormal retries can become very expensive.

Fourth is cognitive surrender. The most dangerous thing isn't the system making mistakes, but people gradually giving up on understanding, reviewing, and judging because it mostly runs fine.

So a good Loop isn't about "maximizing full automation," but about being:

• Stoppable;
• Verifiable;
• Having memory;
• Having boundaries;
• Having a budget;
• Observable.

These six words are more important than "high degree of automation."

---

People Don't Disappear, Their Position Changes

Loop Engineering is most easily misinterpreted as "full automation." I think this is actually dangerous.

The closer it gets to real users, real funds, production data, and external sending, the less you can let the Agent run the entire course on its own.

A more stable division of labor is:

• Agent handles fuzzy judgment: understanding content, classification, matching, generating candidate solutions;
• Code handles deterministic actions: fetching, transmitting, writing, validation, permissions, state transitions;
• Checker or rule system handles quality gates: fields, format, duplicates, anomalies, risk words, constraints;
• People handle high-risk approvals: sending, payments, deletions, deployments to production, actions not easily reversible.

This isn't lowering the degree of automation, but placing human attention in more valuable positions.

If people are still copy-pasting every piece of low-risk data, the system isn't amplifying efficiency; if people don't look at any high-risk actions at all, the system will amplify accidents.

A good Loop shouldn't pursue "people being completely absent," but should pursue "people only appearing when they should."

In Closing

Loop Engineering isn't "just another new AI buzzword." Instead, it brings a very basic problem to the forefront:

Before, people stood inside the loop, pushing AI forward with patience and experience; now, if we want Agents to truly enter long-term tasks, we must design this loop itself.

In this design, prompts are still important, context is still important, and harnesses are also important. But they are only prerequisites for the Loop.

What truly determines whether the system can run stably is whether it has stable scheduling, clean working context, reliable long-term state, deterministic validation, failure recovery, cost boundaries, and necessary human intervention.

In other words, Loop Engineering isn't about making Agents more like people, but about making Agents more like a system component that can be scheduled, constrained, inspected, and recovered.

This might not sound as exciting as "a super Agent taking over all work." But if the goal is to let AI work continuously in real environments, this is a more feasible path.

References

1. Loop Engineering — Addy Osmani — The original article that systematized the term "Loop Engineering," decomposing a loop into six components: automation, worktree isolation, skills, connectors, sub-agents, and memory.