There has been a lot of debate in overseas AI circles these days. Matt Van Horn sorted out this debate in "WTF Is a Loop? Peter Steinberger vs. Boris Cherny": You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents. What really hurts people is not that "prompt is obsolete". What it says is that the focus of the Agent's work is shifting from one-time instructions to a set of execution structures that can run repeatedly, observe status, correct errors, and stop. In engineering language, Agent Loop is not a conceptual wrapper. It is a runtime where a normal chatbot receives a question, generates an answer once, and then ends. When an agent receives a target, it will enter a loop: read the current status, decide the next step, call the tool, observe the results, write the observations back to the context, and then decide whether to continue. Oracle splits this cycle into five segments: Perceive, Reason, Plan, Act, and Observe. Hugging Face, Stacklok, and Kite Metric more commonly use the three paragraphs Thought, Action, and Observation. TinyAgents squeezed it down to 5 lines of pseudocode: call LLM, check tool calls, execute the tool, stuff the tool results back into messages, and then go to the next round. The names are different, but the skeleton is similar: This is the form behind all coding agents, research agents, and workflow agents today.
- The first layer of value of Agent Loop: Let the model move from "answer" to "advance" Hugging Face's Agents Course uses a weather agent as an example: The user asks about the weather in New York, and the agent first thinks "I need the current weather", then calls the weather tool, and then organizes the answer after getting the observation. This example is very basic, but it highlights the boundary between agents and chatbots. Chatbots are good at answering based on existing context; The agent has one more action surface. It turns "I don't know" into a search, an API call, a file read, and a code execution. When MindStudio talks about ReAct loop, it refers to the ReAct idea of ​​Yao et al. in 2022: Reasoning + Acting. The model no longer only infers in the text, it will make inferences in the external environment, and then correct the next step based on environmental feedback. The change brought about by this step is very direct: the context is no longer just the prompt, it becomes the state container after each round of action. Tools are no longer just plug-ins, they become agents that touch the execution boundaries of the world. The observation is no longer a log, it becomes the input for the next round of decision-making. So the first meaning of Agent Loop is simple: transform LLM from a "generator" to a "stateful executor".
- The second layer of value: loop exposes the real failure point of the agent. Oracle’s article makes a direct judgment: the single-round chatbot is not a problem of model capabilities, but an architectural limitation. It cannot continue to disassemble tasks based on tool results, cannot change strategies after failure, and cannot handle workflows that depend on the results of the previous step. But after adding loop, the problem did not disappear, it was just exposed more clearly. Outcome School lists a number of common failures: loops that don’t know when to stop, tools that return bad results, contexts that get cluttered, repeated calls to the same tool, and continuing to miss the target. TinyAgents puts it even more harshly: When the agent gets stuck, it's usually because something in the loop is broken. The model either requested the wrong tool, received the wrong observation, or the stopping conditions were poorly designed. This is also the true experience of many people after using agents: the demo is fast, but has no business value. For an agent to run, it only needs a while loop. For an agent to be able to deliver stably, it needs these things to work together: max iterations to prevent infinite loops; stop condition, to clarify when to end; tool schema, so that actions do not rely on guessing; observation format, so that tool results can continue to be used by the model; trace log, so that each round of judgment can be played back; evaluator, so that good results can be distinguished; budget guard, so that tokens and tool calls do not get out of control. Oracle also gave a cost reminder: agent loop usually consumes more tokens than standard chat, and multi-agent scenarios will continue to expand. Addy Osmani also reminded the same issue in "Loop Engineering": loop engineering is likely to be the future of coding agents, but token cost and quality decline are real risks. This sentence is very important. Loop is not free intelligence, it is a control system with a bill.
- The third layer of value: The difficulty of long-task agents is not "running for a long time", but "not drifting." Robert Courson said it very truthfully when he wrote "/Loops, /goals, and long-running agents": The reason why large tasks can be kept in a useful state is usually not because the model is
- 8 times stronger, but because the structure around the target is better. Failures of long-task agents are stable: context is diluted; one error becomes a full restart; early learning disappears; verification happens too late; people are always babysit; Finally stop at "mostly done forever". These articles are closer to the real engineering site than the ordinary ReAct introduction. If the Agent Loop is only responsible for "thinking, doing, and seeing", it can only handle short tasks. Long tasks require an outer goal structure: task boundaries, stage status, checkpoints, acceptance conditions, failure recovery, and how to save historical experience. This is where “loop engineering” starts to get interesting. What you design is not a round of prompt words, but an execution track: what really determines whether the agent can work independently is often checkpoint and verify. Without these two layers, the loop would just spread the uncertainty further.
- The fourth level of value: Autoloop needs a mechanism to "judge how to get better"! [Xiao Hei installs an evaluation ruler for the loop] (assets/04-autoloop-evaluator.png) Meta Alchemist's "Autoloops > Agent Loops" pushes the problem one step further: a loop that repeats does not mean a loop that will improve. A bad process repeated a thousand times will only produce bad results a thousand times faster. Self-improving loops require at least a mechanism to "differentiate between good and bad". The article calls it domain chip: define what is better in a specific field, and then let each round of output leave comparable traces. Alok Bishoyi's "Self-Evolving Autoresearch Workflow Loops" also talks in a similar direction. He migrated evo's autoreserach loop to dynamic workflows: giving the system a goal, a definition of "better", and a budget, the system generates hypotheses, runs them in an isolated workspace, scores them, and retains better paths. This line is related to the dynamic workflows of Anthropic Claude Code: the coordination logic starts to flow freely from the model and migrates to the small programs and executable workflows generated by the model. The judgment is still involved by the model, but the orchestration becomes code. This will be the next most critical fork of Agent Loop: Ordinary loop: Let the agent continue to do things; Controlled loop: Make every step of the agent observable, stopable, and replayable; Self-improvement loop: Let the agent judge which round is better, and solidify this judgment to the next round. Without an evaluator, self-improvement simply loops on itself.
- After reading these articles, I will split Agent Loop into 7 engineering components. You.com article uses Goal, Context, Plan, Action, and Evaluate to talk about Agent Loop, which is more suitable from the product and platform perspective. Juntao's article: Start building an agent from the smallest REPL, which is suitable for putting the sentence "agent is a loop" into the code. Collaborne Engineering's practice is more like a production accident review: after separating Thought, Action, and Observation, they gain transparent reasoning, quickly locate bugs, reduce repeated tool calls, and better fallback. Taken together, these materials can be compressed into a more engineering list: Goal: Goals must be structured, not just a wish. State: There must be a place for each round of input, tool results, and stage conclusions. Policy: The model needs to know what can and cannot be done. Tool Boundary: Tool interfaces, parameters, permissions, and error returns must be stable. Observation: The tool results must be able to enter the next round of reasoning, rather than just entering the log. Verifier: Phased inspections must be carried out in advance and cannot be done manually at the end. Budget & Stop: Token, time, number of rounds, and risk must all make the loop stop.
- What does this wave of discussion really mean? In the past year, everyone has been asking: Will the model be stronger? This wave of Agent Loop discussions pushes the question down a level: How can a strong model be installed into a controllable execution system? This is why the phrase “design loops that prompt your agents” is so popular. It changes the human role from prompt writer to loop designer. You no longer just write a smarter sentence, you design a system that continuously connects goals, status, tools, feedback, and acceptance. For individual developers, this means that you can start with a 5-line loop and don't be superstitious about the framework right away. For teams, this means that agent projects should not only evaluate model output, but also traces, tool boundaries, stopping conditions, cost curves, and replay capabilities. For product developers, this means that the agent’s selling point cannot stop at “it can call tools”. The real threshold is whether the system can still explain what it did after running the loop for 20 rounds, why it continued, why it stopped, and where to recover if it made a mistake. The surface of Agent Loop is a loop. In engineering, it is to put the unstable model output into an observable, constrainable, and verifiable state machine. After this was done, the Agent moved from demonstration to workflow. Summary of related information Matt Van Horn, "WTF Is a Loop? Peter Steinberger vs. Boris Cherny": Putting this week's discussion of "design loops" back into the five-year evolution of AI coding, emphasizing that the expensive part is shifting from models to loops. Meta Alchemist, "Autoloops > Agent Loops": Repetition does not equal improvement. Self-improvement loops require a domain evaluation mechanism that can distinguish between better and worse. Addy Osmani, "Loop Engineering": Loop engineering uses systems to replace people to prompt agents. Five components have appeared in tools such as Claude Code and Codex. At the same time, we must be wary of token costs and quality decline. Robert Courson, "/Loops, /goals, and long-running agents": Long task success comes more from the structure around the goal, and failure is concentrated in context dilution, restarting, forgetting, verifying too late, and mostly done forever. Alok Bishoyi, "Self-Evolving Autoresearch Workflow Loops": Dynamic workflow writes orchestration into executable code, the model makes judgments, and the research loop generates, runs, scores, and retains better paths in an isolated workspace. Oracle, "What Is the AI ​​Agent Loop?": defines the agent loop as Perceive, Reason, Plan, Act, and Observe, and emphasizes the token cost and observability of the production environment. Hugging Face Agents Course: Explain the basic while loop of agents using Thought, Action, and Observation. Outcome School, "AI Agent Loop": Covers stop conditions, parallel tool calls and common loop failures. MindStudio, "What Is the ReAct Loop?": Explain the agent mechanism of Reasoning + Acting based on the ReAct paper. You.com, "The Agent Loop": Use Goal, Context, Plan, Action, and Evaluate to organize a platform-based agent loop. TinyAgents, "The Agent Loop Explained": Use 5 lines of code to explain the minimum loop behind each agent. Stacklok, "Understanding AI Agents": Explaining Think-Act-Observe with tools, environments, plans, and observations. Collaborne Engineering, "Controlling LLM Agents with Think → Act → Observe": After breaking the loop into explicit steps, you can gain observable logs, debugging speed, and fewer repeated calls. Juntao, "Building an AI Agent from Scratch": Build an agent skeleton from a minimal REPL and tool calls. Kite Metric, "Understanding AI Agents": Putting Think-Act-Observe into SmolAgents and Security Practices.
