Agent Loop

A loop is a playbook with feedback built in: it turns a one-shot instruction into a repeatable process by giving the agent a way to learn from each result and take the next useful step. Where an open-ended "keep improving this" leaves too much room for guessing, a loop supplies a clear finish line and a consistent way to judge progress — so the agent can compare results instead of trusting its own confidence, keep improvements instead of merely making changes, and stop when it succeeds or stops making progress.

A good loop answers four questions: what is the agent trying to accomplish; how will it know whether the latest attempt worked (a real acceptance check); what should it do with what it learned; and when should it finish or hand back to a human. Critically, a loop is deliberately bounded — a real check, a clear stopping point, a finite run boundary supplied before acting, and a hand-back to a person at approval or judgment boundaries. This is the evaluator-optimizer pattern and the bounded agent loop of Workflows vs Agents, packaged as a first-class reusable design object rather than re-derived per task.

Claims

A loop is a playbook with feedback built in — a repeatable process, not a one-shot prompt. principle — durable: the defining move is closing the generate→check→adjust cycle so the work is repeatable, comparable, and trustable.
A good loop answers four questions: goal, how-to-verify-progress, what-to-do-with-the- learning, when-to-stop-or-ask. best practice — context: designing a bounded iterative workflow; the four questions are the checklist that separates a real loop from open-ended "keep improving."
A loop must have a real acceptance check; without a verifiable success signal the agent can only fall back on confidence. principle — durable: feedback loops require ground truth (cf. Workflows vs Agents — "ground truth from the environment at each step").
Loops are not permission to run forever — bound them with a finite run boundary, a clear stopping point, and a hand-back to a human at approval/judgment boundaries. principle — durable: bounded autonomy; the same compounding-error / stopping-condition discipline that gates any autonomous loop.
Stop at success, a clean no-op, a blocker, an approval boundary, an exhausted limit, or no measurable progress. best practice — context: executing a loop in bounded passes; these are the concrete stop conditions, applied after each pass.
Require at least two distinct occurrences before calling work "repeated"; a code pattern without run history is a potential loop, not proven recurrence. best practice — context: mining recurring work to promote into a loop; the two-occurrence bar guards against over-generalizing from a single instance.
A loop is only as good as its done-check — make "done" as objective as possible: "keep iterating until X metric = Y result" beats "until you're satisfied." best practice — context: designing the acceptance check; a subjective stop ("until satisfied", "until 100% confident") still runs but is the weak version — push toward a machine-verifiable metric, and when you genuinely can't, name the fallback explicitly. An independent source (Nate Herk) converges on this same objective-over-subjective discipline.
Verification is the load-bearing reason to loop — most tasks don't need a loop; the ones that do, need it for the check-and-iterate, not the autonomy. observation — the value is the outsourced feedback/iteration cycle (a human would climb quality attempt-by-attempt anyway; the loop just has the agent do it and jump higher faster), not "run unattended for its own sake." Corroborates Agentic Simplicity.
The verification tool must fit what's built — visual check for a UI, functional/play-test for a game, flow/tone check for prose, a code test for a script; it's your job to give the agent the right checking tools. best practice — context: wiring the acceptance check; the form of "how does it check" is task-specific even though the need to check is invariant (cf. Agent-Computer Interface (ACI)).
Match the done-criteria difficulty to cost — an unreachable check runs forever (loops can burn 12h+); hard-cap the passes and make the run make sense against its token/time cost. best practice — context: operating loops on hard goals; the concrete failure mode behind the finite-run-boundary discipline (e.g. "stop at avg ≥ 9, hard cap 8 passes").
Reason → Act → Observe is the loop's inner cycle; "Think→Act→See" (ReAct), model-uses- tools (Anthropic's augmented LLM), goal-runs-unattended (AutoGPT), and manager-with-helpers (multi-agent) are four drawings of one skeleton. observation — the naming varies by source; the underlying reason/act/observe-until-done loop does not. Useful for reconciling the "everyone has their own spin" confusion around agent loops.
In a conversational agent, memory update is a first-class stage of the loop itself — after each response, analyze the exchange and write anything worth remembering — not an offline or per-run process. observation — the per-turn form of the persist-memory rule above: Hermes runs user message → build context → LLM ⇄ tools → response → memory update on every turn, and the source credits that tail stage for the agent "continuously learning the more you use it." See Layered Agent Memory for where the writes land.
For a goal that isn't a metric, bridge abstract → verifiable: attach a review skill that emits a concrete verdict (approved/not-approved or a score) instead of skipping the check. best practice — context: loops whose "done" is subjective (prose, drafts, design); the real-acceptance-check principle still binds, so you manufacture a checkable signal rather than fall back on confidence. See Skill-Driven Loop Development (skills carry the verdict) and LLM-as-Judge (keeping the verdict honest).
Persist loop memory to a plain file — every run starts from scratch unless you record what happened ("the agent forgets, the repo doesn't"). best practice — context: loops you run repeatedly; without recorded lessons the loop re-hits the same failures, wastes tokens, and never improves across runs. An independent source (Addy Osmani, Google Cloud AI) and Anthropic's own guidance ("provide a place to write notes, as simple as a markdown file") converge here; relates to Evergreen vs Volatile Context and Decision Log.

Agentic Workflow Patterns — a loop is the evaluator-optimizer pattern (generate → evaluate → refine) made a first-class, reusable artifact.
Workflows vs Agents — the bounded agent loop with stopping conditions and ground-truth feedback; a loop packages that discipline into a named object.
Reusable Workflow Library — loops become shareable, cataloged, publishable artifacts.
Eval-Driven Development — the acceptance check is the eval flywheel collapsed into the loop's inference-time cycle.
Error Analysis — a run debrief separates loop-design failures from execution, tool, environment, or goal failures before recommending a change.
Loop Engineering — the practice of designing loops instead of prompting; a loop is the artifact loop engineering produces.
Skill-Driven Loop Development — the discipline that supplies a loop's execution steps and acceptance check: pre-validated skills, one of which can emit the verdict.
Loop Training Mode — the run-time guardrail: verify a new loop's behaviour under pause-for-approval before letting it run unattended.
Managed Agent — the same loop lifted into a hosted, always-on cloud runtime; the persist-memory rule above has a managed-service instance there (an attached memory store), and "match done-criteria to cost" gets a vivid case (~$12 / 28 min because a hard rubric requirement couldn't be met in the managed environment — see Pre-Deployment Validation).
Distillate: Forward-Future/loopy — a catalog and skill for bounded, reusable agent loops.
Distillate: Finally. Agent Loops Clearly Explained. — loop engineering, decoded for the rest of us.
Distillate: Loop Engineering, Illustrated: Triggers, Skills, Verification, Memory — a four-block loop anatomy (trigger / skills / goal+verification / output+memory) and the persist-memory rule.
Distillate: Claude Code's New Open-Source "Launch Your Agent" Skill — Loops as a Managed Cloud Service — the goal-not-a-task, check-your-own-work, repeat-until-it-passes engine, deployed as a managed cloud service.
Distillate: Hermes Architecture EXPLAINED: Memory, Context & Gateways — the conversational instantiation: a minimalist per-message loop whose final stage is the memory update.

Agent Loop

Claims

Related

Linked from