From Prompt Engineering to Loop Engineering

If you spend any time watching this space, you have watched this vocabulary turn over three times in about a year. Prompt engineering, then context engineering, then harness engineering, and now loop engineering.

The usual telling makes that a sequence, each term replacing the last. They are layers, and each one moved a different part of the job from you to the (AI) system. Loop engineering is the first layer where the system decides when to stop. That splits one question into three: is the work finished? is another attempt worth making? or should the task leave the loop and reach a person?

In this post, I’ll explain what each layer does, why each one emerged, and use a customer support workflow to show how loop engineering works in practice.

Four layers of responsibility

Each layer moves a different responsibility from the engineer to the system.

Prompt engineering was the whole game for the first couple of years. Early systems were built around a model call: the application supplied instructions and whatever information the developer included, the model returned an answer, and a person decided whether to accept it, ask again, or stop. The human was the trigger, verifier, memory, and stop condition.

That worked for bounded tasks, but the model could never move faster than the person driving it. Better instructions could improve the answer, but they could not compensate for missing evidence or an inability to interact with the system where the work actually happened.

Context engineering shifted attention from the wording of the prompt to the information available at inference time. Instead of placing every document, account record, log, and policy into the prompt manually, systems could retrieve what the model needed through repositories, search, APIs, databases, and MCP servers.

That solved one bottleneck but exposed another. More context is not the same as the right context, and long-running tasks gradually lose important information through summarisation, stale retrieval, and forgotten decisions. Context gives an agent evidence, but it does not tell the agent whether it has reached the right outcome.

Harness engineering wrapped the model in an execution environment: tools it could call, systems it could modify, tests or policy checks it could run, permissions, sandboxes, project instructions, and persistent state. The environment might be a software repository, a customer support platform, a payment system, or any other operational system where the agent needs to perform real work.

This turned an LLM into an agent capable of taking action, inspecting the result, and iterating within a bounded run. In practice, the harness determines what the agent can see, change, execute, and learn from. What it does not define by itself is the control policy for when the agent should try again, when the outcome should be accepted, or when the task should be escalated.

✨ Loop engineering moves that final responsibility into the system. Instead of waiting for a person after every attempt, the agent observes the current state, acts, measures the outcome, and repeats until it reaches a verified stopping condition, an explicit failure condition, or an escalation boundary.

When Addy Osmani introduced the term in June 2026, Peter Steinberger, the creator of OpenClaw, described it as “designing loops that prompt your agents”, while Boris Cherny, who leads Claude Code at Anthropic, summarised his work even more simply: “My job is to write loops.”

The idea is compelling but it comes with a real trade-off: unattended loops can consume far more compute and tokens than a human-supervised workflow, especially when the system has a weak verifier and repeatedly attempts work that cannot be completed automatically.

These layers are not replacements for one another, instead they stack. Prompt quality still matters, context still determines what the agent knows, and the harness still determines what it can safely do. Loop engineering adds the feedback mechanism that allows the system to decide whether to continue without waiting for a human between every iteration.

Loop engineering isn’t scheduling

One misconception I’ve seen is that loop engineering is just scheduled automation. Run a prompt every hour, every day, or whenever an event arrives, and you have built a loop.

I don’t think that is right. A scheduler or event bus decides when something starts. A loop decides what the result means and whether another action is required.

Scheduled or event-driven automation looks like this:

A feedback loop looks like this:

The key difference is the verifier.

Without one, an agent can execute work but has no reliable way to determine whether that work achieved the intended outcome. It runs because the clock fired or an event arrived, not because the system measured the result and concluded that more work was necessary.

Once an agent can modify real systems and act repeatedly, generation is no longer the main bottleneck but verification is.

An agent can run for hours, make hundreds of changes, call dozens of tools, and satisfy every superficial check you gave it. None of that proves it solved the original problem. If the verifier measures the wrong thing, the loop will optimise for the wrong thing.

Verification can sound abstract, so it is worth making it concrete.

The same workflow, four levels of autonomy

Imagine you are building an AI-powered customer support system that handles refund requests. A customer contacts support because they believe they were charged twice for the same subscription.

The objective remains the same throughout the example: determine what happened, issue a refund if it is justified, update every relevant system, communicate the result to the customer, and leave behind a complete audit trail.

What changes is how much responsibility the system takes on.

At the prompt layer

