An AI "agent" is not a new kind of model. It is an ordinary LLM — the same next-token machine that turns your prompt into integers — wrapped in a plain while loop by a harness (Claude Code, Aider, Codex CLI). Every mysterious-sounding agent behavior is one of seven pedantic steps. Once you can name the step, you can name the failure mode — and most agent-engineering practice turns out to be a defense of one specific step.

One iteration, precisely

1 assemble context rules + tool catalog + history 2 tokenize one integer list 3 forward pass next-token prediction 4 emit tool-call TEXT a request, not an action 5 harness executes all real capability lives here 6 result appended as text 7 go to 1 exit: final answer or budget cap
The whole trick: the LLM proposes (in tokens), the harness disposes (in code), and results loop back (as tokens). There is nothing else.
  1. Assemble the context. The harness concatenates, as plain text: the system prompt, the tool catalog (names, descriptions, parameter schemas — just text), the conversation, and every prior tool result. One long string.
  2. Tokenize. The same slicer as any prompt turns it into one integer list. The tool catalog alone is often thousands of tokens — an overhead you pay every single lap.
  3. Forward passes. The model does the only thing it can do: predict next tokens. There is no separate "reasoning module" — planning, deciding, and tool-choosing are all emitted as tokens.
  4. The model "calls a tool" by emitting formatted text. A tool call is nothing but tokens in an agreed syntax ({"tool": "Bash", "command": "pytest"}). The model cannot execute anything. It writes a request.
  5. The harness parses and executes. Ordinary non-AI code detects the syntax, validates it against the schema, runs the real command/API/edit, and captures the output. All real-world capability lives in this step — as does the permission layer, which is why the harness, not the model, is the security boundary.
  6. The result is appended as text to the conversation.
  7. Go to step 1. The context — now longer — is re-assembled and re-tokenized. The loop exits when the model emits a final answer instead of a tool call, or when the harness hits a cap (turns, tokens, dollars).

Two consequences people miss. The model is stateless between laps — the KV cache is a compute optimization, not memory; the only "memory" is whatever text step 1 re-feeds. And iteration 40 is not smarter than iteration 1 — the weights are frozen; any improvement across a session arrives through the context, never through learning.

What it CAN do

  • Everything its tools + loop reach. Read and write files, run code and observe the result, query APIs — then react to what actually happened. This closes the loop a bare chat model lacks.
  • Self-correct against ground truth. Run tests → read the failure → edit → rerun. This is why routing by the verifier works: the verifier's output re-enters the context and the next lap conditions on it.
  • Decompose long tasks. Each lap only has to pick the next action; the loop, not the model, carries the task across hours.
  • Recover from tool errors. An error message is just more text to condition on — often enough to fix the call on the next lap.

What it CANNOT do

  • Execute anything itself. The model only emits tokens. No tool in the catalog = no capability, period.
  • Remember beyond the context window. Anything evicted or never re-fed is gone. "Memory" features are the harness re-inserting text at step 1 — useful, but step-1 engineering, not model memory.
  • Learn from the session. Improving the model needs offline signals — the token logprobs, chosen-vs-rejected preference pairs, and distillation targets the loop happens to generate as a byproduct.
  • Verify itself. Its confidence is a token probability, not a proof — the silent confident error is intrinsic, which is why benchmark scores lie and why every serious agent pipeline gates on an external check.
  • Guarantee termination or cost. The loop is model-driven; without harness caps it can spin. Budgets and turn limits are not bureaucracy — they are the halting condition.
  • Act atomically. Each tool call is a separate real-world action, and the world can change between step 5 and the next step 1. Two agents sharing a repo will eventually collide; locks and ledgers live in the harness layer.

The one-line version

An agent is a stateless next-token predictor on a leash of re-fed text, whose hands are entirely borrowed from the harness. It can do whatever the loop lets it observe and the tools let it touch — and nothing else. Every piece of agent-engineering folklore is a defense of one step: context budgets defend step 1, tokenizer choice prices step 2, schema validation guards step 5, verifier gates patch the model's inability to check itself, and turn caps make the whole thing halt.

Related: From prompt to token · The tokenizer tax · Why benchmark scores lie · A V-cycle of models.