The last two issues both came down to the same core mechanism: a model generates text, and that text feeds back in to shape what comes next. An agent is that loop pointed at a goal. “Reasoning” is that loop made to plan before it acts. This week we follow the text out of the model and into the world, to the moment it reaches past itself and makes something happen. That moment is a tool call. Knowing exactly what does and does not occur with a tool call lets you turn an expensive, variable process into a cheap and increasingly reliable one.
The Core Idea: The Model Requests, Deterministic Software Does the Work
On its own, a language model only produces text. It does not calculate well, it’s poor at querying a database, and it never directly opens the file you uploaded. What it can do is produce text in a particular format that the surrounding software program recognizes as a request to run a specific tool with specific inputs.
Here is the entire sequence. A developer registers a set of tools with the system, each with a name, its inputs, and a description of what it does. For example, a calculator tool named calculate that takes two numbers and returns their sum. When the LLMs output indicates a tool-call request (i.e., text that names a tool and supplies its arguments), the LLM stops there. It has not run anything. A separate, ordinary, deterministic software program reads that request, executes the actual function, and places the result back into the model’s context. The model then continues generating textual output with the result obtained from standard, ho-hum software now in front of it.
The seam between the LLM and the deterministic software is important. The model is probabilistic and will generate a different textual answer with each run. In contrast, the tool is deterministic and will work the same way every time. Ask a well-built AI system what 2 + 2 is and it comes back 4 because a calculator computed it, not because the LLM can be trusted to do arithmetic itself. The generative system is good at producing the request. The boring program behind it is what makes the answer dependable.
When You Ask It to Analyze Data, It Writes Code
Most people picture LLMs as opening a spreadsheet and doing the statistics on the fly. But, that’s not what happens. Instead the model writes a short, one-off script (typically in Python or R), and a code-execution tool runs that script against your data. The script computes the means, runs the test, draws the chart. Only the result comes back into the context that the LLM can then pick up and (you hope) faithfully insert it into the conversation.
Two very different kinds of processes are stacked here, and the whole point of this newsletter is learning to tell them apart.
Running the script is deterministic. The same script on the same data returns the same output every single time. But, when you ask an LLM-driven system to write the script, it’s probabilistically generated. Ask the model to write the analysis twice and you can get two different scripts with potentially different libraries, a different way of handling missing values, a different default assumption buried in a statistical call. Most of the time the two scripts agree. Sometimes they do not.
If you’ve ever noticed variation in analytic outputs from run to run, that obviously can’t come from the arithmetic. The deterministic portion ran faithfully both times. But slightly different instructions were run because a fresh script got written for each request. The variability lives entirely in the generative step, and that is exactly the step you can remove.
Write the Code Once, Then Run the Code
For a task you do once, letting the model improvise a script is probably fine and often ideal (though having it do it multiple times allows you to see the variability in its own outputs). For a task you repeat (e.g., monthly reports, standard data-cleaning passes, the same figure every quarter), re-prompting the model each time re-rolls the dice for no reason. The smarter, more reliable move is to have the model write the code once, keep it, and run that saved code from then on. Three benefits follow from using this approach.