The system sends the customer’s message to an LLM with carefully written instructions explaining how refund requests should be analysed.

The model only knows what is included in that call. If the prompt does not contain the customer’s billing history, refund policy, subscription status, or previous support conversations, the model cannot reason about them.

It can classify the request, draft a response, or suggest that the customer may be entitled to a refund. It then returns its answer and stops. No investigation has taken place, no external system has changed, and nothing has been verified.

The prompt layer transfers responsibility for generating the next answer.

At the context layer

The system retrieves the customer’s account, payment history, subscription records, refund policy, previous tickets, and relevant billing events before calling the model.

The model is no longer reasoning only from the customer’s description. It can see whether two charges exist, whether they relate to the same subscription period, whether a previous refund has already been issued, and which policy applies to the account.

The recommendation becomes substantially better because the model has evidence, but the system still only produces a recommendation. It cannot issue the refund, update the customer record, or confirm that the problem has been resolved.

The context layer transfers responsibility for finding and assembling evidence.

At the harness layer

The model gains controlled access to the customer support platform and the systems around it.

It can inspect payment transactions, check subscription events, issue refunds within policy limits, request additional information from the customer, update the CRM, send confirmation emails, and write an audit record describing what it did.

The system has moved beyond generating text and into performing work. The harness may also allow the agent to inspect tool results and adjust its actions within the same run.

What the harness does not establish by itself is whether the task should continue after that run or whether the observed result proves that the customer’s problem has been resolved. It makes action and iteration possible, but the completion decision still sits elsewhere.

The harness layer transfers responsibility for execution.

At the loop layer

The workflow becomes goal-driven rather than merely request-driven.

A new support ticket starts the process, but the trigger is not what makes it a loop. The loop begins when the system repeatedly measures the current state and uses that evidence to decide what should happen next.

The agent retrieves the relevant account and payment history, determines whether a duplicate charge exists, checks the applicable refund policy, confirms that no refund has already been issued, and requests additional evidence where necessary.

If the refund is authorised, it submits the transaction, records the payment processor’s response, updates the CRM and billing records, sends the customer an accurate confirmation, and submits the resulting state to an independent verifier.

The verifier does not simply ask whether the ticket has been closed. It checks whether:

• two qualifying charges actually existed;
• the refund amount matches the duplicated charge;
• the refund complied with the applicable policy;
• the payment processor accepted the request and returned a transaction reference;
• the CRM and billing systems contain consistent records;
• the customer received the correct communication;
• no required manual-review condition was bypassed;
• and the workflow did not issue the same refund twice.

If those checks succeed, the ticket closes automatically with an audit trail containing the evidence and actions behind the decision.

If a correctable check fails, the verifier feeds that result back into the loop. The system might retry a failed CRM update, wait for the payment processor to return a definitive status, correct the customer communication, or gather another piece of evidence.

If the system cannot establish the outcome with sufficient confidence, it escalates the case to a human together with the evidence it collected, the actions it attempted, the checks that passed, the checks that failed, and the exact decision that remains unresolved.

The loop layer transfers responsibility for deciding whether to continue, stop, fail, or escalate.

The interesting part is not that the model became smarter, because it did not, but the system around it became more capable.

Each layer transferred another responsibility from the engineer to the software: first generating an answer, then assembling evidence, then performing actions, and finally judging whether the outcome had been achieved. That last transfer, from execution to independent verification, is what turns an automated workflow into a genuine feedback loop.

The verifier is your sensor

The mental model I find most useful comes from control engineering.

An open-loop system looks like this:

A closed-loop system looks like this:

An open-loop controller acts without measuring the result. A closed-loop controller measures the outcome and uses that signal to adjust what happens next.

The difference is not intelligence or planning. The difference is feedback, and more specifically, the quality of the sensor supplying that feedback.

A closed-loop system can never be better than the signal it receives. A thermostat connected to a faulty thermometer does not hesitate or degrade gracefully. It heats the house with complete confidence because every measurement tells it that the room is still cold.

Agentic systems work the same way. Verification turns state into feedback. It measures whether the system achieved the intended outcome and determines what happens next.

If the support verifier only observes whether the ticket status changed to closed, then closing the ticket becomes indistinguishable from resolving the customer’s problem. The system can report success even when the refund failed, the wrong amount was issued, the CRM was not updated, or the customer received an inaccurate response.

