Anatomy of an Agentic Loop

Strip away the orchestration frameworks, the vector stores, and the YAML, and every agent you have ever used is the same four-beat rhythm running in a while loop: perceive, plan, act, verify. The model reads the current state of the world, decides what to do next, does it, and checks whether reality now looks the way it expected. Then it goes around again.

That sounds almost too simple to be worth an article. But each beat exists to absorb a specific class of failure, and most broken agents I have dissected are broken because one beat was skipped or collapsed into another. This piece walks the loop stage by stage, shows what a minimal honest implementation looks like, and ends with how the loop generalizes to the multi-step patterns you actually ship.

Why a loop and not a pipeline

The earliest tool-using systems were pipelines: one prompt produced a full plan, a runner executed every step, and the answer fell out the bottom. Pipelines fail the moment step three returns something the plan's author did not anticipate — a 404, an empty table, a file that moved. The plan was written before the world answered back, so there is no mechanism to revise it.

A loop fixes this by making one decision per iteration, with the freshest possible view of the world. The model never commits to step seven before seeing the result of step two. This is the core insight of the ReAct line of work: interleaving reasoning and acting beats reasoning first and acting second, because acting generates information that the reasoning needs.

The cost is latency and tokens — every iteration is another model call carrying the full history. That trade is worth naming explicitly: loops buy adaptability with inference spend. If your task is genuinely fixed-shape (extract these five fields from every invoice), a pipeline is cheaper and more predictable. Reach for a loop when the path to the goal depends on what you find along the way.

Perceive: the context is the agent

Perception is everything the model can see when it wakes up for an iteration: the system prompt, the task, the conversation so far, and — critically — the results of its previous actions. An agent does not have memory; it has a transcript. If a fact is not in the transcript, the agent does not know it, no matter how recently "it" learned it.

Two practical consequences follow:

Tool results must be informative, not just truthful. A tool that returns "error" is truthful and useless. A tool that returns "error: file not found at /etc/app.conf — directory /etc/app/ exists and contains config.yaml" lets the very next plan step self-correct. You are designing the agent's sensory organs; give them resolution.

Context is a budget, not a bucket. Long-running loops accumulate transcript. Past a point, old tool output stops helping and starts drowning the signal. Production loops compact: summarize stale iterations, truncate bulky results, keep the task and recent state verbatim.

Plan: one decision, not a manifesto

Planning in a loop is deliberately small: given everything perceived, emit the next action — a tool call with arguments, or a decision that the task is complete. Resist the urge to make the model output a numbered ten-step plan and then follow it; that recreates the pipeline failure mode inside your loop.

There is a useful middle ground: let the model keep a lightweight scratchpad plan that it revises every iteration. The plan is advisory; the action is binding. This preserves coherence on long tasks ("I am on step 3 of finding the regression") without locking in stale decisions.

The plan step is also where the loop terminates. The model must be able to say "done" — and your prompt must define what done means. Vague goals ("improve the code") produce loops that either stop instantly or never stop. Verifiable goals ("make npm test pass") give the plan step a real stopping condition.

Act: the only step that touches the world

Acting is mechanically boring — parse the tool call, run it, capture output — and operationally where everything dangerous lives. Three rules earn their keep:

1. Validate arguments before execution. The model will eventually pass a relative path where you expect absolute, or a string where you expect an integer. Reject with a descriptive message; the loop will repair itself on the next pass.
2. Sandbox by default. An agent with shell access has the blast radius of its credentials. Run tools with the narrowest permissions that still let the task succeed, and gate irreversible actions (sending email, deleting data, spending money) behind human confirmation.
3. Return structure, not prose. Tools that return JSON with stable keys are far easier for the model to act on across iterations than free-text blobs.

Here is the whole loop in honest, minimal Python — no framework, just the rhythm:

import json
 
MAX_ITERATIONS = 20
 
def run_agent(client, task: str, tools: dict) -> str:
    messages = [{"role": "user", "content": task}]   # perceive: seed context
 
    for _ in range(MAX_ITERATIONS):
        response = client.create(                     # plan: one decision
            model="hermes-4",
            messages=messages,
            tools=[t.schema for t in tools.values()],
        )
        messages.append(response.to_message())
 
        if response.stop_reason != "tool_use":
            return response.text                      # model declared "done"
 
        for call in response.tool_calls:              # act
            tool = tools[call.name]
            try:
                result = tool.run(**call.arguments)
                payload = {"ok": True, "result": result}
            except Exception as exc:                  # verify: capture failure
                payload = {"ok": False, "error": str(exc)}
 
            messages.append({                         # feed outcome back in
                "role": "tool",
                "tool_call_id": call.id,
                "content": json.dumps(payload),
            })
 
    return "Stopped: iteration budget exhausted."     # bounded, always

Note the iteration cap. Every production loop needs a budget — iterations, tokens, wall-clock, or dollars — because a loop that cannot finish must still end.

Verify: the beat everyone skips

Verification asks: did the action produce the intended effect? Not "did the tool return exit code 0" — did the goal-relevant state change. Writing a file and reading it back. Running the test you just claimed to fix. Re-querying the record you just updated.

Skipping verification produces the most embarrassing class of agent failure: the confident wrong answer. The model edits a file, the edit silently fails to match, and the agent reports success because nothing told it otherwise. Verification converts silent failures into loud ones, and loud failures are exactly what the next perceive step can fix.

The strongest form is independent verification: checking with a different mechanism than the one that acted. If the agent wrote code, run the tests rather than re-reading the code. If the agent claims a server is up, curl it. Self-grading with the same eyes that made the mistake is weak evidence.

Here is one full beat of the loop as a sequence — a single tool call round-trip, from decision to verified result:

The same skeleton in TypeScript, with the verification beat made explicit rather than folded into error handling:

interface StepOutcome {
  ok: boolean;
  evidence: string; // what we observed, fed back into context
}
 
async function actAndVerify(
  call: ToolCall,
  tools: ToolRegistry,
): Promise<StepOutcome> {
  const tool = tools.get(call.name);
  const result = await tool.run(call.arguments);
 
  // Verify against the world, not the tool's own report.
  const check = await tool.verify?.(call.arguments, result);
  if (check && !check.passed) {
    return {
      ok: false,
      evidence: `Tool reported success but verification failed: ${check.detail}`,
    };
  }
  return { ok: true, evidence: result.summary };
}

A verify hook per tool is a pattern worth stealing: the write-file tool re-reads the file; the deploy tool polls the health endpoint. Verification logic lives next to the action it checks.

How the loop scales up

Everything above is one agent, one loop. The patterns you see in larger systems are compositions of the same cycle:

Notice that every row differs mainly in where verification lives. Orchestrator–workers puts it in the orchestrator, which checks sub-agent reports before integrating them. Evaluator–optimizer promotes verification to a whole second agent. The beat never disappears; it just moves.

Closing the loop

If you take one thing from this: the four beats are not a metaphor, they are a checklist. When an agent misbehaves, locate the broken beat. Hallucinated facts → perception starved. Thrashing between approaches → planning without a scratchpad, or a goal with no stopping condition. Dangerous side effects → acting without validation. Confident nonsense → verification skipped.

The loop is small enough to write in an afternoon and deep enough that every production agent system is still, underneath, this. Build the honest version first. Add machinery only when a beat measurably needs it.