When humans still needed to sit at keyboards and manually guide agents line by line, the core skill was writing prompts. Today, agents can receive a goal and execute it autonomously—now, the new core skill is loop engineering.

Author: CyrilXBT

Article compiled and sourced from: ME News

In June 2026, within a week, three individuals independently reached the same conclusion.

OpenClaw’s developer, Peter Steinberger, publicly stated that people should stop directly prompting programming agents and instead design loop systems that automatically issue instructions to the agents.

Around the same time, Boris Cherny, head of Anthropic Claude Code, also stated that he no longer directly inputs prompts into Claude. Instead, he runs a series of loops that automatically invoke Claude and determine the next steps, while his real work lies in writing and designing these loops.

A few days later, Google engineer Addy Osmani systematically summarized this practice and gave it a name:

Loop Engineering, circular engineering.

They didn’t invent this way of working out of thin air—they simply named a change that had already been quietly taking place.

Prior to this, the underlying tools had crossed a critical threshold: programming agents began to be capable of completing real tasks without human supervision; the cost of automated scheduling had dropped low enough that repeatedly scheduling a task no longer seemed wasteful; and the cost of a single agent run had fallen to a new level—where it might be cheaper to let the agent attempt a task five times than to spend significant time carefully planning it once.

This is exactly why this roadmap exists.

When humans still needed to sit at keyboards and manually guide agents line by line, the core skill was writing prompts. Today, agents can receive a goal and execute it autonomously—now, the new core skill is loop engineering.

Below is a complete 20-step path from a prompt operator to a system designer. Steps must be followed in sequence, as the order between steps is often more important than any single step individually.

Cycle engineering is not a single skill that you either master or don't master, but rather a layered stack of abilities. Each layer depends on the strength of the foundation beneath it.

For example, building the automated scheduling trigger at step 14 before establishing the actual stop condition at step 10 will only result in a system that automatically wastes funds without supervision. Previously, it at least only wasted resources while you were watching the screen; now, it can continuously burn money on its own.

Similarly, if you establish the persistent memory layer in Step 11 before reliably verifying Steps 6 and 7, you may faithfully store the accumulated experience from a reviewer that is too permissive and continually allows incorrect results.

This not only fails to help the system improve but also causes erroneous experiences to accumulate, turning the memory layer from "temporarily useless" into "actively harmful."

Therefore, skipping certain steps isn't just about failing to implement a feature—it's far more serious: you're building impressive, advanced capabilities on a foundation that simply cannot support them, and often don't discover the problems until the system is already scaled and causing real-world consequences.

Phase One: Complete the Mindset Shift Step 1: Acknowledge that the bottleneck lies with you, not the model.

The first real step doesn't involve any technology.

You must admit that, in the current workflow, the limiting factor for efficiency is often no longer the model's capability, but rather your continued involvement in the loop.

Every time you sit at your computer waiting for the model to respond, read the output, and then enter the next command, you become the slowest part of the entire system.

The model can execute, validate, and retry, and these operations are much faster than a human could supervise step by step.

This step has no corresponding prompt—it is a cognitive decision.

Until you truly accept this, all subsequent steps will seem like unnecessary extra work rather than what they truly are—removing the biggest efficiency bottleneck in the system.

When a model produces incorrect output, the most natural response is often to add another rule to the original prompt.

Months later, this approach creates a wall of rules: dense, conflicting, and too long for the model to process all requirements simultaneously in its working memory.

Ultimately, models often only perform pattern matching based on the most recent or most prominent content, inadvertently ignoring other rules.

Circular engineering has completely transformed this approach.

When an issue arises, instead of simply adding a new requirement to the prompt, you add a new component to the system, such as:

• Add an independent verification step;
• Add a memory file;
• Add a scheduled trigger;
• Add a structured review process.

As the capabilities of external systems continue to improve, prompts should become shorter, not longer.

Regardless of the specific task's domain, each iteration in the loop can be broken down into five fundamental actions:

Identify, hand over, verify, persist, schedule.

Discovery

Figure out what the actual task needs to be accomplished.

Handoff

Assign the task to the model, agent, or tool responsible for execution.

Verification

Verify whether the results are correct according to actual standards.

Persistence

Record what happened and what was learned during this run to ensure the experience is not lost in the next run.

