Agents and tool use

Give a next-word predictor a loop, a few tools, and a scratchpad - and it starts to plan, act, and check its own work.

Every lesson so far has treated the model as a one-shot function: text in, one continuation out. But ask it "what is 17% of the population of France?" and one shot is not enough - it may not know the population, and it is a shaky calculator. The fix is not a bigger model; it is a loop. Wrap the model so that instead of answering immediately it can emit an action - "search this," "compute that" - let a real tool run, feed the result back into its context, and let it think again. Repeat until it is ready to answer. That loop is what turns a language model into an agent: something that decomposes a goal into steps, reaches out to the world, and adjusts based on what it sees.

From one answer to a loop: tool & function calling

The primitive that makes this possible is tool calling (a.k.a. function calling). You describe a set of tools to the model as a menu - each with a name, a text description, and a typed argument schema (say search(query: str) and calculator(expr: str)). The model, instead of replying in prose, can emit a structured request like calculator("0.17 * 68170000"). Your code - not the model - runs that function and hands the return value back as the next piece of context. The model is still only predicting tokens; you have simply taught it that certain token patterns mean "please run this and tell me the result." Tools are how a frozen, text-only model gets fresh facts (search), exact arithmetic (a calculator), side effects (send an email), or state (read a database).

ReAct: Reason → Act → Observe

The dominant recipe for arranging that loop is ReAct - Reasoning + Acting. Each turn the model interleaves a natural-language reasoning trace with a tool action, then consumes the observation before reasoning again. The magic is the interleaving: pure reasoning with no tools drifts into confident hallucination; pure acting with no reasoning flails without a plan. Alternating the two lets the plan guide the actions and the observations correct the plan. Step through a real trace below - and at the first thought, edit it and re-run to watch the agent take a different path through the problem.

Planning, memory, and the loop as a state graph

Two ingredients turn this simple loop into something that handles genuinely multi-step goals. Planning / task decomposition: for a hard task the first thoughts break the goal into an ordered list of sub-goals ("first get the population, then take a percentage") - sometimes written out explicitly as a plan the later steps tick through. Memory: the growing transcript of thoughts, actions, and observations is the agent's short-term memory - its scratchpad - carried forward in the context window each turn. When that window is too small for a long task, agents add long-term memory: they write facts to an external store and retrieve them later with the same vector search you saw in RAG. The outer machinery that runs the loop - call the model, parse its action, dispatch the tool, append the observation, stop on finish or a step budget - is the orchestrator.

def run_agent(task, tools, model, max_steps=6):
    context = [system_prompt(tools), task]      # scratchpad = short-term memory
    for step in range(max_steps):                # the observation loop (bounded)
        thought, action = model.decide(context)  # REASON: pick the next move
        context.append(f"Thought: {thought}")
        if action.name == "finish":              # terminal node -> stop the recursion
            return action.args["answer"]
        obs = tools[action.name](**action.args)  # ACT: follow an edge to a new state
        context.append(f"Action: {action}")
        context.append(f"Observation: {obs}")     # OBSERVE: fold the world back in
    return "stopped: step budget exhausted"      # the base case that guarantees halting

Now look at that loop through two lenses you already own. It is a state-graph traversal (Lesson 29): the agent starts at a node (the task), every Action is an edge it chooses, every Observation is the new node it arrives at, and finish is a terminal node. Unlike BFS on a fixed graph, the agent builds the graph as it walks - the reasoning trace decides which edge to create next. And it is recursion (Lesson 10) with the outside world spliced into each call. Writing the policy as ${\pi }_{\theta }$, the environment as $\mathrm{env}$, and the running context as $c_t$, one turn is

and the whole agent is a recursive call that keeps extending its own context until the base case fires:

The only reason it halts is the same reason any recursion halts: a base case (the model emits finish) plus a guard against runaway loops (the max_steps budget). Drop both and you get an agent that spins forever - the infinite-recursion bug of Lesson 10, now with an API bill.

Check yourself