Agentic Loops: How Coding Agents Actually Work

An agentic loop is the repeating cycle an autonomous coding agent runs to move toward a goal: it gathers the context it needs, decides the next action, acts by calling a tool, observes what happened, and repeats, continuing until the goal is met or a stop condition triggers. That single sentence is the whole idea, and everything else on this page is detail hung off it.

The word that matters is repeating. A raw language model, given a prompt, produces one response and stops. It has no way to see whether that response worked. An agent wraps the model in a loop that feeds the result of each action back in as new context, so the model's next decision is informed by what its last action actually did. That feedback, act, observe, decide again, is what lets an agent grep a codebase, edit a file, run the test, read the failure, and try a different fix, all without a human between each step. Understanding the loop is the foundation of agentic engineering; the loop is the thing every harness, spec, and stop condition exists to shape.

Strip a coding agent down and every iteration of its loop, sometimes called perceive, plan, act, observe, runs the same five moves. Names vary across frameworks; the mechanic does not:

1. 1

   Gather context (perceive / observe)

   The agent assembles what it can see: the goal or spec, relevant files, prior tool results, project conventions from CLAUDE.md or AGENTS.md, and any state carried from earlier turns. On the first turn this is the initial task; on later turns it includes the observation from the previous action. What lands here is the province of context engineering.
2. 2

   Reason / decide the next action

   Given that context, the model reasons about what to do next and picks a single concrete action, which file to read, which edit to make, which command to run. Some loops make this reasoning explicit as a written thought; others keep it implicit. Either way, the output is a decision, not yet a change.
3. 3

   Act via a tool

   The agent executes the chosen action through a tool call: read or grep a file, apply an edit, run a shell command, run the test suite, stage a git commit. This is the only step that touches the outside world, and it is where an agent differs from a chatbot: it does things, it does not just describe them.
4. 4

   Observe the result

   The tool returns a result, file contents, a diff, stdout, a passing or failing test, an error, and that result is fed back into the agent's context. The observation is the feedback signal: it is how the agent learns whether the last action helped, and it is what the next turn's reasoning is built on.
5. 5

   Check done? Loop or stop

   The agent evaluates whether the goal is satisfied. If the acceptance criteria are met or the task is clearly complete, it stops and hands off. If not, and no budget or gate has fired, it loops back to step one with the new observation in context. This done-check is the single most important step, and the one most often left underspecified.

The five-step cycle admits a few well-known arrangements. They differ mainly in when the agent plans and whether it critiques its own work. These are real patterns from the agent literature, described here in plain terms:

In practice these are not exclusive. Most capable coding agents blend them: they draft a rough plan, then run a ReAct-style loop to carry out each step, and may wrap the whole thing in an evaluator pass, or defer that judgment to a human at the PR. The point is not to pick one label but to know which trade-off you are making: adaptivity versus predictability, and how much self-critique you trust before a human looks. When you run several of these loops at once, the coordination problem is its own topic, covered in the multi-agent coding workflow.

Abstract cycles are easy to nod at and hard to picture. Here is what a handful of turns of a real coding agent's loop looks like when the task is “fix the failing checkout total test”:

# turn 1 — gather + act: locate the relevant code
$ grep -rn "calculateTotal" src/
  src/cart/total.ts:42:  export function calculateTotal(items) {

# turn 2 — observe: read the function
$ read src/cart/total.ts
  ...sums item.price but ignores item.quantity...

# turn 3 — act: apply the fix
$ edit src/cart/total.ts   # multiply price by quantity

# turn 4 — act + observe: run the test
$ npm test -- total.test.ts
  ✗ expected 30, received 10   # discount not applied either

# turn 5 — act: patch the discount branch, re-run
$ edit src/cart/total.ts
$ npm test -- total.test.ts
  ✓ 3 passing                  # done-check passes → stop

Notice the shape. The agent does not one-shot the fix; it greps, reads, edits, runs, reads the failure, edits again, re-runs. Each observation, especially the second test failure, changes the next decision. The loop terminates at turn five not because a fixed number of turns elapsed but because the done-check, the test suite, went green. That green suite is the concrete goal the loop was measuring itself against, which is exactly why the next section matters.

A loop is defined as much by how it ends as by how it runs. An agent with no stop condition is not autonomous, it is a runaway. There are two families of termination, and a healthy loop uses both:

The goal condition is where spec-driven development earns its keep: a spec with acceptance criteria gives the loop a finish line it can actually test against, instead of a vague “make it better” that never resolves. The budget conditions are pure engineering hygiene, cheap to add, and the difference between a predictable tool and one you cannot leave unattended. Every serious agent harness wires in both.

When agents misbehave, it is usually the loop, not the model, that failed. Four failure modes account for most of it, and they share a root cause: the loop kept running without the information or the boundary it needed to stop well.

Controlling an agentic loop is not about making the model smarter; it is about giving the loop good boundaries. Four levers do most of the work, and they map directly onto the failure modes above:

1. 1

   Bound the goal with a spec and acceptance criteria

   A concrete, testable definition of done gives the loop a real finish line and starves the doom-loop and the vague-goal runaway. This is the single highest-leverage control, and the whole practice is spec-driven AI development.
2. 2

   Use fresh, scoped sessions per task

   A short loop scoped to one story keeps context clean and defeats context rot: less history to bury the goal, fewer turns to wander. Prefer a fresh session per task over one marathon run, a lesson from context engineering.
3. 3

   Put verification inside the loop

   Make the agent run the tests, not just claim they pass, so the observation is a real signal and 'done' means something. Verification is what turns an agent that emits code into one that checks it, and it is the honest counter to reward-hacking, paired with human review of the diff.
4. 4

   Add human checkpoints at the edges

   Gate the loop where it matters: approve the plan before the agent commits to it, and review the result before it merges. The checkpoints do not slow the loop down mid-run, they bound what it is allowed to start and what it is allowed to finish, the core idea behind the AI agent harness.

None of these require exotic tooling. You can bound a loop by hand: write the spec in markdown, start a fresh session, tell the agent to run the suite, and read the diff before you merge. Tools exist to make the boundaries automatic rather than a matter of discipline, which is what the last section is about, and where orchestrating Claude Code across many stories comes in.

AIDEN is a cockpit over your local coding CLIs, Claude Code and Codex, orchestrating them on a spec-first kanban board. It does not replace the agent's loop; it wraps a boundary around it so the loop terminates at reviewable work instead of drifting. Every story on the board runs a scoped session against an approved spec with a definition of done and a PR gate, which is the four control levers above, made structural:

AIDEN is BYO inference: it runs the CLIs and subscription you already have, and it never makes false claims about what a bare agent can or cannot do, the loop is the same loop, AIDEN just gives it edges. It is free for one project, and Solo is $19/mo, so the cheapest way to see a bounded loop is to run one real story through it and review the PR the loop produces.