A stronger verifier observes the transaction ledger, policy decision, processor response, account state, customer communication, and audit record together. It has a better signal, which gives the loop a better chance of distinguishing real completion from something that merely resembles it.

If the verifier measures the wrong thing, the loop will optimise for the wrong thing, regardless of how capable the model is.

Every stop condition is a target

Suppose your stop condition is simple: keep going until the support ticket is closed.

That sounds like a specification, but there are several ways to satisfy it:

• Confirm the duplicate charge, issue the correct refund, update every system, and notify the customer.
• Reject the request and mark the ticket as resolved.
• Send a generic response and close the conversation.
• Issue a refund without checking whether the customer is eligible.
• Record the refund as successful even though the payment API timed out.
• Ask the customer to open a new ticket, then close the current one.

Every route can produce a closed ticket, but only the first produces the outcome you intended.

The agent does not need to be malicious to choose one of the others. You defined ticket closure as the goal, and the system found a route that satisfied that measurable condition.

Every stop condition should therefore be treated as a target that the system may satisfy in an unintended way. That is not evidence of adversarial intent. It is an ordinary consequence of optimising against a proxy.

The design question is not only what the agent should achieve. You also need to ask how it could satisfy the check without achieving the real outcome, and whether your system has closed that path.

A serious stop condition is usually a conjunction:

This checks the route as well as the destination.

It also means verification cannot reduce to asking a second model whether the outcome looks correct. The verifier needs evidence, and the two main kinds of check have opposite weaknesses.

Deterministic checks are narrow but repeatable. They can confirm that two transaction identifiers differ, the amounts match, the policy threshold was not exceeded, an idempotency key was used, the processor returned a refund reference, and all required fields were populated.

Semantic checks are broader but probabilistic. They can assess whether the customer’s request was interpreted correctly, whether an exception in the policy applies, whether the response actually addresses the complaint, and whether the evidence contains contradictions or unsafe assumptions.

Deterministic checks alone miss meaning. Semantic checks alone are inconsistent, and a second model can share the same blind spots or assumptions as the first. Using a different model for verification may reduce correlated errors, but it does not eliminate them.

Workflows combining structured rules with ambiguous human meaning usually need both. The deterministic layer should run first, and the semantic verifier should read those results alongside the original goal, retrieved evidence, action log, resulting state, and stopping criteria.

The verifier does not need the maker’s internal reasoning. Its job is not to understand why the acting agent believes the work is correct. Its job is to find evidence that the result may not be correct.

The boundary is verifiability, not capability alone

The edge of a loop is not where the model stops being capable. It is where the system stops being able to verify the outcome.

These properties improve at different rates. Model capability is what vendors compete on, and it changes every few months. The verifiability of a problem is a property of the evidence, rules, and systems around that problem, and it improves on nobody’s model release schedule.

Two customer support cases make the difference clear.

The first is a straightforward duplicate payment. The billing system shows two successful charges for the same amount, subscription, customer, and service period. The refund policy explicitly covers duplicate payments, the account owner has been authenticated, and the payment processor can confirm whether the refund completed.

The system can verify what happened, determine the correct action, and confirm the resulting state. That makes the case a strong candidate for automation.

The second case looks similar, but the customer claims they cancelled the subscription during a phone call before the renewal date. The CRM contains no cancellation note, the call recording is unavailable, and the billing records show a valid renewal.

The agent may be capable of producing a recommendation. It can examine the customer’s history, read the policy, assess the tone of the complaint, and estimate which explanation sounds more plausible.

None of that verifies whether the cancellation conversation actually happened.

The problem has not become harder because the model is less capable. It has become harder because the available evidence does not determine the answer. A more intelligent model can produce a more convincing opinion, but it cannot recover a missing fact.

That case has to leave the loop. The correct output is not an automated approval or rejection, but an escalation to someone with the authority to make a discretionary decision.

A useful loop therefore needs at least three terminal states.

1. Success means the result was verified.
2. Failure means the system could not complete an otherwise verifiable task safely, perhaps because a required service remained unavailable or the retry budget was exhausted.
3. Escalation means the task requires evidence, authority, or judgement that the system does not possess and cannot verify.

Escalation is not a failure of autonomy, because it shows that the boundary has been drawn explicitly. A good escalation explains what happened, what evidence was available, what the system attempted, which checks passed, which checks failed, and what decision is now required.

The goal was never to remove people from every decision. It was to remove them from work that can be checked mechanically, so their attention goes to decisions that cannot.

