An agent thinks in stages. The model itself produces inference — the next token, the next tool call, the next decision. But the agent's thinking is the whole loop around that inference. The six stages — intake, context, inference, tool execution, persistence, termination — are what make the model's output useful instead of just plausible.

This piece walks through each stage with concrete examples. The goal is not to teach the model; the goal is to teach the loop.

The model does one thing

The model inside an agent does exactly one thing: given the input, produce the next piece of output. The next piece might be a sentence. It might be a tool call. It might be a decision to terminate the loop. The model does not know which kind of output is expected — it just produces the next token, conditioned on the context it has been given.

Everything else — the goal, the memory, the tools, the loop — is the operator's design choice. When an agent does something stupid, the cause is almost never that the model is stupid. The cause is that the loop gave the model the wrong context, or the wrong tools, or the wrong termination condition.

The rest of this piece walks through the six stages of the loop and names the design choices at each one.

Stage 1 — Intake

The intake stage receives the goal. It is the moment the agent finds out what it is supposed to do. The intake stage is deceptively simple: a goal arrives, the agent writes it down.

The design choices at intake are about how specific the goal is. A vague goal produces vague behavior. A specific goal produces specific behavior — even with the same model and the same tools.

The signal that intake is weak: the agent starts asking clarifying questions, or it starts doing the wrong thing and noticing too late.

The fix is almost always at intake. Make the goal specific. Make the success criteria explicit. Make the deadline explicit. If the goal cannot be made specific, refuse it — the loop will do better work on a more specific version of the same goal.

Stage 2 — Context

The context stage gathers what the agent needs to act well. It is the moment the agent looks around. It reads files. It checks memory. It pulls in retrieved chunks. It inspects prior state.

The design choices at context are about what to include and what to leave out. Too little context and the agent guesses. Too much context and the agent drowns.

The signals that context is wrong:

  • The agent hallucinates facts that are not in the workspace.
  • The agent cites notes that are six months old.
  • The agent uses one tool when another would have worked.
  • The agent's responses get longer and slower as the conversation grows.

The fix is to bound the context deliberately. Decide which sources are canonical for this kind of work. Decide how many chunks to retrieve. Decide what to summarize and what to keep verbatim. The piece on Why Context Explodes Without Bounding treats this stage in depth.

Stage 3 — Inference

The inference stage is the model's contribution. The model reads the context and produces the next piece of output — a sentence, a tool call, a decision to terminate.

The design choices at inference are about prompting. The model is roughly as capable as it is going to be. What changes between a working inference and a failing inference is the prompt that frames the work.

A useful prompt has four pieces:

  • Role. What kind of work is this?
  • Task. What is the specific thing to do?
  • Constraints. What are the limits — length, format, scope, forbidden tools?
  • Examples. What does a good answer look like?

The piece on Best Ways to Ask an Agent for Things treats this pattern in detail.

Stage 4 — Tool execution

The tool execution stage is where the agent's thinking meets the real world. The model produces a tool call; the platform runs the tool; the result comes back; the loop continues.

The design choices at tool execution are about what tools exist, what they do, and what they return. A weak tool layer gives the agent tools that fail silently, return incomprehensible errors, or do something subtly different from what the agent expected.

The signals that tool execution is wrong:

  • The agent retries the same tool call three times in a row.
  • The agent treats a tool error as a successful result.
  • The agent's tool calls drift toward tools that should not be available in this context.

The fix is at the tool layer. Tools should be specific, named clearly, and return errors loudly. The agent should be told when a tool result is suspect, not just when it succeeds.

Stage 5 — Persistence

The persistence stage records what happened in a place that survives the loop iteration. The agent writes to a file. The agent updates a state store. The agent appends to its long-term memory.

The design choices at persistence are about what to save and where to save it. A weak persistence layer saves too much to the wrong place. The agent's long-term memory file grows without bound. The wiki is not updated when it should be. The semantic index is not reindexed when chunks go stale.

The fix is to decide, before the loop runs, which kinds of facts go to which memory layer. The piece on Agent Memory and State treats this in depth.

Stage 6 — Termination

The termination stage decides whether to run another iteration. This is the stage most agent designs skip, and it is the stage where most agent failures originate.

A weak termination layer terminates on the wrong signal — "I feel done," "I produced some text," "I haven't errored." A strong termination layer terminates on a written predicate — "the file was created," "the API returned 200," "the user said done."

The signals that termination is wrong:

  • The agent loops forever producing nothing useful.
  • The agent declares success without producing the artifact.
  • The agent stops one step short of completion.

The fix is to write the termination condition down before the loop runs. Make it a predicate, not a vibe. The piece on Why Agents Stall treats this stage in detail.

How the stages compose

The six stages run in order, but the order is not always strict. A loop might do partial context, partial inference, partial tool execution, then more context, then more inference. The stages are a vocabulary, not a schedule.

What the stages buy is legibility. When the agent does something wrong, the operator can ask "which stage failed?" and get a useful answer. "The intake was vague." "The context was stale." "The tool returned a malformed result." "The termination condition was a vibe."

Each of those failures has a different fix. Naming the stage names the fix.

Takeaway

An agent thinks in stages. The model produces inference; the loop produces the rest. Most agent failures are loop failures, not model failures. The fix is at the stage that failed, not at the model that produced the wrong output.

Read the next pieces in this manual to go deeper on each stage. The vocabulary in this piece is enough to read any of them.