Chapter 5.4 β€” Agents and Tool Use

Contents

  1. From perceiving more to doing more
  2. What tools give a language model that parameters can't
  3. Function calling: the basic mechanism
  4. ReAct: interleaving reasoning and acting
  5. Toolformer: learning tool use as a training objective
  6. The honest gap between demos and reliable agents
  7. Interview angle
  8. Self-check questions
  9. Sources

1. From perceiving more to doing more

Chapter 5.3 extended what a language model can perceive, letting it condition its generation on images as well as text. This chapter extends what a model can do, taking a model that reasons well (Chapter 5.1) and can perceive rich, grounded context (Chapters 5.2 and 5.3) and giving it a way to act on the world β€” to execute code, query a live database, call an API, or search the web β€” rather than being limited to producing text and nothing else. This is the "agent" framing that has come to dominate a huge share of applied LLM engineering: a language model is no longer just a text generator sitting at the end of a conversation, but the controller of a loop that can take actions, observe their results, and decide what to do next.

2. What tools give a language model that parameters can't

It's worth being precise about exactly what problem tool use solves, because the framing matters for how you reason about when an agentic system is the right design and when it's overkill. A language model's parametric knowledge and reasoning ability, however good, have specific, structural weaknesses that no amount of scale or clever prompting removes. Precise arithmetic and exact computation are one: a model generates tokens via a learned probability distribution, not via a deterministic execution engine, so multiplying two large numbers or executing a precise algorithm reliably is fundamentally a bad fit for autoregressive token generation, even though a model can learn to approximate arithmetic reasonably well for small cases. Live or private data is another: a model's parametric memory is frozen at training time (Chapter 5.2's framing again), so it structurally cannot know today's stock price, the contents of your private database, or anything that happened after its training cutoff, no matter how it's prompted. And taking real-world action β€” sending an email, executing a trade, modifying a file, calling a production API β€” is not something text generation does at all; generating the text "I have sent the email" doesn't send an email. External tools β€” calculators, code interpreters, search engines, databases, arbitrary APIs β€” are precisely the mechanisms that already solve each of these problems reliably, and the engineering question tool use answers is how to let a language model invoke them appropriately, rather than trying to make the model itself replicate what a calculator or a database already does better.

3. Function calling: the basic mechanism

The basic mechanism underlying essentially every agent system is function calling: a model is trained or prompted to recognize when invoking an external function would help answer the current request, and to emit a structured request specifying which function to call and with what arguments, rather than emitting a natural-language answer directly. That structured request β€” typically something like a function name and a set of arguments serialized in a fixed schema β€” is intercepted by the surrounding system (not generated as a hallucinated "result," but actually executed against the real function), and the function's actual return value is inserted back into the model's context as an observation, after which the model continues generating, now conditioned on that real result. This is a direct extension of the autoregressive framing from Chapter 1.1: the sequence being modeled just gets richer, alternating between tokens the model generates and tokens injected from outside the model's own distribution β€” the results of real function execution β€” with the model conditioning its subsequent generation on both in exactly the same way it conditions on any other prior context. How to make the model actually emit that structured request in a schema-valid form reliably, rather than merely usually, is a separate engineering problem, taken up directly in Chapter 5.6.

The engineering value of function calling is that it converts an open-ended, unreliable generation problem ("compute this correctly") into a narrow, well-specified one ("decide whether and how to invoke an external function, then correctly interpret its output"), which plays to what language models are actually good at β€” understanding intent, choosing an appropriate action, and synthesizing results into a coherent response β€” while offloading the parts they're structurally bad at to systems built specifically for those parts.

Function calling as just described says nothing about how a specific tool's schema actually reaches a specific model, and in practice that's historically meant bespoke, per-application, per-tool integration code β€” every agent framework wiring up every tool's schema and invocation logic its own way. The Model Context Protocol (MCP), introduced by Anthropic, standardizes that wiring instead: it defines a common protocol by which a tool (or a data source, or a whole external system) exposes its available functions, their schemas, and how to invoke them, so that any MCP-compatible model or agent framework can discover and call any MCP-compatible tool server without custom integration code written specifically for that pairing. The engineering value is the same kind of standardization that made HTTP or USB useful: it turns an $M \times N$ integration problem (every agent framework separately wiring up every tool) into an $M + N$ one (each tool implements MCP once, each framework implements MCP once, and any tool works with any framework by construction).

4. ReAct: interleaving reasoning and acting

Function calling on its own describes a single action-and-observation step; it doesn't say anything about how a model should decide on a whole sequence of actions to accomplish a multi-step task, or how it should incorporate the results of one action into deciding on the next. Yao et al. (2022) proposed ReAct (Reasoning and Acting) as an influential framework for exactly this: rather than having the model either reason silently and then act, or act repeatedly without any explicit reasoning, ReAct has the model produce an explicit, interleaved trace of "Thought" (a piece of reasoning about what to do next and why), "Action" (a tool call or function invocation), and "Observation" (the real result returned by that action), repeated in a loop until the model decides it has enough information to produce a final answer.

The empirical case for this interleaving, rather than reasoning-only chain-of-thought or acting-only tool use, is that reasoning and acting are complementary and each corrects failure modes the other is prone to. Reasoning-only chain-of-thought (Chapter 5.1) can produce fluent, plausible-sounding derivations that are simply wrong because they're ungrounded in any real, checkable external state β€” the model can hallucinate a fact mid-reasoning-chain with nothing to catch it. Acting without explicit reasoning, on the other hand, tends to make impulsive, poorly-planned tool calls, invoking actions without a clear articulated goal for why that action is the right next step, which makes it harder for the model (or a human debugging its behavior) to recognize when a chosen action isn't actually going to help. Interleaving the two lets the explicit "Thought" step plan and justify the next action before it's taken, and lets the "Observation" step ground subsequent reasoning in real, verified information pulled from the outside world rather than the model's possibly-hallucinated internal beliefs β€” each loop iteration is an opportunity for the model to notice that its plan was wrong and adjust, rather than committing to a single unexamined chain all the way to the end. This Thought-Action-Observation loop is, structurally, the template underlying most agent frameworks and agent-oriented product features that followed.

5. Toolformer: learning tool use as a training objective

ReAct is fundamentally a prompting framework: it relies on carefully constructed prompts (and in-context examples) to induce the Thought-Action-Observation pattern in a model that was never specifically trained to produce it, the same way chain-of-thought prompting in Chapter 5.1 elicited reasoning from a model never trained explicitly to reason. Schick et al. (2023) asked the natural next question, echoing the arc from Chapter 5.1's move from prompting to training: can a model learn, through training rather than prompting alone, when and how to invoke tools on its own?

Toolformer's answer is a self-supervised bootstrapping procedure that requires no manually annotated examples of correct tool use. Starting from a base language model and a small set of example tool-call formats, the model is used to generate candidate tool-call insertions at many positions throughout a large text corpus β€” essentially, the model proposes "here's a place in this passage where calling a calculator, or a search engine, or a calendar API, might help predict the following text more accurately." Each candidate insertion is then actually executed against the real tool, and the resulting tool output is inserted into the text at that position. The key filtering step is self-supervised: the augmented text (with the tool call and its real result inserted) is scored by how much it improves the model's own next-token prediction loss on the text that follows, compared to the original, unaugmented text or a version with an uninformative tool call. Only tool-call insertions that actually reduce the model's prediction loss on subsequent tokens are kept as positive training examples, and the model is then fine-tuned on this filtered dataset of "here's text, here's a tool call that helps predict what comes next, here's the real tool output" examples.

This is a clean illustration of a recurring pattern in this book: a capability (here, deciding when a tool call would help) is turned into something a model can learn directly, using the model's own existing objective (next-token prediction) as the filter for what counts as a good training example, rather than requiring a human to hand-label "yes this is a good place to call a calculator." The result is a model that, at inference time, spontaneously inserts tool calls into its own generation when doing so would improve the accuracy of what it's about to say, without needing a ReAct-style prompt scaffolding to induce that behavior.

6. The honest gap between demos and reliable agents

It would be a mistake, and the kind of mistake a strong interview answer explicitly avoids, to come away from ReAct and Toolformer thinking that agentic tool use is a solved problem. Both papers demonstrate the mechanism working β€” a model can be prompted or trained to invoke tools sensibly β€” on tasks that are comparatively short-horizon: a handful of reasoning-action-observation cycles, or single well-defined tool insertions. Production agent systems, by contrast, are typically asked to carry out long sequences of dependent steps β€” dozens or more sequential actions, each depending on the success of the ones before it β€” and that shift in horizon length exposes problems that don't show up in short demos.

The most fundamental of these is compounding error: if each step in a chain of actions has even a modest independent probability of going wrong, the probability that the entire multi-step sequence completes correctly falls off multiplicatively with the number of steps β€” a chain of $n$ steps, each succeeding independently with probability $p$, succeeds end-to-end with probability roughly $p^n$, which degrades fast even for a fairly reliable per-step $p$. This is a purely structural problem, not one that better prompting or a marginally more capable underlying model straightforwardly fixes, because it's a property of chaining many probabilistic steps together rather than a property of any one step's quality. Related to this is the difficulty of long-horizon planning: deciding on a good sequence of actions many steps in advance, especially when later steps depend on information only available after earlier actions execute, is a harder problem than choosing the single best next action, and current agent systems are considerably better at the latter than the former. Equally important is recovery from mistakes: a capable agent needs to notice when an action didn't produce the expected result or when its overall plan has gone wrong, and to backtrack or replan accordingly, rather than continuing to compound an already-broken trajectory β€” and reliably detecting "this isn't working" partway through a long action sequence remains a genuinely hard, open problem rather than something current systems do robustly.

The honest, interview-appropriate framing is that reliable long-horizon agentic behavior is an open engineering problem, actively being worked on across the field, not a capability that has already been cracked and is merely awaiting wider deployment. Being able to state clearly why compounding error rates make this hard, rather than reciting "agents are the future" as a slogan, is exactly the kind of precision that distinguishes a strong answer here.

Two further directions are worth naming because they compound the same underlying difficulty rather than escaping it. Multi-agent systems replace a single agent working through a task with several agents, often with different roles or specialized prompts (a planner, a coder, a critic that reviews the others' work), coordinating toward a shared goal. This can genuinely help by giving a task explicit checks a single agent's own self-assessment lacks β€” a dedicated critic agent catching a mistake a single agent might have talked itself past β€” but it does not sidestep compounding error, it relocates it: now the end-to-end success probability depends on every agent's individual reliability and on the reliability of the coordination between them, which is its own additional source of failure (miscommunication, agents working at cross purposes, an error introduced by one agent that others fail to catch) layered on top of the single-agent problem section above already describes. Computer-use agents push long-horizon action into an even less structured environment: rather than calling well-specified, schema-defined functions, the agent perceives a screen (via screenshots or an accessibility tree) and acts through the same interfaces a human would β€” clicking, typing, scrolling β€” on software that was never designed to be driven by an API call at all. This removes function calling's clean, well-specified action space entirely, replacing it with the much larger and much less forgiving space of "anything a mouse and keyboard can do to this particular piece of software," which makes the compounding-error and recovery-from-mistakes problems above sharper rather than milder: a single misclick can silently derail a long task in a way a malformed function call, at least, usually can't.

Reasoning, retrieval, multimodal perception, and tool-using agency are all, individually, capabilities that expand what a language model can do. None of them, on their own, tells you whether a system built out of them is actually good β€” whether it produces correct, useful, safe output more often than not, in ways you can measure and trust. That question, evaluation, is where the next chapter turns, and it is in many ways the least mature part of the entire pipeline covered so far.

7. Interview angle

Q: When would you reach for an agentic tool-use architecture versus a plain RAG pipeline versus a single-shot prompted model? A strong answer distinguishes based on the structure of the task: single-shot prompting suffices when the model's parametric knowledge and one-pass reasoning are enough; RAG is appropriate when the bottleneck is missing or stale knowledge that a retrieval step can supply directly; an agentic tool-use loop is warranted when the task requires actions with side effects (querying a live system, executing code, calling an API) or a multi-step process where later steps depend on the results of earlier ones, and it should note that agentic architectures introduce compounding-error and reliability costs that aren't free, so they shouldn't be reached for by default.

Q: Why does ReAct interleave reasoning and acting instead of just having the model produce reasoning first and then a single tool call? A strong answer explains that reasoning-only chains can be fluent but ungrounded, prone to hallucinated intermediate "facts" with nothing to check them, while acting without explicit reasoning tends to produce poorly justified, impulsive tool calls; interleaving lets each action be planned by an explicit thought step and then corrected by a real observation before the next thought, so errors get caught within the loop rather than compounding silently across an unexamined multi-step plan.

Q: How does Toolformer decide which tool calls are actually useful, given that it has no human-labeled examples of correct tool use? A strong answer describes the self-supervised filtering procedure precisely: candidate tool-call insertions are generated, executed against real tools, and kept as training examples only if inserting the real tool output measurably reduces the model's own next-token prediction loss on the subsequent text, compared to not inserting it β€” the model's existing training objective, not a human rater, is the filter.

Q: Why does chaining many agentic steps together make reliability worse, even if each individual step is fairly good? A strong answer gives the multiplicative-probability argument directly: if each of $n$ sequential steps succeeds independently with probability $p$, the whole chain's success probability is roughly $p^n$, which drops quickly as $n$ grows even for a high per-step $p$ β€” and should note this is a structural property of chaining, not something a marginally better model fixes on its own.

Q: What's the difference between "the model can call a calculator" and "the model has learned when to call a calculator," and why does that distinction matter? A strong answer connects this to the ReAct-versus-Toolformer distinction: function calling is just the mechanism (a structured request the surrounding system executes); ReAct elicits sensible tool-use behavior via prompting; Toolformer trains the decision of when and how to invoke a tool directly into the model's weights via a self-supervised objective, so the model doesn't need scaffolding prompts to behave well, mirroring the general prompting-to-training shift discussed in Chapter 5.1.

8. Self-check questions

  1. Name the three structural weaknesses of parametric-only language models that motivate tool use, and give a concrete example of each.
  2. Walk through the basic function-calling loop: what does the model emit, what does the surrounding system do with it, and how does the result re-enter the model's context?
  3. What are the three components of a ReAct loop, and what specific failure mode of reasoning-only prompting does the "Action"/"Observation" step correct for?
  4. Describe Toolformer's self-supervised filtering step in your own words: what makes a candidate tool-call insertion get kept as a training example?
  5. Why is Toolformer described as a training-time analogue of what ReAct achieves through prompting?
  6. Derive, using the independent-step-probability argument, why a 10-step agentic task with 95% per-step reliability has a meaningfully lower overall success probability than the 95% figure might suggest.
  7. Why is "reliable long-horizon agents" described as an open problem rather than a solved one, and what two specific sub-problems (beyond compounding error) does that framing point to?

9. Sources

  • Yao, S., Zhao, J., Yu, D., et al. (2022). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR 2023. arXiv:2210.03629. https://arxiv.org/abs/2210.03629
  • Schick, T., Dwivedi-Yu, J., DessΓ¬, R., et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023. arXiv:2302.04761. https://arxiv.org/abs/2302.04761
  • Anthropic (2024). Model Context Protocol Specification. https://modelcontextprotocol.io

Self-check quiz

Test your understanding of this chapter with a short quiz β€” a mix of concept questions and quick calculations.

What structural weakness of parametric-only language models does tool use address regarding precise arithmetic?

Explanation: A calculator or code interpreter already solves exact computation reliably β€” offloading it is more effective than trying to make the model itself replicate that reliability.

In the basic function-calling mechanism, what happens after the model emits a structured function-call request?

Explanation: The model then continues generating, now conditioned on the real, injected result β€” the same autoregressive framing, just with a richer sequence.

Why does ReAct interleave Thought, Action, and Observation instead of reasoning once and then acting once?

Explanation: Each loop iteration is a chance for the model to notice its plan was wrong and adjust, rather than committing to one unexamined chain to the end.

How does Toolformer decide which candidate tool-call insertions to keep as training examples?

Explanation: The model's own existing training objective β€” not a human rater β€” is the filter, making this a self-supervised bootstrapping procedure requiring no manual annotation.

An agentic task requires 10 sequential steps, each succeeding independently with probability 0.95. Using $p^n$, what is the approximate probability the entire chain succeeds end-to-end? (Round to 2 decimal places.)

Explanation: 0.95^10 β‰ˆ 0.5987 β‰ˆ 0.60 β€” a seemingly reliable 95% per-step success rate still yields only ~60% end-to-end success over 10 steps.

An agentic task requires 20 sequential steps, each succeeding independently with probability 0.9. What is the approximate end-to-end success probability? (Round to 2 decimal places.)

Explanation: 0.9^20 β‰ˆ 0.1216 β‰ˆ 0.12 β€” compounding error degrades success rapidly even at a fairly high per-step reliability.

An agentic task requires 50 sequential steps, each succeeding independently with probability 0.98. What is the approximate end-to-end success probability? (Round to 2 decimal places.)

Explanation: 0.98^50 β‰ˆ 0.364 β‰ˆ 0.36.

You want a 10-step agentic chain to succeed end-to-end with probability 0.5. What per-step success probability $p$ is required (i.e., solve $p^{10} = 0.5$)? (Round to 2 decimal places.)

Explanation: p = 0.5^(1/10) β‰ˆ 0.9330 β‰ˆ 0.93 β€” even a single 50%-overall target requires each step to be individually quite reliable.