A PLAIN-LANGUAGE GUIDE TO AGENT LOOPS
Loop Engineering
A good agent loop is not an AI that works forever. It is a bounded system that knows the goal, takes one useful step, reads real evidence, remembers progress, and stops for the right reason.
System overview
Move from prompting every turn to designing the system
Without an engineered loop, a person repeatedly carries information between the goal, the agent, the tests, and the next prompt. The AI may be capable, but progress still depends on a human noticing every result and deciding every next step.
Loop Engineering externalizes that repetitive coordination. The system can trigger work, prepare a bounded attempt, read evidence, save state, and choose a safe route. The person moves outward: they define the contract, approve risky consequences, and improve the loop when it fails.
Three ideas to keep
- Automation is not absence
The human leaves repetitive routing, not responsibility.
- The loop surrounds the model
Prompts and tool calls are inside a larger operating system.
- A stop is part of the design
Success, blockage, escalation, and budget exhaustion are all valid endings.
Design move 01
Start with the smallest useful loop
The word loop simply means that an observation changes what happens next. An Agent reads the current state, takes an action, observes the environment, adjusts its plan, and reaches a route decision.
The engineering work lives around that cycle: make the goal observable, keep each action bounded, bring back high-signal feedback, and prevent the return arrow from becoming an infinite retry.
The minimum anatomy
- Goal
A result the system can compare against, not merely an activity such as ‘keep improving’.
- Ground truth
The environment must return facts that can change the next action.
- Route
Every lap ends in a decision: retry, stop, block, escalate, or cancel.
Design move 02
Turn intent into an executable contract
A wish such as ‘make checkout better’ gives the Agent freedom but gives the controller nothing reliable to judge. Before the first attempt, convert intent into fields the system can inspect.
A useful run contract names the goal, scope, non-goals, allowed tools, evidence, budget, stop conditions, and escalation owner. It does not need legalistic prose; it needs enough precision to choose the next route without inventing policy mid-run.
Contract fields that prevent drift
- Scope and non-goals
State both what may change and what must remain untouched.
- Evidence and authority
Say what proves success and which real-world actions are permitted.
- Budget and escalation
Cap attempts, time, tokens, and parallelism; name who handles the rest.
Design move 03
Let one attempt do one bounded job
A long-running Loop should not ask one context window to solve the whole project. One attempt should investigate a narrow hypothesis, make a small and preferably reversible change, run the declared checks, and record what was learned.
When an attempt fails, the valuable output is not only the code. The failing test, log, rejected hypothesis, cost, and remaining uncertainty become better input for the next attempt. This is how a loop converges instead of merely repeating.
What a bounded attempt protects
- Context quality
A small job leaves room to reason about the relevant facts.
- Reversibility
Small diffs are easier to inspect, undo, and compare with evidence.
- Learning
A failed attempt still advances the system if its evidence is persisted.
Design move 04
Make completion a verdict, not a feeling
Language models can produce a confident explanation that is internally coherent and still wrong about the environment. The actor's statement ‘done’ is therefore a claim, not a completion signal.
Independent evidence may be deterministic, such as a test or database invariant, or judgment-based, such as a separate reviewer following a rubric. Strong loops combine signals: cheap checks run automatically, realistic E2E checks observe user behavior, and humans decide questions of taste, intent, or serious consequence.
Evidence is layered
- Deterministic checks
Tests, types, invariants, and policy rules are fast and repeatable.
- Realistic observation
Browser, CI, logs, screenshots, and user flows catch environment gaps.
- Human judgment
Intent, taste, tradeoffs, and irreversible consequences remain human territory.
Design move 05
Move memory out of the conversation
A context window is working memory, not a database. Long conversations are compressed, Agents restart, files change, and earlier assumptions become stale. If progress exists only in chat, each new attempt may rediscover old facts or repeat a failed approach.
Durable state should record facts needed for recovery: the current goal, accepted scope, work queue, tried approaches, test output, important decisions, remaining blockers, costs, and the exact reason the previous run stopped. Git, a progress file, a task system, or a database can all serve this role.
Durable state is not a transcript
- Facts over narration
Save current code, checks, decisions, and blockers instead of every thought.
- Fresh reads
Each attempt reloads current reality rather than trusting stale memory.
- Recoverable handoff
A different Agent or human can continue without reconstructing the whole chat.
Design move 06
Design several correct ways to stop
An unsafe loop recognizes only one ending: success. Everything else becomes another retry. A reliable controller treats stopping as a routing problem and names the terminal states before execution begins.
PASS means the declared evidence is satisfied. BLOCKED means an external dependency prevents progress. ESCALATE means the system lacks authority or judgment. BUDGET EXHAUSTED means the experiment has reached its cap. CANCELLED means a person or policy deliberately ended it. None of these states should be disguised as silent failure.
A stop controller asks four questions
- Did evidence pass?
If yes, package the proof and stop repeating the task.
- Can failure teach the next attempt?
Retry only when there is new, actionable information and remaining budget.
- Does a human need to decide?
Escalate ambiguity, missing authority, high impact, or exhausted limits.
Design move 07
Remove one part and watch the loop fail
Reliable behavior is an emergent property of several parts working together. A strong model cannot compensate indefinitely for missing evidence, missing memory, broad permissions, conflicting workspaces, or an absent stop controller.
The fastest way to understand Loop Engineering is to break the machine on purpose. Each missing component creates a recognizable failure pattern that can be monitored and corrected.
Failure has a signature
- Watch symptoms
Repeated attempts, premature completion, conflicting diffs, and growing review queues are system signals.
- Repair the missing layer
Do not respond to every failure by writing a longer prompt or choosing a larger model.
- Improve from traces
Turn recurring incidents into tests, Skills, hooks, graders, or narrower permissions.
Design move 08
See the five loops inside Loop Engineering
People use ‘loop’ for several time scales. At the center, the model calls tools inside one run. Around it, a verifier drives retries. A wider operations loop discovers work and persists it across sessions. An improvement loop changes the Harness from traces. The outermost human loop owns goals, permission, risk, and consequences.
These layers are nested, not replacements. Better prompts still matter inside a Loop; context still needs curation; the Harness still supplies tools and guardrails. Loop Engineering asks how those parts repeatedly interact with reality over time.
Each layer answers a different question
- Can the Agent act?
The execution loop connects model decisions to tools and environment feedback.
- Can the work converge?
Verification and operations turn attempts into sustained, evidence-led progress.
- Can the system stay accountable?
Improvement and human loops govern learning, authority, and real-world consequences.
Design move 09
Walk through a real CI-repair loop
A practical Loop can be much smaller than a software factory. Imagine one routine that responds to a failing checkout test. The trigger is CI, the contract limits changes to the checkout module, the Agent works in an isolated branch, and independent checks decide the route.
The important artifact is not only the patch. A good run delivers an evidence package: what triggered the work, what changed, which checks ran, what remains uncertain, how much budget was used, why the run stopped, and whether a human approval is still required.
A sensible first deployment
- Stable signal
Choose work with a clear trigger and acceptance check, such as a reproducible CI failure.
- Narrow authority
Use the least permission and smallest writable scope required for the task.
- Reviewable delivery
End with a small diff, evidence, stop reason, cost, and known gaps.
BUILD THE FIRST LOOP
Seven questions before you automate another turn
Loop Engineering is useful when a task repeats, its environment can return meaningful evidence, and the next action can be bounded. If the work is deterministic and easily scripted, use a script. If success cannot be judged or the consequence cannot be safely contained, keep a person in the execution path.
Begin with one workflow, low privileges, visible traces, and a small attempt cap. Review early runs closely. Expand autonomy only when the system can explain what it saw, what it changed, why it stopped, and what remains uncertain.
First-loop checklist
- What observable result ends the work?
- What may the Agent change, and what is explicitly out of scope?
- Which evidence comes from the environment rather than the Agent's own report?
- What does one bounded attempt do, and what is the attempt, time, token, and parallelism budget?
- Where are progress, evidence, decisions, and blockers stored outside the chat?
- Which outcomes retry, stop, block, cancel, or escalate to which human owner?
- How will a recurring failure become a test, Skill, hook, grader, tool, or safer policy?
Do not confuse the design scales
- PromptHow should this instruction be phrased?
One control input inside an attempt.
- ContextWhat should the model see right now?
The high-signal information selected for one reasoning step.
- HarnessWhat can this Agent do safely?
Tools, permissions, sandbox, hooks, memory, and recovery around the model.
- LoopHow does work advance and stop over time?
Trigger, contract, attempt, evidence, state, routing, and human boundary.
- FactoryHow are many loops organized at scale?
Queues, isolation, review capacity, governance, and portfolio-level learning.
Loop Engineering is not making AI work forever. It is designing how the system knows the next step, proves the result, stops at the right time, and turns failure into a better next run.
Terminology note: ‘Loop Engineering’ is an emerging AI-Agent practice label, not a single formal standard. This guide synthesizes public 2024–2026 engineering guidance from Anthropic / Claude, Addy Osmani, OpenAI, LangChain, and IBM, and does not claim a single absolute inventor.