Loop engineering: the skill that replaced prompt engineering

Prompt engineering had a good run. For about two years, the difference between a useful AI feature and a useless one really was down to how you phrased the instruction.

That era is over. Models follow instructions well enough now that phrasing is rarely the bottleneck. What separates an agent that finishes a real task from one that produces impressive-looking nonsense is the structure around the model: what it can see, what it can do, how it finds out whether its last action worked, and when it is allowed to stop. That structure is the loop, and designing it well is the actual discipline.

Anatomy of a loop

Strip any coding agent, research agent or workflow automation down and you get the same four beats:

1. Context — what the model can see this turn.
2. Action — the tool it calls, or the output it produces.
3. Verification — how the system finds out whether that action achieved anything.
4. Feedback — what the result of that check adds to the next turn's context.

Then repeat. Almost every agent failure we have debugged is a defect in one of those four, not in the prompt.

Verification is the whole game

This is the part teams skip, and it is the part that decides everything. An agent without verification is a very confident intern with no manager: it will do something, declare success and move on, and the errors compound silently across turns.

The trick is to prefer machine-checkable ground truth wherever it exists. In software this is a gift, because the ecosystem is full of it:

• Does it compile?
• Do the types check?
• Do the tests pass?
• Does the linter complain?
• Does the actual HTTP request return what it should?

None of these require the model to judge its own work — and self-assessment is exactly what models are worst at. A loop wrapped around a test suite will grind its way to a genuinely working answer. A loop wrapped around "does this look right to you?" will grind its way to a confident wrong one.

If you cannot describe how the agent finds out it was wrong, you do not have a loop. You have a very expensive autocomplete.

Outside code, you build the ground truth yourself: schema validation on structured output, a lookup that confirms the record exists, a second model checking a claim against a retrieved source, or a human approval step for anything expensive to get wrong.

Context engineering: curation, not accumulation

The instinct is to give the model everything. It is the wrong instinct. A context window packed with stale tool output, irrelevant files and the full history of a long session makes the model worse — the signal is diluted, and the important instruction from twelve turns ago is now buried.

Good loops curate aggressively:

• Put stable, reusable content first and volatile content last — it keeps prompt caching working, which is a direct cost saving.
• Summarise or drop old tool results once they have served their purpose.
• Retrieve the two files that matter rather than the twenty that might.
• Keep the task statement close to the action, not buried at the top of a wall of text.

Context is a budget, not a bucket.

Tools are your real API surface

The tools you expose define what the agent can do — and, just as importantly, what you can supervise. A single broad tool (run_any_command) gives maximum capability and minimum control: every action looks identical to your harness, so you cannot gate, log or parallelise intelligently.

Promoting an action to its own tool — send_email, deploy, delete_record — gives you a typed, named thing you can require approval for, render in a UI, audit, or rate-limit. Our rule of thumb: start broad for reach, then promote anything that is hard to reverse into its own explicitly gated tool.

Tool descriptions matter more than people expect, too. Say when to call something, not just what it does. "Call this when the user asks about current pricing" outperforms "gets pricing data" by a wide margin.

Know when to stop

Loops fail in two directions, and both are expensive:

• Never stopping. The agent retries the same failing approach, or politely asks a question nobody is there to answer. Every loop needs an iteration cap, a token budget and a definition of done.
• Stopping too early. The agent announces a plan instead of executing it, or declares victory on the easy half. The fix is usually an explicit completion check: is every part of the task actually finished, with evidence?

Between those, prefer short, checkpointed loops over one heroic run. A loop that verifies every few steps recovers from a wrong turn in minutes. One that verifies only at the end has to throw away an hour.

What this means in practice

When we build an AI feature now, the prompt is maybe a day of the work. The rest is loop design: which tools, what context, what verifies each step, what the budget is, where a human approves, and what happens when a step fails.

That is a genuinely different skill from writing clever instructions — closer to systems engineering than to copywriting. It is also the reason two teams using the identical model get results that are nothing alike.