Scheduling

Decide when this process should run again.

Most people’s existing workflows explicitly include only the first two actions: identifying tasks and handing them off, typically completed manually within chat windows.

The other three actions either do not exist at all or are hidden within the human brain itself.

The core of circular engineering is to explicitly define all five actions and automate them as much as possible.

Before setting up the system, choose a task you are already performing repeatedly and can clearly define quality standards for.

Don't choose the most difficult problems or entirely unprecedented innovation tasks.

The first candidate task must satisfy three conditions:

1. You need to repeat it;
2. It has clear, documented standards;
3. It has a clearly recognizable "completed" status.

In other words, a colleague reviewing the results should be able to quickly determine whether the task was completed correctly.

This restriction is more important than it appears.

If a task lacks clear completion criteria, a true verification process cannot be established. And a cycle without a reliable verification mechanism is not a true cycle—it is merely an unsupervised guess.

Phase Two: Building the First Loop Step 5: Write “Completion Definition” first, then write the prompt

This is the step most people tend to skip, yet it’s crucial for determining whether the system will function properly afterward.

Before writing any instructions for the agent, first clearly and naturally describe what the correct result should look like.

You need specific, verifiable standards, not vague quality judgments like "feels good" or "looks professional."

You can use the following template:

Task name: [Task name]

Definition of Done (DoD):

• [Specific, verifiable standard 1]
• [Specific, verifiable standard 2]
• [Specific, verifiable standard 3]

Even if the final output appears complete and carefully polished, the task cannot be considered finished if any of the above elements are missing.

If you cannot fill out this template for your currently selected task, return to Step 4 and choose a different task better suited for building a loop.

This is the most important architectural decision in all cyclic systems.

The role responsible for generating results must be separate from the role responsible for reviewing results.

The reason is that when a model reviews its own output immediately after generating it, it tends to defend the recently produced answer rather than critically examining potential issues within it.

In a proper cycle, there should be at least two independent roles:

Builder

Builders have some creative freedom and are responsible for generating the first version of the result.

Judge

The reviewer receives the builder's output and the Definition of Done established in Step 5, and evaluates whether the result meets these criteria.

Ideally, reviewers should also have access to independent evidence that builders cannot access, such as:

• Test suite;
• Original data;
• Real-time data;
• Authoritative database;
• Original task brief.

This ensures that reviewers' judgments are based on actual evidence, rather than generating another subjective opinion using the same reasoning as the builder.

If the reviewer can only see the builder's output, it can at most judge whether the result "appears coherent."

It cannot determine whether the result is truly correct.

Therefore, reviewers must have verifiable objective grounds, known as Ground Truth. Depending on the context, this can be understood as "baseline facts," "authentic data," or "authoritative reference."

The objective criteria vary depending on the task.

Programming task

The objective basis is the test suite and the actual output generated by the running code.

Content creation task

The objective basis consists of the original materials and content briefs. Reviewers must compare the original materials side by side with the generated draft.

Research task

Objective evidence consists of the original documents, papers, datasets, or authoritative sources explicitly required for the task.

If you cannot clearly state what reviewers should base their checks on, then your cycle lacks a true verification mechanism, no matter how confident the reviewers' wording may sound.

The builder's output and the reviewer's conclusion must both follow a clearly defined structure, rather than being free-flowing natural language.

Otherwise, the next manager won't have stable, reliable information to make decisions and route transactions.

Builders can use the following output format:

Builder output:

• Final deliverable;
• Degree of confidence in the result;
• Known uncertainty.

Reviewers may use the following output format:

Review conclusion:

• PASS: Approved;
• FAIL: Failure;
• NEEDS REVISION: Requires revision;
• Specific issues identified;
• The objective criteria or original evidence used for this inspection.

Before enabling automated scheduling and automatic retries, manually run the full "Builder—Reviewer" process once yourself.

Carefully read the reviewer's assessment and ask yourself:

• Do you agree with its conclusion?
• Has it ever let through a result you knew was wrong?
• Did it incorrectly reject a valid result?

If a reviewer approves a result you know is incorrect, or rejects a result that is actually fine, first correct the objective criteria or complete the standards before continuing to build the system.

Automating an incorrect verification step will only cause the system to produce erroneous results faster.

