Within a single year, the “thing worth getting right” in agent work has moved up the stack three times. First it was the prompt. Then the context. Then the harness around a single run. The newest level now has a name: loop engineering. The name is worth defining carefully, because the obvious reading of it is wrong.
The ladder is real:
- Prompt engineering is what you say in one turn.
- Context engineering is what information reaches the model’s finite attention budget.
- Harness engineering is what equips a single run: its tools, its memory, its sandbox.
- Loop engineering is what runs the agent on a schedule, spawns helpers, and feeds work back to itself.
What makes the last level different is authorship. You are no longer the component inside the loop that types prompts. You write the loop, and the model becomes a subroutine that the loop calls.
You are no longer prompting the agent. You are writing the program that prompts the agent, and the program decides when the work is done.
That description sounds like a one-line while statement, and that is the trap. The while statement is the easy part. The engineering is everything you build around it so that the loop can be trusted to run with nobody watching.
The guardrails are the work
Three failure modes appear as soon as a loop runs without a human reviewing each turn.
Context overflow. Long sessions fill the window, and the quality of reasoning degrades without any visible signal.
Silent failure. The output is confident and the tools are firing, but nothing is actually changing. This failure is the hardest one to catch.
Cost blowup. A single agent already runs at several times the cost of a chat session. An agent that gets stuck can call a broken tool hundreds of times in a few minutes.
A real loop therefore needs three things that the naive version does not have: a verifier that is not the agent grading its own work, a detector for lack of progress, and a hard budget. A loop that contains nothing capable of saying no is just the model agreeing with itself.
The unit of work
A useful way to think about a loop: it is cron plus a decision-maker. On each tick, the model chooses the next action rather than following a hard-coded branch, and something independent checks whether the goal has actually been met.
None of this makes the model smarter. It makes the system able to run overnight without wasting a large amount of money. That is the shift: the loop has become the unit of work, and the guardrails are what separate engineering a loop from merely running one.