Loop Engineering

Bound the reason → act → observe cycle: name every exit, cap every budget, and detect a loop that has stopped learning.

Agentic Engineering · Intermediate · ~6 min

In plain English

Deciding when the agent is allowed to stop. Not 'when it feels done' — a hard step count, a token budget, and a rule for what to do when it runs out.

Why it's worth your time

Almost every agent incident — runaway cost, infinite retries, a task that never finishes — is a missing loop bound.

If you remember three things

Every loop needs a step cap, a token budget and an exit report
Cost is roughly quadratic in loop length if you resend everything
Stopping honestly beats continuing hopefully

Overview

An agent is a loop, not a prompt. It reasons about what it is missing, takes one action, observes the result, and goes round again — and nothing about that path is scripted. That freedom is exactly why the loop is the first thing you must engineer: an unbounded loop is an unbounded bill, and a loop with no progress check will happily spend your entire budget re-running the same failing search. Loop engineering is four concrete decisions: what one lap is allowed to do, which conditions terminate it, what hard ceilings sit around it (iterations, wall-clock, spend), and how you detect that the loop is spinning rather than working. Everything else in agent engineering assumes this is already solid.

How it works

Reason → Act → Observe One lap = one decision. The model chooses the action; the runtime executes it and feeds the observation back.
One lap, three rows Laps append to an immutable trace. That trace is the debugger, the audit log, and the eval input.
Termination conditions Goal satisfied, no tool call emitted, stop marker seen, budget exhausted, no progress — enumerate them explicitly.
Max-iteration budget Cap laps, wall-clock and spend independently. Cost grows super-linearly because the whole context is re-sent each lap.
Escaping infinite loops Fingerprint (action, args, result). A repeat means the loop is not learning — break out, re-plan, or escalate.

In an interview

An agent is a loop: reason about what's missing, take one action, observe, repeat. Loop engineering is bounding it. I enumerate the termination conditions explicitly — goal satisfied, no tool call emitted, stop marker seen — and put hard ceilings on iterations, wall-clock and spend, because the whole context is re-sent every lap so cost grows super-linearly. Then I add a no-progress detector: hash the action, its arguments and its result, and if that fingerprint repeats, break out and re-plan or escalate rather than burning the rest of the budget. When a ceiling fires I return the partial result and the reason, never a silent hang.

Production defaults

Steps: 8–12 tool calls. An agent that hasn't finished by 12 usually never will
Tokens: a hard budget enforced in code, not requested in the prompt
Repeats: same tool + same arguments twice → break out, don't try again
Exit: report what was achieved and what wasn't. A partial answer with a clear boundary beats silence

What breaks

Runaway cost incident — No token budget. Prompts can't enforce limits — only code can.
Agent gives up too early on genuinely long tasks — Wrong shape, not wrong cap. Decompose into sub-tasks with their own budgets.

Watch it explained

AI agents explained: Build your first agent in 8 minutes — Google Cloud Tech, 8:29