To make the five steps above more concrete, we can examine a common task: transforming raw source material into a complete article.

Step 5: Define Completion

The completion criteria for this task can be:

• Each fact in the draft can be traced back to a clear source in the original material;
• The draft meets all specific requirements in the brief, including length, tone, and structure;
• The core argument of the original text has been clearly preserved without being diluted by meaningless filler content.

Step 6: Builder generates draft

The builder receives the raw materials and content brief, then generates a draft version.

At the same time, it must clearly list the uncertainties present during the writing process, such as:

• Whether a certain number actually appears in the original source;
• Is the conclusion explicitly stated in the original text, or is it inferred by the model?
• Whether a fact lacks sufficient sourcing.

Step 7: Reviewer checks against the original text

Reviewers receive both the draft and the original materials, not just the draft.

It must evaluate each of the three criteria in the definition separately and provide a pass or fail result for each criterion individually, rather than compressing all dimensions into a single ambiguous overall score.

Combining three different standards into one overall judgment obscures which specific dimension is having an issue. This is the most common reason why many originally functional cycles gradually lose their feedback value.

Step 8: Structured Handover

The reviewer's conclusion should be a structured object, not a paragraph of natural language with qualifying phrases.

It must output three clear pass or fail results, with specific reasons provided for each failure.

Step 9: Manually Verify the Review Mechanism

Manually executing the full process before the system runs automatically can help you determine whether reviewers are too lenient or too strict.

Overly lenient reviewers may overlook fabricated data simply because the article is well-written.

An overly strict reviewer might incorrectly reject a qualified article due to a personal stylistic preference never mentioned in the brief.

Both of these issues are very common when setting up for the first time.

Discovering them after the system has run unattended for 50 times is far more expensive than resolving the issues during the initial manual testing.

Phase Three: Fill in the Missing Components of the Loop Step 10: Set Up the Manager and the True Stopping Condition

The Manager reads the reviewers' judgments and determines the next steps.

Stop conditions should also reside within the manager and must be written as explicit hard logic, not as soft instructions that a model can circumvent through self-interpretation.

For example:

Stop condition:

• Maximum number of modifications: 3;
• When the third review still fails, submit the complete history for human handling without initiating a fourth revision;
• Quality Standard: Each item defined must show PASS;
• Budget cap: If the task cost exceeds X or the runtime exceeds Y, the task must be immediately stopped regardless of its current status.

A loop without a true stopping condition is not a system—it's a liability waiting to expose risk.

Why are soft instructions like "stop when the result is good enough" unreliable?

Because it's just a suggestion.

When a model has been modified multiple times in a row without passing, it may convince itself that "this version is close enough to the standard" in order to provide a seemingly satisfactory conclusion to the task, thereby lowering its own evaluation threshold.

In contrast, issues of this kind do not arise with iterations mechanically checked by code or explicit rules that managers cannot bypass through reasoning.

If a cycle starts from zero each time it runs, it won't remember what it learned during the previous run.

Therefore, a simple persistence layer needs to be added.

You can create a file for each new genuine experience and summarize it in one sentence at the top of the file:

• What did you learn?
• What was corrected;
• Why this experience is important.

The key principle is: only record new knowledge that has not been saved elsewhere.

Repeated memory is not knowledge, but noise.

To ensure the persistence mechanism remains effective over the long term, you must exercise restraint during writes.

It’s easy to feel the urge to record every operational detail, but this merely recreates the “bloated prompt” issue mentioned in Step 2—except now, the bloat shifts from prompts to memory folders.

The truly valuable experiences to document are those that, if forgotten, would require significant time to rediscover—not merely routine operations that went as expected.

Simply adding a persistence mechanism will eventually lead to problems similar to those caused by excessively long prompts.

Over time, the system accumulates dozens of files, many of which contain only slightly different formulations of the same issue.

Therefore, memory files should be organized on a fixed schedule. Performing this task once a week is typically a reasonable frequency.

The process includes:

• Review existing memory;
• Merge duplicate content;
• Condense multiple similar experiences into one clearer principle;
• Remove content that has been proven incorrect or outdated.

The goal is not to accumulate more and more documents, but to gain fewer, higher-density insights.

Many people skip this step entirely because it doesn’t immediately grant any visible new capabilities—it’s only about preventing future issues.

