Loop Engineering
The practice of building a small system that finds work, hands it to an AI agent, checks the result against an objective gate, records what happened, and decides the next step on its own, so the system prompts the agent instead of you.
What It Is
Loop engineering is the design work one floor above the prompt. For two years, getting useful output from a coding agent meant a manual cycle: write a prompt, hand over context, read the result, write the next prompt. You held the tool the entire time. Loop engineering replaces you in that cycle with a small system. The system finds the work, hands it to the agent, checks the result against a standard that can actually fail, records what happened, and decides the next move on its own. You build that system once. From then on, it does the prompting.
The word “loop” is literal. An agent does a slice of the work, checks it against the goal, folds in what it learned, and writes its own next step, repeating until the task is done or the output stops improving. What turns that from a clever demo into an engineering discipline is that every part is deliberate: what triggers it, what it remembers, and above all what is allowed to tell it that the work is not good enough yet.
How It Actually Works
A working loop is built from five primitives, and the craft is choosing the smallest version of each. There is an automation, usually a scheduled task or an event trigger, that fires the loop so it runs without you. There is a skill, a saved instruction file holding the project context the agent would otherwise re-derive from zero every run. There is a state file, a plain record kept outside the conversation that holds what is done and what is next, because the agent forgets and the file does not. There are connectors, typed bridges over MCP that let the loop touch real tools instead of only describing what it would do. And there is a gate: an objective check, owned by a separate verifying subagent, because the model that wrote the work is far too generous grading its own homework.
The gate is the heart of the whole arrangement. Without a real check, a loop is not a loop. It is an agent agreeing with itself on repeat. The gate is the thing that turns repetition into progress, which is why a test, a build, or a type check beats any second agent that merely has an opinion.
Why It Matters Right Now
The leverage point in working with AI moved this year. It used to sit at the prompt: better wording, better context, a better one-shot answer. The models got good enough that the next gain comes from the system that decides what they work on, when, and against what test. The same pattern is escaping engineering. Newer models run the iterate-check-repeat cycle well enough for people who have never opened a terminal, which is why a marketer looping on email drafts and an engineer looping on a test suite are now doing structurally the same thing.
The Cost and the Tradeoff
Loops are not free, and the cost compounds in a way that surprises people. Every pass re-reads the whole context, and that pile grows each time, so ten iterations is not ten prompts but ten prompts that each keep getting bigger. Splitting the work between a maker and a checker, which is what lifts quality, also doubles that bill because two models now read the work. The honest framing lives in agent loop cost: a loop earns its keep only when the task repeats, the verification is automated, your budget can absorb the waste, and the agent has real tools. Miss one condition and the loop costs more than it returns.
How TWO Uses It
TWO treats loop engineering as a discipline to grow into, not a badge to rush. The position is that most operators should not build a loop this month. They should run the four-condition test on their recurring work, watch most tasks fail a condition, and count that as the win, since it spares them a system that would have cost more than it saved. Where a loop does fit, TWO’s rule is to build the smallest one and name the gate before anything else. If you cannot say what objective check is allowed to fail the work, you do not yet have a loop. The deeper TWO concern is what a good loop does to the builder. The faster a loop ships work you did not write, the wider the gap between what your project contains and what you understand, a debt that comes due the day you must debug a system no one has read.
A Concrete Operator Scenario
You run a small agency and every Monday you check three client sites for broken links and stale pricing. It recurs weekly, a script can verify it, the token cost is trivial, and the agent can actually load the pages. Four conditions, all met. So you write one skill describing what to check, point a scheduled task at it, keep a state file of what each site looked like last week, and set the gate to a link checker that returns pass or fail. The first month you read every result by hand to confirm the gate catches what you care about. Only then do you stop watching. Compare that to “summarize this client’s brand voice,” which has no objective gate and where a single careful prompt still wins. Telling those two tasks apart is the entire skill.
Common Misconceptions
The first is that a loop is a smarter prompt. It is not; it is a system with a trigger, a memory, and a gate, and the prompt is the least important part. The second is that more agents mean a better loop. Parallel agents only multiply the bill unless your review capacity can keep up, and review, not typing, is usually the real bottleneck. The third, and the costliest, is that designing the loop means you can stop paying attention. The opposite is true. A loop is a tool for keeping good work, not for surrendering the judgment of what good is, and the moment it touches architecture, auth, payments, or any judgment call, the discipline of drift control and human review stops being optional.