Every tool call your model makes is not a single event -- it is a round trip with five distinct moves, and the reliability of your whole agent depends on treating it as a state machine rather than a one-shot function call. The model decides it needs something, emits a structured request for it, your code validates and executes that request, you hand back a result, and the model picks the conversation back up with that result in context. Skip the mental model of "the model calls my function" -- it doesn't; it asks, and your system is the one that actually acts.
This lesson is about the plumbing that connects request to execution to return, and specifically about where that plumbing breaks in production: an unbounded loop that never terminates, a dispatcher that crashes on a tool name it has never seen, a tool executed twice because a network hiccup made the model ask again, or a debugging session with no way to tell which of forty tool calls produced the wrong number in the final answer. None of these are exotic failure modes -- they are the default outcome of wiring request and response together without thinking about the lifecycle as a whole.
By the end of this lesson you will be able to describe the five stages by name, know which failure belongs to which stage, and have working code for a turn-capped, validated, logged dispatch loop plus an idempotency guard -- the two pieces of infrastructure every production tool-calling system needs and almost none of the quick-start tutorials show you.