Precisely because it lacks immediate feedback, it should be deliberately scheduled rather than postponed until someone realizes their memory folder has become unmanageable.

In reality, this "I'll get around to it later" task rarely ever happens until system performance begins to degrade due to numerous conflicting, outdated, and partially relevant memories competing for context window space.

At the start of each new task, have the loop first scan the one-sentence summary in the memory file to determine which experiences are truly relevant to the current task, and load only those relevant details.

At the same time, the system should be explicitly required to state directly that there are no applicable experiences if no existing memory is relevant to the current task.

Don't force past experiences onto a completely new problem just because a memory system already exists.

Next, determine when this cycle should run automatically without manual initiation.

Trigger methods may include:

• Cron scheduled task;
• File change listener;
• Calendar-based periodic trigger;
• Triggered when an external event or state changes.

This step transforms a system that can only be manually initiated into one that continues running while you sleep.

Ironically, this is often the easiest step on the entire checklist, yet many people still delay implementing it—even after completing all the other components.

Phase Four: Scale and Enhance Reliability Step 15: Stress-test it before entering a true trust loop

Before using a loop for any critical task, proactively test for four failure modes.

Test One: An Impossible Task

Provide the system with a truly unsolvable task version to confirm that the manager can exit according to the stop conditions rather than entering an infinite loop.

If a loop has only been tested on tasks it can successfully complete, it has never proven its ability to fail gracefully.

Test 2: Results that appear reasonable but are actually incorrect

Provide the reviewer with an output that you know contains a subtle error.

This result should read very smoothly but contain a fact or logical error that you intentionally embedded.

Observe whether reviewers can identify issues, rather than approving content simply because it sounds reasonable.

Test 3: Builders and reviewers share model blind spots

If the builder and reviewer use the same underlying model, they can intentionally introduce a common error that the model frequently makes, to observe whether the reviewer will overlook it.

If the reviewer and the builder share the same blind spots, the role separation designed in Step 6 loses its meaning.

Test 4: Calculate the operational cost under worst-case scenarios

Calculate the maximum cost this loop could incur under the worst-case scenario, using the most expensive model invocation, the maximum number of modifications, and the longest possible output within reasonable limits.

Then honestly ask yourself:

Would you feel uneasy if this number appeared on a real bill?

Completing these four tests before processing critical tasks in the trust cycle can identify the vast majority of potential issues in advance.

Otherwise, these issues are likely to first appear to customers or managers—or directly show up on your bill—rather than during a test you control.

Once the loop is running stably, don’t have all roles use the same model you favor.

Different roles within the cycle have varying requirements for model capabilities.

Builder

Builders should typically use the most powerful models.

Because it handles the primary complex reasoning and content generation tasks. Using an underpowered model here would reduce the quality of the first draft, potentially requiring more revision rounds afterward.

In the end, the cost of correcting a low-quality draft may exceed the cost of using a more powerful model from the start.

Reviewer

Reviewers are responsible for conducting checks based on clear criteria and typically do not require strong creative skills.

When the criteria are sufficiently specific, a smaller, lower-cost, and faster model can often reliably complete the review task.

A small model, if guided by a highly specific checklist, can achieve stability approaching that of a large model, while significantly reducing cost and latency.

Manager

The manager routes requests according to pre-defined rules and rarely needs to use the most expensive model.

Its task is to execute predefined logic, not to engage in open-ended reasoning.

In addition, regardless of the performance of builders and reviewers, the manager runs at least once in each iteration, so its per-call cost is particularly noteworthy.

A reasonable layered configuration is typically:

• The strong model is responsible for construction;
• Affordable and stable models handle routine reviews;
• Low-cost models or rule-based programs handle routing and management.

Significant cost optimization in a circular system typically comes from this model-role alignment.

Many people believe that controlling costs means reducing the number of cycles or revisions. In fact, a more effective approach is to align the model's cost with the actual difficulty of each role in the cycle.

After the first cycle succeeds, it's easy to immediately try building multiple cycles simultaneously to process five different tasks in parallel.

Even though the current architecture can already support this expansion, you should restrain this impulse.

You should let the first loop run stably for long enough until you no longer need to closely monitor every output.

This does not mean that a demonstration happened to succeed when everyone was paying close attention, but rather that it continues to pass manual inspections after a period of real-world operation.

