What Is Loop Engineering? Agent Loops Explained in Plain English

If you have shipped anything with an LLM in the last year, you have probably noticed the same thing I did: the prompt was never the hard part. Getting a good answer once is easy. Getting a good answer reliably, without you sitting there re-prompting it, is the actual job.

That gap is what loop engineering names.

What is loop engineering?

Loop engineering is designing the cycle that prompts the agent, instead of prompting it yourself.

The phrase started circulating around June 2026, once agent harnesses — Claude Code, OpenClaw, Codex and friends — made it obvious that the interesting engineering had moved. You are no longer writing one message and reading one reply. You are building a system that gives a model a goal, lets it act, checks what came back, and decides whether to go again.

The shift is small to describe and large to build: from you prompting the agent, to a system prompting the agent.

Why prompting alone stopped being enough

A prompt is a single shot. It has no memory of what just failed, no way to check its own work, and no opinion about when to give up.

Real tasks fail in ways a single shot cannot recover from:

• The model writes code that does not compile. Nothing in the prompt notices.
• Retrieval pulls three irrelevant documents. The answer is confidently wrong.
• The output is 90% right, and the missing 10% is the part that matters.

You already handle these — by reading the output, spotting the problem, and typing a follow-up. That is you being the loop. Loop engineering is writing that down so the system does it.

The seven parts of a loop

Almost every working agent loop has the same anatomy. When a loop misbehaves, it is nearly always because one of these seven is missing or vague.

Part	The question it answers
Trigger	What starts the cycle?
Goal	What are we trying to reach?
State	What does the next iteration need to know?
Action policy	What is the agent allowed to do?
Evidence	How do we know it worked?
Feedback	What exactly failed?
Stop rule	When does it end?

Write those seven down for your agent before you write any code. If you cannot answer “how do we know it worked” without saying “you read it and see”, you do not have a loop yet — you have a chatbot with extra steps.

A minimal loop, in code

No framework. This is the whole idea in about twenty lines:

def run_loop(task, max_iterations=6, cost_ceiling_usd=2.00):
    state = {"task": task, "attempts": [], "spent": 0.0}

    for i in range(max_iterations):
        # ACTION POLICY — what the agent is allowed to do this turn
        result = agent.act(task=task, history=state["attempts"])
        state["spent"] += result.cost_usd

        # EVIDENCE — machine-checkable, not "looks good to me"
        check = run_tests(result.output)
        if check.passed:
            return result.output                    # STOP RULE: success

        # FEEDBACK — the specific failure, not "try again"
        state["attempts"].append({
            "output": result.output,
            "failure": check.first_error,           # e.g. the failing assertion
        })

        # STOP RULE: cost ceiling
        if state["spent"] >= cost_ceiling_usd:
            raise BudgetExceeded(state)

    # STOP RULE: iteration ceiling
    raise NoConvergence(state)

Three things in there do the real work, and they are the three people skip.

check.first_error, not “it failed.” Feeding back “that was wrong, try again” gives the model nothing to act on. Feeding back the failing assertion gives it a target. The specificity of your feedback sets the ceiling on how well the loop can converge.

Two stop rules, not one. Iterations and cost. An agent that retries six times on a cheap task and an agent that retries six times on an expensive one are very different line items.

state["attempts"] accumulates. Without it, iteration four repeats the mistake from iteration two. This is the single most common bug in hand-rolled loops.

The stop rule is the part everyone gets wrong

If you take one thing from this page, take this: the stop rule is what separates an agent from a runaway bill.

Most loops that misbehave in production do not misbehave because the model is dumb. They misbehave because nobody decided, in advance, what “done” means. So the loop either spins until something crashes, or it stops after a fixed number of turns whether or not the work is finished — which is stopping arbitrarily and calling it a policy.

Good stop rules are boring and specific:

• Tests pass.
• Retrieval confidence clears a threshold.
• The output validates against a schema.
• Six iterations, whichever comes first.
• Two dollars, whichever comes first.

Bad stop rules are “when it looks right”.

A prompt you can steal

The hardest part of the seven is usually evidence, because it forces you to make “good” measurable. This prompt is useful for pinning it down before you build anything:

I'm designing an agent loop for this task: [DESCRIBE THE TASK].

Help me define its seven parts. For each one, push back if my answer is vague:

1. Trigger — what starts the cycle?
2. Goal — what state are we trying to reach, stated so a machine could check it?
3. State — what must survive from one iteration to the next?
4. Action policy — what tools is the agent allowed to call, and what is off limits?
5. Evidence — what machine-checkable signal tells us the goal was met?
   Reject any answer that requires a human to read the output and judge it.
6. Feedback — what exactly do we hand back on failure, so the next attempt is
   better than the last rather than merely different?
7. Stop rule — the success condition, the iteration ceiling, and the cost ceiling.

Then tell me which of the seven is weakest, and what would break because of it.

The last line matters most. A loop fails at its weakest part, and it is rarely the one you were worrying about.

When a loop is the wrong tool

Loops are sequential. That is their strength and their limit.

If your workflow has three reviews that do not read each other’s output, a loop runs them one after another for no reason. Three sequential steps that could have been one parallel step is pure latency — and no amount of loop tuning fixes it, because the problem is the shape of the work, not the quality of the cycle.

That is the point where loop engineering hands off to graph engineering: making the topology explicit so independent work can actually run independently.

The move is additive, not a replacement. You keep the loop you have, make it one node, and split out the step that was holding everything else up.

The bottom line

Loop engineering is the discipline of writing down what you were already doing by hand: set a goal, let the model act, check the result against something real, hand back the specific failure, and know in advance when to stop.

The seven parts are a checklist, not a framework. Most production agents are a while statement with a good stop rule and honest evidence — and they beat elaborate multi-agent systems built on “looks right” every time.

Start with evidence. If you cannot measure done, nothing downstream of it works.