Why One Simple Loop Drives Every Coding Agent
I read the Gemini CLI source code for a concrete reason: last year I built a Code Agent product internally, and while designing its loop mechanism I wanted to see how an open-source implementation already running on many developers’ terminals actually does it. So I went through the Gemini CLI core directories.
The conclusion surprised me: the essential thing is tiny — it’s a loop. The model speaks, fires tool calls, receives tool results, and speaks again. Everything else — approvals, context compression, loop detection, budget control, model fallback — is peripheral engineering built around that loop. Even the question of “who speaks next” is just a decision point inside the loop: when the model finishes a line without firing any tool, a lightweight model gets asked once whether to continue or hand control back, and “continue” simply starts another turn.
How simple this conclusion looks in the source can be told with three details. The Turn class wraps one model call into an event stream, and the event types are a single enum in the source — from text and tool-call requests to loop detection and session-turn exhaustion, covering every situation the loop can meet. client.ts hard-codes MAX_TURNS = 100 as a ceiling on the recursion. And the next-speaker checker’s prompt carries only three rules: if the previous response states a next action, the model continues; if it ends with a question to the user, control returns; otherwise, control returns as well. For a system that lets an LLM work autonomously, the decision points amount to these few lines.
flowchart TB
A[User request] --> B[Model speaks<br/>may fire tool calls]
B --> C{Any tool<br/>calls fired?}
C -->|Yes| D[Scheduler runs the tools<br/>results go back into history]
D --> B
C -->|No| E[Next Speaker check<br/>lightweight model decides]
E -->|Model continues| B
E -->|Hand back to user| F[Control returns to the input box]Anthropic put this fact plainly in “Building Effective Agents”: agents are typically just “LLMs using tools based on environmental feedback in a loop.” That leaves three questions worth answering seriously. Where did this mechanism come from? Why is it so powerful specifically for writing code? And are today’s coding agents all running this way?
Where the mechanism comes from: not an LLM-era invention
The deepest root of this loop predates LLMs by decades. Reinforcement learning textbooks — Sutton and Barto’s Reinforcement Learning: An Introduction among them — formalize “the agent-environment interaction” as the core of the entire field: the agent observes the environment’s state, takes an action, and the environment returns a new state and a reward, over and over. The classic AI definition of an agent says the same thing in one line: anything that perceives its environment and acts on it. So the loop itself wasn’t invented by anyone — its form was written down decades ago in control theory and reinforcement learning. What happened after 2022 was replacing the decision-making component inside that loop with a language model.
The first piece after that replacement was ReAct (October 2022): interleaving reasoning traces and actions in the same loop — think one step, act one step, observe the result, think again. It addressed two chronic problems of pure reasoning — hallucination drift and untraceability: with actions and environment observations wedged into the chain, the reasoning stays calibrated against real environment feedback. On the ALFWorld and WebShop interactive tasks, ReAct beat the imitation-learning and RL baselines of the day by 34% and 10% absolute success rate, using only a couple of examples.
The second piece was Toolformer (February 2023): through self-supervision, it taught a model to decide on its own when to call an API, what arguments to pass, and how to use the result in later prediction. Before that, “calling tools” was the script’s job — the script parsed the model’s text output, and the model took no part in the decision. After it, the judgment of when to call tools moved back into the model’s hands. That idea later became a standard capability across model APIs (function calling), turning “fire a tool” from text parsing into a structured interface call.
The third piece was landing the loop in code, and it has a clear starting point: in October 2023, SWE-bench shipped with 2,294 real GitHub issues, handing every agent a common benchmark. The early answer was brutal — the strongest model of the day, Claude 2, resolved 1.96%. Seven months later SWE-agent pushed the record to 12.5%, and its central claim wasn’t a stronger model but the ACI (agent-computer interface): search, edit, and browse commands designed specifically for the model, edit commands with linter guardrails, a windowed file view. How well the interface is designed directly decides what score the same brain can earn.
In 2024 the line converged into a consensus. OpenHands (July 2024, later at ICLR 2025) built “working like a human developer — writing code, using the command line, browsing the web” into an open platform, showing the loop can serve as a general base for building a full platform; Anthropic wrote the experience up as methodology at the end of 2024: start with the simplest augmented LLM, move to agents only when needed, and record as shared practitioner wisdom that “we spent more time optimizing our tools than the overall prompt.”
flowchart TB
A["Control theory and reinforcement learning<br/>the perceive-act loop<br/>formalized by Sutton and Barto"] --> B["2021.12 WebGPT<br/>model operates a text browser"]
B --> C["2022.10 ReAct<br/>interleaved reasoning and acting<br/>stops hallucination drift"]
C --> D["2023.02 Toolformer<br/>tool-calling judgment moves to the model"]
D --> E["2023.10 SWE-bench<br/>2,294 real issues<br/>Claude 2 at only 1.96%"]
E --> F["2024.05 SWE-agent<br/>the ACI decides the score<br/>12.5%"]
F --> G["2024 OpenHands and<br/>production harnesses<br/>the loop becomes a common base"]Why it is so powerful in code specifically
Put three pieces of evidence side by side, and the answer is the nature of the feedback.
First, the code environment ships a cheap, deterministic referee. Compilers and test suites don’t equivocate: a pass is a pass, and a failure comes with a concrete error and location. Anthropic’s summary: code solutions are verifiable through automated tests, so agents can iterate using test results as feedback. The “observation” step of the loop carries a strong signal, letting a model finish multiple rounds of self-correction inside one session without a human stepping in.
Anthropic also shared two concrete interface-design details: their agent made mistakes with relative filepaths, so they changed the tools to require absolute paths, after which the model stopped making that mistake; they call this class of design poka-yoke — making the tool’s parameter definitions hard to misuse. Gains like these have nothing to do with model capability; they are engineering decisions.
Second, not even weight updates are needed. Reflexion (2023) showed that an agent which writes its failures into verbal reflections, keeps them in memory, and loops again pushes HumanEval pass@1 from GPT-4’s 80% to 91%. The loop plus verbal feedback alone produces something that looks like learning — direct evidence of how cheap and effective this pattern is.
Third, the numbers trace the gains to loop engineering, not model generations. SWE-bench opened at 1.96%; SWE-agent hit 12.5% five months later on interface redesign alone; after 2024, products like OpenHands, Claude Code, and Gemini CLI fitted the same loop with guardrails (approvals, compression, loop detection, budgets) so it could carry real workloads. One loop structure, stronger models, better interfaces, more complete guardrails — the score keeps climbing.
Are today’s coding agents all running this way
My answer has two layers.
For mainstream autonomous agents, yes. The OpenHands paper describes the base more fully: agents execute code in sandboxed environments, multiple agents can coordinate, and the platform integrates 15 benchmarks (SWE-bench and WebArena among them) under the MIT license, with over 2,100 contributions from 188 contributors. Its acceptance at ICLR 2025 says academia treats “LLM plus tool loop” as the standard paradigm for software engineering research. The public implementations and papers of Claude Code, Gemini CLI, SWE-agent, and OpenHands all share the same core: model-driven tool calls plus environment feedback. Their differences aren’t in the loop but around it — how the tool surface is designed, how permissions are guarded, how context is managed, how runaway behavior is stopped. That matches exactly what I felt reading the Gemini CLI source: dozens of modules in the directory, and not one of them modifies the loop itself; every one of them builds guardrails for it. Building my own product gave me a second sample of the same conclusion: stand up the model, the tool surface, and the loop, and the first version can already carry a complete coding task; in every iteration after that, the effort went almost entirely into guardrails — permissions, context, interruption recovery — while the loop itself never changed a line.
But there are narrowed variants. Aider is a good example: it doesn’t open free tool calling. Instead the model outputs edits in a fixed SEARCH/REPLACE block format, the program parses and applies those blocks, then auto-commits to git and runs tests. The loop narrows into three steps — chat, edit files, test — with no freedom for the model to “decide what’s next,” in exchange for controllable editing behavior. Designs like this show the same loop structure can be opened up or narrowed on demand: loosen the tool surface for autonomy, tighten it into a workflow for control.
Closing
So, to the three questions I opened with: this loop isn’t a new invention — it’s the old perceive-act structure, given an LLM decision core after 2022 and paved all the way into code by ReAct and Toolformer. It’s powerful in code because compilers and tests hand it cheap, deterministic verification results. Mainstream autonomous coding agents all run this way, and the competition has already moved off the loop itself onto the interface (ACI) and the guardrails.
The biggest takeaway from reading the source and building my own agent on top of it: don’t try to invent a new loop; put the engineering effort into the interface and the guardrails.
Two things I’ll watch next: whether agent-environment interface standardization (protocols like MCP) can turn the ACI from private designs into shared infrastructure; and whether the loop’s stopping decision can become more reliable — when to continue and when to hand back to a human is the call whose error rate directly decides how an agent feels to use.