🗺️ Why there’s no single definition
Your instinct that something was off was right. Across 45 verified sources, two major vendors and the most cited blogger converged on a tedious phrase, but outside it, definitions fracture into 11 distinct schools. The axis that organizes everything runs from minimum to maximum.
Read the spectrum: on the left, the loop is a sentence (“an LLM using tools in a loop”). On the right, it becomes a scheduled, multi-session system that designs itself. The 11 schools are spread across this spectrum.
🧩 Two things go by “loop”
The cognition cycle internal of the agent (reason-act-observe) and an orchestration loop external, scheduled/automated/designed by a human, within which the agent runs. Confusing the two is the source of half the misunderstandings.
📦 Minimalist: "tools in a loop"
Formal convergence, in one sentence: "an LLM (or model) calling tools in a loop until the task is done". Simon Willison, Anthropic, and LangChain say nearly the same thing, almost word for word. The loop is trivial; the craft lies in the tools, the prompt, and the stopping condition.
"An agentic LLM runs tools in a loop to achieve a goal."
“LLMs using tools autonomously in a loop.”
"A model calling tools in a loop until the task is done."
💡 The phrase became a punching bag
Today, that minimalist definition is also the target of practitioners who call it "too simple to be useful" (swyx cites the phrase only to rebut it). In other words: it’s the foundation—but the boundary debate has already moved beyond it.
🔄 ReAct: reason → act → observe
The most "academic" school and the only one that names an internal cognition cycle: each iteration is thought → action → observation, repeating until it’s finished. It comes from a paper (Yao et al., 2022) and became standard vocabulary in docs and frameworks.
📊 Who’s in this school of thought
It has the most sources: the ReAct paper, architecture surveys, and frameworks such as smolagents, LlamaIndex, and Pydantic AI. When documentation says “Thought / Action / Observation,” this is the school it means.
✅ Verification: built-in × separate
Two schools make verification a named step — and disagree about who checks.
Self-verification
The same agent checks its own work: gather → act → verify → repeat (Anthropic SDK). Voyager does this with a code-correctness gate.
Separate evaluator
A second agent grades the generator's output; the loop runs again until PASS. The generator never self-approves (evaluator-optimizer).
🔗 Where this takes you
The separate evaluator is the root of the pattern Maker → Checker that you build by hand in Track 2, and the adversarial verifier you see in Track 4. Remember the idea: the person who does the work doesn’t grade it.
🏗️ Runner × autonomous loop
Another breakdown: who owns the loop? For vendors, a runtime object (the Runner). For autonomous agents, no one—it prompts itself and runs on its own.
🏗️ Runner / runtime
An orchestrator owns the loop. One "run" = one turn: call the model, inspect the output, branch (run tools / hand off / return), until a stopping point or max_turns.
OpenAI SDK, Google ADK, AWS Bedrock—all formal.
🛰️ Autonomous loop
Runs unsupervised toward a goal: it prompts itself or wakes on a schedule, completes a cycle, checks the state against the criterion, records the result, and repeats — without a human reprompting it.
AutoGPT is the anchor: self-prompt → respond → repeat until the goal is reached.
🛰️ The edge schools (and a trap)
At the "maximum" extreme and in the margins are the most provocative schools—and one pure name trap.
🛰️ Loop engineering
“Stop prompting the agent; design the loop that prompts the agent” (Steinberger). The human becomes the architect. That’s the whole theme of Track 4.
🧠 Cross-trial memory loop
The loop spans episodes: act → feedback → reflect in text → save to memory → do better next time (Reflexion). It learns through language, not retraining.
🧱 "A loop isn’t the right primitive"
swyx: the loop is just the flow-control piece of a 6-element system. Other surveys describe the agent as modules (profile/memory/planning/action), without naming a "loop."
🚨 The terminology trap: "loop" ≠ HITL
Zapier, LangChain HITL, and Microsoft HITL use "loop" to mean human-in-the-loop (human oversight: approve, escalate, give feedback)—and don't define any agent loop.
Classic beginner mistake: copying an HITL guide thinking it’s a loop-building pattern. They’re different things.
⚖️ The 6 axes of disagreement
Those one-line descriptions hide 6 axes where the definitions really disagree. Knowing the axes lets you read any new definition and see where it fits.
| Axis | The positions you’ll see |
|---|---|
| Who owns the loop | the model itself · a Runner/orchestrator · a human who designs the loop |
| What ends the loop | the model decides · an evaluator (PASS) · a hard limit (max_turns) · one operator/CTRL+C |
| Is verification a step? | yes, by itself · yes, by a separate evaluator · there's no explicit step |
| Scope of one iteration | one tool call · one entire session/context window · one episode (with memory) |
| Are tools essential? | yes, they're the point of the loop · no, the loop is about decision/reflection; tools are optional |
| Is “loop” the right primitive? | yes, the agent is a loop · it's just one piece of a larger system · "loop" = HITL, not the agent |
🧩 What this proves
Remove the disagreements and what remains is the invariant core of module 1.2 (model, iteration, state, goal). That’s what a beginner can rely on—the rest is each author’s style.
You find a "human-in-the-loop" guide. Can you use it as a recipe for building an agent loop?
🧾 Module Summary
Next:
Track 2 — When (and when NOT) to use a loop