The Agent Loop

Every serious agent library is a costume on the same loop. The library may say ReAct, plan-and-execute, or “crew.” Under the costume, a program is still doing this:

1. Assemble context (goal, memory, observations, tool docs)
2. Ask the model what to do next
3. Parse a thought, a tool call, or a final answer
4. Execute tools in the real world
5. Append results to context
6. Repeat until a stop condition

This is ReAct when the model is asked to emit reasoning plus an action. Reasoning here means text the model writes before it names a tool — not a guarantee of truth. It is plan-and-execute when step 2 produces a whole plan first, then later steps run the plan. It is multi-agent when step 4 is “ask another agent.” The loop did not become a different species. The action got bigger.

People confuse the loop with “the model thinking forever.” Thinking is cheap to say and expensive to run. Each turn rewrites history. The model does not remember the previous call. You send the growing transcript again. Context grows. Cost grows. Attention gets noisier. That is why later tracks spend time on memory, retrieval, and summarization — not because they are fashionable, but because the loop is otherwise unbounded.

What each step is doing

Assemble. If you forget tool docs, the model invents APIs. If you dump the entire company wiki, you pay for noise and you hide the goal.

Ask. This is the only step that looks like “AI.” Treat it as a function from transcript to decision.

Parse. Models emit messy text. Your parser must fail loud when the shape is wrong. Silent repair is how you execute the wrong tool.

Execute. This is the real world: HTTP, SQL, files, refunds. It needs permissions, timeouts, and an allow-list of names.

Append. If a tool fails and you hide the error, the next ask repeats the same call. Errors are observations. Keep them short and true.

Repeat or stop. No stop is not “more autonomous.” It is a runaway process.

Why loops eat tokens

A token is a chunk of text the model reads or writes. You pay for input tokens and output tokens. On step 1 the input is the goal. On step 10 the input is the goal plus nine tool results plus nine model messages. A 20-step run can cost many times a single chat.

Implications you will implement later, named only so the cost is not a surprise:

• Keep tool results short
• Summarize old steps
• Retrieve only the chunks you need
• Prefer small models for routing and big models for hard reasoning

The trace is the list of thoughts, calls, and results. It is the most important artifact you will produce in production. You cannot eval, debug, or bill without it.

A warehouse ticket in slow motion

A warehouse system asks: “We have 3 pallets of 4 boxes. Each box ships in packs priced as 10. What is the number we need?” A human would add 3 and 4, then multiply by 10. An agent with two tools, add and mul, should do the same: call add, see 7, call mul, see 70, then stop with a final sentence.

In production, step 2 would be a model. In the box below, step 2 is a script — a hard-coded list of decisions. The script stands in for an LLM. That is honest. You can see the loop without paying for tokens. Notice that the script does not read the prior result. It already “knows” to multiply 7 and 10. A real model would have to look at the trace. The surrounding code — tools, events, stop on final — is the part you keep.

Run to execute this in your browser. Nothing is sent to a server.

You should see two JSON lines. The first is step 1, add, arguments 3 and 4, result 7. The second is step 2, mul, arguments 7 and 10, result 70. Then a line that starts with FINAL and the sentence about 70. Then the count of tool calls (2) and the last result (70). If you change the script’s multiply inputs, the final sentence will lie unless you change it too. That lie is premature stop in miniature: words that do not check the trace.

What goes wrong

• Infinite retry. The tool fails. The model calls it the same way again. The trace grows. The bill grows. The bug stays.
• Goal drift. The user asked for a number. The model starts writing a warehouse essay. Neighboring problems feel helpful.
• Context rot. Old errors stay in the prompt. The model imitates the errors. Failed JSON becomes a style.
• Premature stop. The model claims success without reading the last tool result. Cheerful. Wrong.
• Tool hallucination. It invents multiply_boxes because that name sounds right. Your execute step must reject unknown names.
• Parse mush. You accept free-form text as a tool call. Sometimes it works. Then it refunds the wrong id.
• No trace. You cannot say which step burned the tokens. You cannot write an eval. You cannot replay.
• Stop only on keyboard interrupt. That is not a product. That is a process you kill by hand.

You will build defenses for each of these in later tracks: schemas, retries with wait, evals, allowed-tool lists, and “verify before final.” This lesson only names the failures so you can see them in the loop.

Tip:Log every thought and tool result. If you cannot replay a run, you cannot improve a run.

Where this goes next

Prompting and structured output are how step 3 stops being a hope. Tools is how step 4 becomes an API with a schema. RAG and memory are how step 1 stays small. Agents (the architecture track) puts costumes on this loop. Evals score traces. Production stores traces and caps spend. Do not skip the fake script. If you cannot follow two JSON lines, a live model will only hide the same loop in poetry.

How agents use this

The loop is the product. Frameworks are optional. Your code should make the six steps visible.

• Code: a run function with a list of tools, a transcript, a parser, and a max_steps integer. One function per tool. Unknown tool names return an error object, not an exception that kills the process without a log.
• Logs: append one event per step: step number, tool name, arguments, result, tokens if you have them. The classroom json.dumps(event) is the seed of that log.
• Tests: feed a scripted model (like the list above) and assert the trace has two calls and a final. Then feed a model that tries an unknown tool and assert you stop with an error, not a hang.
• Stop conditions: success when a final decision appears and a check function agrees with the last result; failure when max_steps or a cost cap hits; handoff when the parser sees ask_human.

If you remember one sentence: the trace is the agent’s memory of the loop, and the stop condition is the agent’s contract with your wallet.