Only after reaching this state should you begin building the second cycle.

The second loop should best handle a task that is clearly different from the first loop.

This is the only way to verify whether the underlying architecture truly has generalizability, rather than merely becoming increasingly fine-tuned for the same task.

After running multiple loops simultaneously, you need to establish a unified monitoring view to centrally track the costs and trigger events of all loops, rather than examining each loop individually.

Individually, a cycle of task budgets may be entirely reasonable.

However, if all ten cycles operate within their respective budgets, their combined cost may still reach an unexpectedly high level.

Because the individual data for each cycle appears normal, this risk is often not detected until the consolidated statement is generated.

In addition to successfully completed tasks, each trigger of a stop condition must be specifically recorded.

If a particular loop frequently reaches the maximum number of modifications, while other loops rarely encounter this, the signal it may be sending is not that "this task is particularly difficult," but rather:

• The evaluation criteria are set unreasonably;
• The reviewer is too strict, causing any result to fail;
• The system checked the objective basis for the error;
• Defining it itself presents problems.

If only successful outcomes are tracked and each manual upgrade is treated as an isolated, unrelated event, this pattern at the design level will go unnoticed.

Stage Five: Become a True System Designer Step 19: Stop Measuring Yourself by the Number of Prompts You’ve Written

The most obvious sign that a mindset shift has truly taken place is that the metrics you pay attention to in your daily life have changed.

The prompt operator is concerned with:

• How many effective prompts did you write today?
• Which prompt works best?
• How to craft prompts more skillfully.

System designers are concerned with:

• How many cycles are currently running;
• How reliable is each cycle?
• How much time did the system free up for itself?
• Which tasks no longer require human supervision?

If you still measure your productivity by the number of prompts you input, then the mindset shift required in Step 1 has not truly been achieved, regardless of how many loops have been technically established.

The final step is no longer entirely about your own system.

It is used to verify that you truly understand this method.

You need to try explaining five basic actions to someone without relying on complex terminology:

Identify, hand over, verify, persist, schedule.

If you can guide someone else to build their first cycle using only these five actions and the preceding steps, you have achieved the true transformation outlined in this roadmap.

You are no longer the one stuck inside the loop, continuously inputting the next instruction.

You have become the person standing outside the cycle, designing the system and observing it run on its own.

The four costs that quietly accumulate after skipping steps

It is necessary to include a warning at the end of the article.

Skipping steps in this roadmap often does not immediately cause system failure.

Its failure is often quiet and difficult to detect for a long time, until the issues have accumulated to a significant degree.

When you skip steps 6 and 7, failing to establish truly independent reviewers and provide reliable objective evidence, debt verification begins to accumulate.

The loop appears to still be functioning normally because the generated results "look good enough."

You only realize that the system never truly determined whether the results were correct until an error accumulated over dozens of runs and was finally discovered.

Understanding may degrade when you skip step 20.

You're still running the loop you built yourself, but you can no longer clearly explain why each component exists, nor can you effectively debug when the system fails.

The reason is that you've never truly internalized the logic behind this architecture.

Cognitive surrender occurs if Step 1 was never truly completed.

Even though the verification system has proven its reliability through long-term operation, you still manually review each output out of habit.

This behavior appears cautious but actually undermines the entire purpose of building the system.

Skipping step 10, without setting a proper termination condition for the loop, could lead to uncontrolled token consumption and calling costs.

You often won’t realize there’s an issue until the final bill arrives, revealing that the cycle has generated a large number of ineffective calls.

All of the above costs can be avoided.

The way to avoid them is always the same discipline:

Build in order, do not skip steps that may seem less impressive.

What often truly works are precisely the most mundane parts:

• Clear completion definition;
• Reliable stop condition;
• Verifiable objective evidence;
• Independent review mechanism.

In comparison, the more appealing aspects—clever prompts, complex system architecture diagrams—are far less important than people imagine.

What truly determines the quality of the system is whether the system you've built knows:

• When are you right?
• When are you wrong;
• When must you stop?

That is the entire difference between a prompt operator and a system designer.

The difference lies not in who is smarter or who can write more elaborate prompts.

The real difference lies in whether you have enough discipline to carefully build the dull, easily skipped parts that truly determine the system's reliability.