State before autonomy

Any loop that runs more than once needs state outside the model.

For a small prototype, a markdown file may carry the system surprisingly far:

In production, this would normally live in a durable workflow store, event log, ticket system, or database rather than a markdown file. The principle is the same.

Without external state, every run has to reconstruct what previous runs already established. That wastes tokens, loses decisions, and makes the system behave inconsistently from one attempt to the next.

Durable state makes idempotent execution possible. The loop must know whether an event is new, already handled, partially complete, or awaiting confirmation. That matters in any workflow, but it becomes critical when an action has financial consequences.

If a payment API times out after receiving a refund request, the model cannot safely assume the refund failed. Retrying without checking persistent state could issue a second refund. The correct next action is to query the processor using the existing idempotency key or transaction reference, not to begin the task again.

The model forgets between runs. The workflow store, audit log, ticket tracker, and idempotency record do not. Conversation history is useful context, but it is not a system of record.

Design principles

Define the verifier first

Before building the loop, write down the evidence that would prove the task is complete.

For the refund workflow, that evidence might include the original transaction records, applicable policy, refund amount, processor response, idempotency key, resulting account state, customer notification, and audit log. If you cannot describe what would prove completion, you are not ready to automate the task.

Assume the stop condition can be satisfied incorrectly

Ask how the agent could satisfy the check without producing the outcome you intended, then close those paths.

Do not only ask whether the ticket is closed. Ask whether the customer’s problem was resolved correctly, within policy, without inconsistent records or duplicate actions.

Separate generation from judgement

Use a maker and a verifier with different responsibilities, different instructions, and ideally different failure modes.

The maker acts to achieve the goal. The verifier examines the evidence and tries to disprove completion.

The verifier should not simply repeat the maker’s analysis in slightly different words.

Use deterministic and semantic checks together

Deterministic checks provide repeatability, but they miss meaning. Semantic checks can reason about meaning, but they are probabilistic and can be inconsistent.

Each is strong where the other is weak, so serious verification requires both.

Persist state before adding autonomy

Completed work, incomplete actions, failed attempts, idempotency records, blocked cases, and escalation reasons must live outside the model conversation.

Autonomy without durable state is just repeated amnesia.

Put a budget around the loop

Every loop needs explicit limits on attempts, elapsed time, token use, tool calls, and financial exposure.

A loop that cannot verify the result should not consume resources indefinitely in the hope that another attempt will produce certainty.

When the budget is exhausted, the system should fail clearly or escalate with the evidence it has already collected.

Route unverifiable decisions to people

Do not let the loop settle something merely because the model is capable of producing an answer.

A system that reports it cannot verify a customer’s claim is safer than one that converts incomplete evidence into a confident decision.

What no verifier solves

There is one failure mode that this design does not address.

Two teams can operate the same customer support loop and end up in very different places.

One team uses it to automate routine work while continuing to inspect sampled cases, investigate failures, improve policies, understand the integrations, and question whether the verifier is measuring the right outcome. The other team watches the ticket closure rate, accepts green dashboards, and gradually loses contact with how customer problems are being resolved.

From the loop’s point of view, those workflows may be indistinguishable. Both can satisfy the same checks and report the same operational metrics.

Only one of them is compounding into greater capability. The other is accumulating cognitive debt, where the system continues to operate while the organisation’s ability to explain, audit, debug, and change it steadily declines.

That erosion is gradual, largely invisible to dashboards, and easy to miss until a policy changes, a system fails, or a customer presents a case that no longer fits the assumptions encoded in the loop.

A verifier can assess whether an individual workflow satisfied its checks. It cannot ensure that the people responsible for the system still understand those checks, challenge their assumptions, or recognise when the surrounding world has changed.

A loop reporting success is a claim. The verifier is the evidence behind that claim. Whether the evidence is sufficient remains a judgement, and that judgement is still yours.

Loop engineering is worth taking seriously. The components now exist across agent frameworks, workflow engines, policy systems, evaluation tooling, and durable state layers, so you no longer need to assemble every part yourself and maintain it forever.

But the quality of a loop is not measured by how long it can run or how much work it can produce. It is measured by whether it can distinguish between a ticket being closed and a customer’s problem being resolved, and whether it knows when that distinction cannot be established automatically. Those states can look identical on a dashboard, and the verifier is what keeps them apart.