Loop engineering is just the loop you already run, with an agent in your seat

Not a new invention

Every few weeks a term shows up that makes something you already do sound like it needs to be learned from scratch. Loop engineering is the current one, complete with diagrams full of boxes and arrows. Strip the diagram away and here's what's underneath: you write a prompt, read what came back, don't love it, tweak the prompt, try again. That's a loop. You've been running it by hand since your first week with Claude. Loop engineering is just the observation that you can put an agent in your own seat and let it run that same loop without you sitting there refreshing the screen.

That's the whole idea. It isn't a new discipline. It's automating a habit you already have.

The four parts worth naming

A loop has four moving pieces. A trigger starts the cycle, a schedule, a webhook, someone typing go. Execution is the actual work, and the mistake people make here is doing it loosely instead of tying it to a skill, so the agent does the same thing the same way on run four as it did on run one, instead of improvising a slightly different approach each time. Third, and this is the one that matters most, a goal and a way to verify it. Not a sense that it looked okay. A check someone who wasn't in the room could run and reach the same answer you did. And fourth, output and memory: somewhere the loop writes down what happened, so the next run, or the next loop looking back at this one, has something to learn from instead of starting blind.

We run roughly this shape every night. A backlog board, a builder agent that picks up a task and does the work, a QA reviewer, a release judge before anything ships. Trigger, execution tied to specific skills, a verification step with a real bar to clear, and a log the next run can read. None of that was inevitable. We built it in that order because the first version was missing every one of these, and reality found each gap for us.

What keeps it from wasting a night

A stop condition, first. Ours is either the acceptance criteria are met or the loop hits a run cap, because a stuck agent doesn't know it's stuck and will keep going until something outside it says no. We've had a loop spend a whole night producing nothing useful because the cap wasn't tight enough. Then context management. Every run adds files, logs, errors to what the agent is carrying, and by run eight it can forget what it was actually fixing and start touching code that was never broken. Keep the latest error, keep the file in question, compress everything older into a line or two, and restate the goal at the top of every cycle. And error recovery. A command that fails mid-run isn't the loop breaking. It's information. Feed it back and let the agent decide what to do with it, the way you'd tell a colleague the build failed and hand them the message.

The one idea worth the whole post

The agent doing the work must never be the agent grading the work. Give the same process both jobs and it will eventually find the easiest path to a pass, and that path is usually weakening the test, not fixing the bug. It's why our builder never merges its own work. A separate QA pass and a separate release judge look at what comes out, and neither can touch the thing they're grading. Small structural decision. It's the difference between a loop that improves your work and one that quietly learns to lie to you.

Before you build one

Most posts on this skip the actual question. A loop is worth building only when you can say, in one sentence, how you'd know it succeeded, and have two different people agree on the answer. Make the failing tests pass clears that bar easily. Write a good post every morning doesn't, because good there is a feeling, not a measurement, and a loop without a real verifier isn't improving anything. It's producing more of whatever it produced last time, dressed up in the confidence of a process that looks rigorous. If you can't write the check, don't build the loop. Write the prompt by hand and call it what it is.

Prompting scales you. A loop scales one agent on one well-defined job, past the point you'd want to sit and watch it. A graph, which is the next thing everyone will start posting about, scales a whole team of agents at once. We're not there in any way worth writing about yet. One loop that reliably knows when it's done beats an org chart of agents that don't.