What is loop engineering?
The practice of designing the system that prompts an AI agent instead of prompting it yourself: a loop that gathers context, acts, verifies the result and repeats until the goal is met.
Loop engineering is the practice of replacing yourself as the person who prompts the agent. You design the system that does it instead — the loop that gathers context, takes action, verifies the work and repeats, plus the memory that carries what one pass learned into the next.
The term took hold in mid-2026, when the people running coding agents all day noticed the same shift: they had stopped prompting. They had loops running that prompt for them — scheduled tasks that triage work, agents acting in parallel workspaces, and separate verifier agents checking the results, precisely so the agent doing the work never gets to grade itself.
The engineer's job moves one level up. Prompt engineering asks: how do I word this message? Loop engineering asks: what system repeats until this goal is met? What you optimise is no longer a sentence — it is the evaluation criteria, the feedback each failed pass sends back, and the condition that ends the loop.
The honest caveat: a loop can run without you, but it cannot generate its own ground truth. Somebody still has to define what “passed” means, which dependencies matter, and where the loop must stop. That specification work is graph engineering — the loop is the engine, the graph is the drawing it builds from.
The four beats of every loop
On the nodalo canvas a loop is one honest backward edge — and these four questions, answered in writing.
Generate
The pass that makes the thing. One node, everything it needs attached to it.
Evaluate
Decides what “good” means — a checklist, a test, a second model, a human. Criteria left unwritten are how quality drifts.
Feed back
The backward edge carries what the last pass learned. Without it you don't have a loop — you have a retry.
Terminate
Pass, run out of attempts, or escalate to a human. A loop without a stop is a bug with a billing cycle.
From prompt engineering
to graph engineering
Each stage wraps the one before it. Wording still matters inside a node, nodes still matter inside a loop — and the loop reads the graph.
| Practice | Unit of work | What you optimise | Fails when |
|---|---|---|---|
| Prompt engineering | One message | Wording, role, format, examples | The task has more than a handful of moving parts |
| Context engineering | The window | What the model sees on each call — retrieved, cut, ordered | The pieces are present but their relationships are not |
| Loop engineering | The running system | Who prompts, what verifies, when to retry, when to stop | Nobody wrote down what “done” means |
| Graph engineering | The specification | Nodes, dependencies, criteria and attached evidence | You skip it and hand the loop a paragraph instead |
Design the loop before you run it
You already run loops — generate, read, wince, adjust, run again. You just run them by hand, from memory, and call it iterating. A loop that lives in your head can't be shared, measured or handed to an agent. A drawn one can. On the canvas the cycle is a backward edge, the evaluator node carries the pass criteria and the stop condition in its contract, and a decision node's outgoing labels are the branch conditions.
To be precise: nodalo is where the loop is designed, not the runtime that spins it. You draw the cycle, name the criteria, set the stop — the compiled specification hands all of it to whatever does the running, and the handoff takes it there in one move.
Draw the loop you keep running by hand
Open the canvas. Close the cycle with one backward edge — and write down, once, what “done” means.