# You Import the Agent Loop. You Own What Goes Into It.

> The agent loop is perceive, reason, act, observe, repeat. It is also about twenty lines, and every harness ships one. The quality of an agent is decided by what you assemble into each turn, not by the loop running it.

Clawnify Resources · https://www.clawnify.com/resources/ai-agent-loops · 2026-08-29

## What an AI agent loop is
An agent loop is the execution pattern underneath every agent product. The model perceives the current state, reasons about what to do next, calls a tool, observes what came back, and goes round again until some condition says stop.

The named patterns are variations on where the thinking sits inside that circle. ReAct interleaves a reasoning step with each action. Plan-and-Execute writes the whole plan first and then works through it, replanning when reality disagrees. Reflexion adds a critique step where the agent reviews its own last attempt before trying again. They are three arrangements of the same four beats.

It is worth being precise about the word, because two different things get called a loop. This one is the architecture: the cycle that lets a model take more than one step. That is the subject here.
## Nobody writes it anymore
Here is the part the tutorials undersell. That cycle is roughly twenty lines of code. It is item one on every list of agent engineering topics not because it is hard, but because it is foundational, sitting alongside tool calling, planning, memory, multi-agent setups, state and graphs, evaluation, guardrails and observability.

In practice you now import it. OpenAI describes teams embedding the open-source Codex harness into internal apps and operations dashboards, and the division of labour they describe is precise: the application controls the interface, the context, the tools and the approvals, while the harness handles the agent loop.

Read that sentence as a bill of materials. One item is handed to a dependency. Four are yours.

This is the usual pattern with a capability that arrives for everyone at once: it stops being the place the advantage lives. We made the same argument about the services economy in AI Roll-ups Are Buying Permission, Not Technology. Having a loop is table stakes. What you feed it is not.
## The four things that are actually yours
Each of the four is a real design surface, and each is where agents get good or stay mediocre.

Context. What you assemble into the turn: the task, the relevant history, the retrieved material, the last error. This is the highest-leverage surface and the easiest to poison. The widely repeated rule that an agent which cannot fix a bug in about three attempts should be stopped is really a context observation. Pasting each new error into the same session fixates the model on its own failed attempts until it is guessing. The recommended fix is not a better model, it is different context: ask it to add the logging needed to reproduce the problem, so the next turn is fed evidence rather than frustration.

Tools. Schemas, whether calls run in parallel or in sequence, and what happens on error. A tool that returns an unhelpful failure teaches the model nothing, and the loop spends its next turn guessing.

Approvals. Which actions a human must confirm. This is the seam between an agent that is useful and one that is dangerous, and it belongs in your application rather than in a dependency.

The interface. Where the work shows up for the person who has to trust it.

The loop is the same in every product; what you put into each turn is the entire difference between them.
## Memory is what makes the loop compound
A loop without persistence repeats. A loop with persistence progresses, and that difference is the reason memory sits so high on every agent engineering list.

Letta makes the point almost as a joke. Letta Code ships a mode you trigger with /ralph, which forces the agent to run continuously. What makes it a feature rather than a hazard is that it is paired with persistent memory, so each pass begins from a state the previous pass wrote down. The loop is unbounded and the work still accumulates.

Physical control loops make the same point without any memory at all, because the world holds the state for them. In one closed-loop rig doing the rounds, an iPhone camera feeds frames to a model, the model judges what it sees and issues commands over Bluetooth to a microcontroller that acts, and fresh frames arrive while the device is still acting, so the control runs asynchronously rather than in turns. Nothing needs to be remembered because the environment is re-read every pass.

Between those two poles sits every agent you will build. Either something survives the turn, or the next turn starts from scratch.
## How to tell whether your loop is any good
Because the loop is shared, the measurements are where teams differ, and they are the ones the discipline has settled on.

Success rate on tasks you can actually score. Trajectory review, meaning read the path the agent took and not only the answer, because a correct result reached by luck will not survive the next input. Cost per completed task, which is the number that turns a demo into a budget. Traces and decision logs so you can see which turn went wrong, and a stop condition you can state as a check rather than as a feeling.

That last one is worth dwelling on. An agent with no measurable definition of done cannot know it is finished, and neither can you. If success is a vibe, every turn looks equally close to it, and the loop has nothing to stop on.
## Building one worth running
The practical sequence, in the order it pays off.

1. Take the loop off the shelf. Use a harness. Writing your own buys nothing and costs you every improvement the maintainers ship.

2. Spend your time on the context. Decide deliberately what enters each turn and what is left out. Most agents that feel dim are well-built loops being fed badly.

3. Give tools honest schemas and useful errors. The failure message is context for the next turn. Make it say something.

4. Persist something every pass. Memory, a file, a log. That is what turns repetition into progress.

5. Define done as a check. A test that passes, a row that appears, an assertion that holds.

6. Keep approvals in your application. Loop freely over reversible work and stop at the door of anything you cannot undo. That is the split OpenAI describes, and it is the right one.

The loop was never the moat. It is the cheapest part of the system and the first thing you should stop building, so that the effort goes where the difference actually gets made.