Definition
An agent loop is the cycle a model runs to accomplish a task: plan the next step, call a tool, observe the result, decide what to do next, repeat until the task is done or a stopping condition is hit. Loop engineering is the discipline of designing that cycle deliberately — instead of letting it emerge implicitly from however the agent framework happens to structure tool calls.
In practice, loop engineering answers questions like: What counts as "done"? How many steps is too many? What happens when a tool call fails — retry, back off, or escalate to a human? What state carries across steps, and what gets dropped? These are systems-design questions, not prompting questions, and they determine whether an agent loop finishes real work or burns budget in circles.
The anatomy of an agent loop
Every agent loop, regardless of framework, is built from the same four moving parts:
| Stage | What it decides | Where loop engineering intervenes |
|---|---|---|
| Plan | What's the next action given the goal and current state? | Bounding how much context and history the planning step sees |
| Call | Which tool to invoke, with what arguments | Constraining the tool surface and validating arguments before execution |
| Observe | What did the tool return, and what does it mean for the goal? | Deciding how much of the raw result to keep vs. summarize |
| Repeat / Stop | Is the task done, stuck, or does it need another step? | Termination conditions, max-step limits, and escalation to a human |
A single chat completion only exercises the first two stages once. What makes something an agent loop — and what makes loop engineering necessary — is repeating this cycle without a human re-prompting each turn.
One-off tasks vs standing loops
Most agent use today is a one-off task: delegate, get a result, done. The harder — and increasingly common — case is the standing loop: an agent that runs continuously, like a cron job, monitoring an inbox, watching for latency spikes, or triaging incoming tickets around the clock. We covered this split in detail in agent loops, tokenomics, and the harness, drawing on how Perplexity's heaviest users structure their agent workflows.
Standing loops need far more deliberate loop engineering than one-off tasks: they run unattended, they accumulate state across many more steps, and a design flaw that costs a few extra tokens in a one-off task can cost thousands of dollars over a week of continuous operation.
Loop engineering vs harness, prompt, and context engineering
These four disciplines are complementary layers of the same system, not competing terms. Each answers a different question about how an agent operates:
| Discipline | Question it answers | Operates at |
|---|---|---|
| Prompt engineering | What instructions does the model see for this request? | Per call |
| Context engineering | What information fills the context window for this request? | Per turn |
| Loop engineering | How many steps run, in what order, and when does it stop? | Per session |
| Harness engineering | What is the loop allowed to do, and what gets logged? | Persistent, across all sessions |
For the full breakdown of where each discipline stops and the next one begins, see loop engineering vs harness engineering and moving from prompt and context engineering toward harness engineering.
Five failure modes of an ungoverned loop
Infinite retry
A tool call fails and the agent retries the identical call indefinitely instead of backing off or escalating.
Tool thrashing
The agent alternates between two or three tool calls without making progress toward the goal — a local loop within the loop.
Context bloat
Every step appends the full history instead of compacting it, so token cost per step grows linearly with session length.
Silent drift
A standing loop keeps running after its assumptions about the environment are no longer true, and nobody notices until the output is visibly wrong.
No stopping condition
“Done” was never defined precisely, so the agent keeps refining a result well past the point of diminishing returns.
Unbounded cost
There is no per-session or per-workflow budget, so a stuck loop can run for hours before a human sees the bill.
None of these are model problems — they are loop design problems, and they recur across every framework and every model provider. For token-specific mitigations, see the complete guide to cutting AI agent token costs.
How to design a loop
Step 1: Define "done" before you define the steps. Write the stopping condition as an explicit, checkable statement — not "when the task is complete" but the specific state that means it's complete.
Step 2: Set a hard step ceiling. Pick a maximum number of iterations up front. A loop that hasn't converged by the ceiling should stop and escalate, not keep trying.
Step 3: Decide what state carries forward. Full history, a rolling summary, or just the last N steps — the choice determines both cost and whether the agent can still see the information it needs three steps from now.
Step 4: Design failure handling explicitly. For each tool call, decide: retry with backoff, try an alternative, or stop and ask a human. Don't let this default to whatever the framework does out of the box.
Step 5: Wrap the loop in a harness before it touches production. The loop decides what to try next; the harness decides whether it's allowed to. See the loop engineering checklist for the full pre-launch list.
Frequently asked questions
What is loop engineering?
Loop engineering is the discipline of designing the execution cycle an AI agent runs to complete a task: how it plans a step, calls a tool, observes the result, decides what to do next, and knows when to stop. It covers termination conditions, state management, retry and backoff behavior, and the cost bounds that keep a loop from running away.
Is loop engineering the same as harness engineering?
No. Loop engineering designs the cycle itself — plan, act, observe, repeat, stop. Harness engineering governs what that cycle is allowed to do — which tools it can call, what needs approval, what gets logged. A loop with no harness is unsafe; a harness with no loop has nothing to govern. See the full comparison below.
Why is loop engineering becoming its own discipline now?
Through most of 2025, agent use meant a single request-response exchange: ask, get an answer, done. Through 2026, teams increasingly run standing loops — agents that keep working across many steps, or that run continuously like a cron job, monitoring, triaging, and acting without a human re-prompting each cycle. Standing loops fail in ways single requests never do: they can loop forever, re-call the same tool, or quietly burn budget for days before anyone notices. That gap created the need for a dedicated design discipline.
What happens without loop engineering?
The most common failure isn't a wrong answer — it's a loop that never converges. Symptoms: the agent calls the same tool repeatedly with minor variations, re-reads the same file every turn, retries a failing action indefinitely, or keeps 'working' well past the point where a human would have stopped and asked a question. Each extra turn costs tokens and compute whether or not it moves the task forward.
Who owns loop engineering on an engineering team?
Whoever owns the agent's runtime code — often a platform or AI infrastructure engineer, not the prompt author. Prompt engineering is usually owned by whoever is closest to the task; loop engineering requires systems-level judgment about state, retries, and failure handling, so it tends to sit with the same team that owns the harness and the production runtime.
Related reading: Loop Engineering: 25 Questions Answered, the Loop Engineering Checklist, and agent loops, tokenomics, and the harness.