Why the Real Power of Agent Loops Lies Beyond Six Lines of Code

Recent discussions have popularized the claim: “Stop writing prompt strings for agents one by one; write loops instead.” The article examines this idea, showing that the loop itself is simple—a standard while loop that feeds model responses back into the context until no tool calls are needed—but the surrounding engineering is far more complex.

Loop itself is trivial

An Agent is essentially a while True loop:

while True:
    response = model(context)
    if response.has_tool_calls():
        results = run_tools(response.tool_calls)
        context += results
    else:
        break

The model reads the context, requests tool execution, receives the tool results, and repeats until it no longer asks for tools. All mainstream Agent frameworks converge on this six‑line pattern, so the real work is not in the loop syntax.

The engineering focus shifts to everything surrounding the model. Prompt engineering controls what you say, context engineering controls what the model sees, framework engineering handles tool execution, state tracking, and error handling, while loop engineering drives the automatic cycle toward the goal. LangChain summarizes this as “Agent = model + framework”.

Four key problem areas of loop engineering are identified (illustrated in the accompanying diagram):

Knowing when to stop. The loop ends when the model stops requesting tools, but that does not mean the overall task is finished. Proper termination requires hard limits on iterations, token or time budgets, detection of repeated calls (idle loops), and a true completion check—typically passing tests rather than the model’s self‑assessment.

Keeping the context clean. Long loops accumulate stale tool outputs, dead‑ends, and outdated reasoning, causing “context decay” that degrades model performance. Mitigations include summarizing long dialogues, offloading large outputs to files, and delegating sub‑tasks to independent sub‑Agents so only clean results return.

Providing useful tools. A bloated toolbox confuses the Agent. A compact, focused set of non‑overlapping tools works best. Tools must be idempotent (safe to retry) because loops may retry operations, and error messages should be written for the Agent, guiding the next step rather than merely informing a human.

Having a “no” role. An unchecked Agent tends to agree with itself. Effective loops include a separate evaluator—such as a test, type‑check, or real error—that can reject the Agent’s output, preventing silent self‑approval.

Work changes

When these four aspects are combined, the practitioner’s role shifts from directly steering the Agent to designing the system that steers the Agent. As illustrated by Karpathy’s overnight research loops—modifying scripts, testing, retaining useful results, discarding the rest—the human becomes the architect of the loop rather than the operator.

Criticism and alternative views

Some argue that a nondeterministic system checking another nondeterministic system is risky, or that the model itself is the engine and a stronger model may outweigh loop refinements. Others claim the loop narrative is a sales pitch for more API calls, suggesting a single Agent with cron‑style scheduling could suffice.

Nevertheless, the consensus is that the loop is easy; the difficulty lies in covering all edge cases. The community already offers teaching repositories and dozens of packaged “Agent Skill” loops—search for awesome-loop-engineering or Agent-Loop-Skills to explore examples.