Loop Engineering, Chapter 1: The Anatomy of an Agentic Loop

This is the first post in a series walking through my new book Loop Engineering: Scaling and Governing Agentic AI. Over the next eight days I will take one chapter a day. We start where every agentic system starts — with a single loop, and the question of what it is actually made of.

The most valuable skill in working with language models keeps moving. For a while the leverage was in the wording, and we called it prompt engineering. Then it moved to the material you put in front of the model — the retrieved passages, the schemas, the history — and we called that context engineering. Both are fundamentally about one turn: you compose an input, the model produces an output, and you are done. This book is about the shift that comes after both, where the leverage moves from any single exchange to the design of the whole system that surrounds the model. I call it loop engineering, and Chapter 1 is about the object at its center.

A loop, in the sense the book uses the word, is a system that cycles through four moves until a condition is met: it plans, it acts, it observes, and it revises. The model plans by deciding what to do next given everything it knows so far. It acts by taking a concrete step — running a command, calling an API, writing a file. It observes by reading the result of that action, which is new information that did not exist a moment ago. And it revises by feeding that observation into the next plan. This is the ReAct pattern, and the reason it matters is that the power lives in the cycle, not in any single step.

A loop is not a chain

It is worth being precise about the distinction, because getting it wrong is the most common early mistake. A prompt chain — a fixed sequence of steps, A then B then C — is not a loop, even when each step calls a model. In a chain the path is decided before you start. A loop makes no such commitment: at each iteration it asks what the situation now requires, and the answer can be different every time. Try again, try something else, take a new branch, or stop. This is why a loop can handle a task whose shape is not known in advance, and a chain cannot. The chain assumes you already understood the problem well enough to lay out the steps. The loop assumes you did not, and builds the understanding as it goes.

Consider asking a model to fix a failing test suite. You do not know what the fix is, and neither does the model, until it has tried something and seen what happened. The real work is iterative: form a hypothesis, change some code, run the tests, read the new failures, revise, and repeat until the suite is green. No amount of prompt cleverness collapses that into one shot, because the information needed to finish does not exist until the work is partly done.

The discipline of knowing when to stop

The other property that defines a loop is the stopping condition, and it is the one most easily neglected. A loop that does not know when it is finished is not an agent; it is an expensive way to burn tokens. The craft begins with turning a fuzzy objective — “make this better” — into an explicit, checkable condition the system can evaluate without a human in the room. “All tests pass” is a stopping condition. “The output validates against this schema” is a stopping condition. “Make it better” is not, because nothing in the world can tell the loop whether it has succeeded. The chapter walks through the hard guards that sit in front of that success check — budget caps, step caps, and a repetition guard that halts a loop spinning on the same useless action — because a loop is only as trustworthy as its definition of done.

Tomorrow: if a loop is the engine, what are the parts? Chapter 2 lays out the six primitives from which durable, unattended systems are actually assembled.