The most useful single idea for understanding how agents behave is the agent loop. Once you see it, "agent" stops being a magic word and becomes a description of a particular kind of program.

The Loop in One Sentence

> Intake → context assembly → model inference → tool execution → > persist → repeat until a stop condition is met.

That is the whole shape. Every long-running agent you have ever used is some variant of it.

The Stages

1. Intake

Something arrives — a message, a webhook, a cron tick, a tool result from the previous iteration. The agent records what came in and from where.

2. Context assembly

The agent pulls together everything it will need for the next decision:

  • System prompt (the operating instructions).
  • Conversation history (or a summary of it).
  • Long-term memory (notes the agent has saved about this user, this

project, this run).

  • Tool definitions (what it can call and how).
  • The current intake item.

The assembled context is what the model will "see" when it thinks. What is and isn't in context is one of the largest determinants of what the model does next.

3. Model inference

The model is asked to produce the next action: a tool call, a final reply to the user, or a structured note. There is no other step here; the model is just a function from context to next-token.

4. Tool execution

If the model emitted a tool call, the agent runs it — file read, shell command, web fetch, calendar update, anything that is wired in. The result is captured.

5. Persist

Whatever the agent just learned or decided (the tool result, the drafted message, a memory note) is saved somewhere durable: a log, a memory file, a session record, a structured state object. Without this step, the next loop iteration starts from zero.

6. Repeat (or terminate)

The agent loops back to step 1 with the persisted state now in scope. The loop ends when:

  • The model emits a final reply and there's nothing pending.
  • A budget (token, time, tool-call count) is exhausted.
  • An explicit stop condition is met ("user said stop", "task done",

"error budget exceeded").

Why the Loop Matters

Three reasons this shape is worth memorizing:

1. Most "agent" failures are loop failures. A loop that forgets to persist, that re-assembles context wrongly, that never sets a stop condition — that is what looks like an agent "going wrong." 2. Improvements happen at specific stages. Better prompting helps at stage 3. Better memory helps at stage 2. Better tool hygiene helps at stage 4. Better observability helps at stage 5. Once you can name the stage, you can name the fix. 3. A loop can run anything that fits the stages. The same loop skeleton can power a coding agent, a research agent, a personal assistant, or a workflow orchestrator. The differences are in the tools, the memory, and the termination condition — not in the shape.

Common Loop Variants

  • Single-shot loop. Runs once, ends. Most "agents" you encounter

in tutorials are this. Useful for bounded tasks.

  • Multi-turn loop. The intake at step 1 is usually a user message;

the loop runs until the user is satisfied or the budget is hit. Chat assistants live here.

  • Cron-driven loop. The intake at step 1 is a schedule tick. The

agent decides whether to act. Heartbeats and scheduled checks live here.

  • Sub-agent loop. A parent agent's tool call spawns a child agent

that runs its own loop and returns. The parent resumes its own loop with the child's output.

  • Graph-driven loop. The "next step" decision is wired through a

state graph instead of being made by the model each iteration. Same stages, different routing.

How to Read an Agent Failure

When something an agent did looks wrong, walk it back through the stages:

  • Was the intake recorded correctly?
  • Was the context the model saw actually the context you expected?
  • Did the model emit what you think it emitted, or did you misread?
  • Did the tool execute correctly, or did it return an error that the

loop swallowed?

  • Did the persist step actually save what was claimed?
  • Did the loop terminate when it should have, or did it run past

budget?

Almost every "agent" bug I've ever debugged was at one of those five places. Naming the stage usually names the fix.

Loop Hygiene

A few habits that keep loops healthy:

  • Persist at every stage, not just at the end. If the loop crashes

mid-iteration, you want a record of where it was.

  • Bound the budget. Token, time, tool-call count. Hard caps beat

soft guidance.

  • Make stop conditions explicit. "I am done when X" is better than

"I will keep going until I feel done."

  • Surface the loop to the human. If the human can't see what the

loop is doing, they can't course-correct it.

What the Loop Is Not

The loop is not the model. The loop is the program the model lives inside. Models come and go; the loop is the part you build, maintain, and debug. That distinction is the entire reason this site exists.