Inside the Agent Loop
One agent run, step by step: where the model decides, where my code decides, and where each guard actually sits.
Anatomy of an agent: a machine with 7 parts. Select a part to read what it does.
- 01 Memory Drawers of notes, files and past results it can pull back in.
- 02 Stop rule When to quit: goal met, steps used up, or stuck. No endless loops.
- 03 Tools shelf The things it can do: search, read files, run code, call an API.
- 04 Model (the brain) Reads the goal and what happened so far, then picks the next step.
- 05 Budget meters Time, tokens and money left. It slows down or stops as they run low.
- 06 Guards (checks) Tests and rules every result must pass before it can leave.
- 07 Approval gate Anything risky waits here for a human GO: sending, paying, deleting.
How it works
One agent run, inside its harness
Task Find what Aiden wrote about checks, save a short note, then finish.
Scroll here to play a run.
Pick a scenario to watch the same loop end three different ways: the model finishing, the step budget running out, and a guard catching an instruction that shouldn't be followed. Gold marks whatever is acting right now. The harness is everything inside the dashed frame, and it's the only part that decides what actually runs.
In Part 2 of the Agent OS series I drew the harness from the outside: tools, permissions, a stop on the loop, then trace and eval. This post opens up a single run and shows where each of those pieces lives in the code.
The model asks, the code acts
The model never runs anything itself. When it wants a tool, it sends back a structured request: the tool's name and its inputs. My code reads that request, runs the tool, and sends the result back as the next message.
So the loop is plain code. Send the conversation, read why the model stopped, and if it stopped to ask for a tool, run the tool and go again. Any other stop reason ends the loop.
Thought, action, result
Research on agents that reason and act calls this rhythm thought, action, observation. The model writes a short plan, takes one action, reads what came back, and adjusts.
The upside is that every step is written down, so a person can read why the agent did what it did. The known failure is repetition: the agent repeats the same thought and action and never gets out of the loop.
Four ways a run ends
- The model is done. It answers instead of asking for another tool.
- A step cap. The loop runs a set number of times at most, then hands back what it has.
- A limit. The reply hits its token cap, or a budget you set runs out.
- A person. The run pauses at a checkpoint and waits for approval.
Only the first one comes from the model. The other three are rules I write, and they're what catch the repeat-forever failure.
Two kinds of checks
After the run, some checks are code: did the output match the expected format, did the right tool get called, did a test pass. They're fast, cheap and give the same answer every time.
Others need judgment, like whether the answer was clear or the tone was right. For those a second model grades the output against a written rubric. Code checks first, the model judge only for what code can't measure.
My take
The gold block is the whole argument. Everything my factory relies on happens in that one step, because it's the only place in the loop where my code holds the pen.
Say an agent is fixing broken links in a draft post. The model can propose any edit it wants. The harness decides that edits to drafts run automatically, that anything touching a live page waits for my human GO, and that the run stops after a fixed number of tries even if the model wants one more.
That's the same idea as Hard Rules Inside Claude Code: the model suggests, plain code enforces. Mods are one way to get a hook into that step without writing your own loop.
The eval gate sits at the end of the drawing, but it's built from the same parts. Code checks run on every run. The model judge runs on a sample. Nothing ships until both pass, and anything irreversible still waits for a person.
What I'd add next, as an idea: log the stop reason for every run. If most runs end on the step cap instead of the model finishing, the agent is looping, and I'd rather see that in a log than in a bill.
Try this
- Write down the four ways your agent's run can end. If one is missing, add it as a rule in code, not a line in the prompt.
- Split your checks into two lists: what code can verify and what needs judgment. Automate the first list before you add a model judge.
Sources
- How tool use works (Anthropic docs). The model emits a structured tool request, your code runs it, and the loop continues while the stop reason is a tool call.
- ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., Princeton and Google, arXiv 2022). Interleaved thought, action and observation, readable traces, and the repetitive-loop failure.
- Building effective agents (Anthropic, Dec 2024). Stopping conditions such as a maximum number of iterations, and pausing for human feedback at checkpoints.
- Define success criteria and build evaluations (Anthropic docs). Code-graded checks and model-graded checks against a rubric.