Tool Use in Language Models

Mert

Tool Use in Language Models

On function calling, Toolformer, agent frameworks, and the idea that language models become dramatically more useful when they can reach outside themselves — calling APIs, executing code, searching the web, and operating software.

finished certainty: likely importance: 7

Tool Use in Language Models

Tool Use in Language Models

A language model, by itself, is a text-in-text-out function. It reads tokens and predicts tokens. It cannot access the internet, check today’s date, execute code, query a database, or interact with any external system. Everything it “knows” was frozen at training time. Every calculation it performs is approximate, running through neural network weights rather than an arithmetic unit. Every factual claim it makes is probabilistic confabulation — the most likely continuation of the input, which may or may not correspond to reality.¹

This is an extraordinary limitation when you think about it. Imagine hiring a brilliant consultant who can discuss any topic with apparent expertise but is locked in a windowless room with no phone, no computer, no books, and no information more recent than their last birthday. That’s a base language model. The knowledge is broad but dated, the reasoning is impressive but unchecked, and anything requiring real-world interaction is simply impossible.

Tool use — giving language models the ability to call external functions, APIs, and software — is the single most impactful augmentation you can make to a language model. It transforms a fluent but unreliable text generator into something approaching a general-purpose cognitive assistant.²

Toolformer: The Foundational Idea

The concept of tool-augmented language models was formalized by Schick et al. (2023) in the Toolformer paper. The core idea: train a language model to decide when and how to use tools by inserting API calls into its generated text.

Toolformer worked by a clever self-supervised process. Starting from a pretrained GPT-J 6.7B model, they:

Sampled potential API calls at each position in the training data (e.g., inserting [Calculator(3+5)] or [Wikipedia("Paris")] at positions where such calls might be useful).
Executed the API calls and inserted the results.
Filtered to keep only calls that reduced the model’s loss — i.e., calls that actually helped the model predict subsequent tokens.
Fine-tuned the model on the filtered data.

The result was a model that learned, without explicit human annotation, when to reach for a calculator, when to look something up, when to call a translation API, and when to just generate text normally. The model developed judgment about tool use — it didn’t call a calculator for “2+2” (it already knew that) but did call one for “1847 × 293” (which it couldn’t reliably compute internally).³

Toolformer was influential more for the concept than the specific implementation. The idea that language models could learn to be tool selectors — deciding which tool to use, what arguments to pass, and how to incorporate the result — became the foundation for everything that followed.

Function Calling in Production

The practical breakthrough came when OpenAI added function calling to the ChatGPT API in June 2023. The interface was simple: you define a set of functions with JSON schemas describing their names, parameters, and descriptions. The model can then choose to “call” a function by generating a structured JSON object with the function name and arguments. Your application executes the function and feeds the result back to the model, which incorporates it into its response.

This sounds like a minor API feature. It was, in retrospect, one of the most consequential product decisions in AI history.⁴

Function calling turned language models from chatbots into integration layers. A model with function calling can:

Search the web (call a search API, read results, synthesize an answer)
Execute code (call a Python interpreter, debug based on error messages, iterate)
Query databases (generate SQL, execute it, interpret results)
Control software (call application APIs, navigate UIs, automate workflows)
Access real-time information (weather, stock prices, news, calendar events)

Each of these had been implemented as specialized systems before. Function calling made them composable — a single model could do all of them in one conversation, deciding which tool to use based on the user’s request. This composability is what makes tool use qualitatively different from RAG or fine-tuning — it’s not about making the model know more or behave differently, it’s about giving the model hands.

Every major model provider now supports function calling: OpenAI, Anthropic, Google, Mistral, and open-weight models like Gemma 4 and LLaMA variants trained for tool use.

Agent Frameworks

Function calling gives models the ability to use tools. Agent frameworks give them the ability to use tools autonomously — planning multi-step tasks, executing tool calls in sequence, handling errors, and iterating until a goal is achieved.

The foundational pattern is the ReAct (Reason + Act) loop from Yao et al. (2023): the model alternates between reasoning (thinking about what to do next, expressed as text) and acting (calling a tool). It observes the tool’s output, reasons again, acts again, and continues until the task is complete or it gets stuck. This is essentially chain-of-thought prompting augmented with the ability to take real-world actions between reasoning steps.

The ecosystem of agent frameworks has exploded:

LangChain was the first widely-adopted framework, providing abstractions for chains (sequential tool use), agents (autonomous tool selection), and memory (conversation history). It became both the standard starting point and the standard target of criticism — LangChain’s abstractions are sometimes accused of being over-engineered for simple use cases and under-engineered for complex ones.⁵

AutoGPT (March 2023) was the first agent to capture public imagination — a system that could set goals, break them into subtasks, execute tool calls, and iterate. It went viral, briefly becoming the most-starred GitHub repo in history. It also demonstrated the failure modes of autonomous agents: loops, irrelevant actions, high API costs, and an alarming tendency to try to modify its own code.⁶

LlamaIndex focused specifically on data agents — agents that can query, retrieve, and synthesize information from multiple data sources. Its strength is in structured data handling: SQL databases, APIs, knowledge graphs.

CrewAI and AutoGen (Microsoft) introduced multi-agent frameworks — systems where multiple specialized agents collaborate on a task. One agent researches, another writes, a third reviews. The agents communicate through natural language, and each has its own tools and persona.

Model Context Protocol (MCP) from Anthropic takes a different approach: instead of building agent logic into the framework, standardize the interface between models and tools. MCP defines a protocol for tool servers — any application can expose its capabilities as MCP tools, and any MCP-compatible model can use them. This is the USB of tool use: a universal connector that lets any model talk to any tool.⁷

The Reliability Problem

The central challenge of tool-using agents is reliability. Each step in an agent’s execution has some probability of failure — the model might call the wrong tool, pass incorrect arguments, misinterpret the result, or hallucinate that an action succeeded when it didn’t. If each step has 90% reliability, a 10-step task has only 35% end-to-end reliability. A 20-step task: 12%.

This is the fundamental reason that autonomous agents haven’t replaced human workers despite the hype cycle of 2023-2024. In benchmarks, agents can solve impressive multi-step problems. In production, they fail in ways that are hard to predict and hard to recover from. The gap between “works in a demo” and “works reliably at scale” is enormous.

Several approaches have been developed to address this:

Human-in-the-loop: the agent proposes actions; a human approves or modifies them. Reliable but slow.
Self-reflection: the agent reviews its own output before finalizing. Reflexion (Shinn et al., 2023) showed this can improve task completion rates by 10-20%.
Verification tools: specialized tools that check the output of other tools. A code execution tool can verify that SQL queries return expected result shapes.
Retry with backtracking: if a step fails, the agent backtracks and tries an alternative approach. This requires maintaining a state history, which adds complexity.
Guardrails and constraints: limiting the set of available tools, requiring confirmation for destructive actions, setting cost and time budgets.

The most reliable production agents I’ve seen use all of these in combination, plus extensive logging and monitoring. They’re also narrowly scoped — a “travel booking agent” or a “code review agent” rather than a “general-purpose assistant.” Narrow scope limits the action space, which limits the ways things can go wrong.

Code Execution As the Killer Tool

Of all the tools available to language models, code execution is the most transformative. A model that can write and run Python code can:

Perform exact arithmetic (no more “LLMs are bad at math”)
Manipulate data structures precisely
Access any Python library (pandas, matplotlib, scipy, etc.)
Process files, images, and structured data
Test its own outputs and iterate on errors

OpenAI’s Code Interpreter (now “Advanced Data Analysis”) demonstrated this powerfully: upload a CSV, ask a question, and the model writes Python to analyze the data, runs it in a sandbox, generates charts, and presents the results. The combination of natural language understanding (parsing the user’s question), code generation (writing correct Python), and tool execution (running the code and inspecting results) is more than the sum of its parts.

Code execution also provides a natural verification mechanism. When a model claims “the average salary in the dataset is $72,000,” you can check whether the code it wrote actually computes an average, whether the result matches the claim, and whether the code handles edge cases correctly. This is a partial solution to the hallucination problem — not because the model can’t write buggy code (it can), but because buggy code produces error messages that the model can use to self-correct.⁸

The Architecture of Tool Use

Under the hood, function calling requires the model to do something unusual: generate structured output (JSON) that conforms to a specific schema, rather than free-form text. This is a different generation task than natural language, and getting it right required changes to both training and inference.⁹

Training. Models are fine-tuned on examples of tool use: conversations where the model decides to call a function, generates the appropriate JSON, receives the result, and incorporates it into a natural language response. Gorilla (Patil et al., 2023) showed that LLMs fine-tuned on API documentation outperform GPT-4 on tool-use benchmarks. ToolBench provided a large-scale benchmark with 16K+ APIs.

Inference. Constrained decoding ensures the model’s output conforms to the function schema — it can only generate valid JSON with the correct field names and types. Libraries like Outlines and Guidance implement grammar-constrained generation that makes structured output reliable.

Routing. When a model has access to many tools, it must decide which one to use — or whether to use any tool at all. This is fundamentally a classification problem embedded in a generation task. Recent work on tool routing suggests that dedicated routing components may outperform the model’s native tool selection, especially when the number of available tools is large.¹⁰

Parallel and Nested Tool Calls

Early function calling implementations supported only sequential, single tool calls: the model calls one function, gets the result, then calls another. Modern implementations support:

Parallel calls. The model generates multiple function calls simultaneously — for example, fetching weather data for three cities at once. This reduces latency dramatically for independent operations.

Nested calls. The result of one tool call becomes the input to another. “Search for recent papers on RAG, then summarize the top 3” requires a search call followed by multiple reading/summarization operations, where the search results parameterize the subsequent calls.

Conditional calls. The model decides which tool to call based on the result of a previous call. “If the database query returns more than 100 rows, sample 100; otherwise, use all of them” requires branching logic within the tool execution flow.

These capabilities bring function calling closer to general-purpose programming. The model is, in effect, writing and executing a program — but in natural language with tool calls, rather than in a traditional programming language. Whether this will converge with traditional programming (models writing explicit code) or remain a separate paradigm (models using natural language orchestration) is an open question.

Where Tool Use Is Going

The trajectory of tool use in LLMs points toward increasingly autonomous and capable agents. Several trends are converging:

Computer use. Anthropic’s computer use feature, released in late 2024, lets Claude control a computer — clicking buttons, typing text, navigating applications, reading screen content. This is tool use taken to its logical extreme: instead of calling specific APIs, the model operates software the same way a human would. It’s slow and error-prone compared to direct API calls, but it works with any application without requiring integration. Google’s Project Mariner explores similar browser-level automation.

Tool creation. Current models use tools that humans define. The next step: models that create their own tools. LATM (Cai et al., 2023) showed that LLMs can generate reusable Python functions as tools, then invoke those tools for subsequent tasks. A model that encounters a repeated task can abstract it into a tool, call that tool in the future, and build up a personal toolkit over time. This is remarkably close to how human expertise develops.¹¹

Multi-agent systems. Complex tasks are increasingly handled by multiple specialized agents that communicate and coordinate. One agent does research, another writes code, a third manages the project plan. Frameworks like AutoGen and CrewAI are building toward this vision, though the reliability challenges multiply with the number of agents.

I suspect tool use will become so integrated into language models that it stops being a separate capability and becomes part of what “language model” means. Just as a modern smartphone is technically a computer that can also make phone calls, a future language model will be a reasoning engine that can also generate text. The text generation is the original capability, but the tool use will be what makes it useful.¹²

The Toolformer paper’s key insight — that models can learn when to use tools, not just how — remains the conceptual foundation. The hardest part of tool use is not the mechanics of API calling. It’s the judgment: knowing when to reach for a calculator versus doing mental arithmetic, when to search the web versus relying on training data, when to execute code versus reasoning in natural language. This judgment is what separates a tool-using agent from a Rube Goldberg machine, and it’s what current models are still learning.

These limitations are not bugs but consequences of the architecture. A transformer processes a fixed context window of tokens through learned weight matrices. It has no mechanism for accessing external state, performing exact computation, or observing real-time information. Every apparent capability — calculation, knowledge, reasoning — is an approximation achieved through pattern matching on training data.↩︎
The impact is hard to overstate. Mialon et al. (2023) surveyed tool-augmented language models and found that tool use consistently improved performance on factual accuracy, mathematical reasoning, and real-world information tasks by 20-50% compared to base models. The gains are especially large on tasks where the model’s internal knowledge is insufficient or unreliable.↩︎
Toolformer’s self-supervised approach to learning tool use was elegant but had limitations. The model could only learn to use tools that it had already seen during training — it couldn’t generalize to novel APIs. And the fine-tuning approach meant the model’s tool-use capabilities were frozen at training time, unlike function calling approaches where new tools can be added at inference time.↩︎
By late 2024, function calling had become the most-used feature of the OpenAI API by volume, surpassing basic chat completions. This suggests that the primary commercial value of language models may not be in generating text but in orchestrating systems.↩︎
The love-hate relationship the developer community has with LangChain is instructive. It lowered the barrier to building agent applications enormously, but its rapid evolution, frequent API changes, and abstraction overhead led many developers to build simpler custom solutions. The pattern — framework adoption followed by framework rebellion — is common in fast-moving fields.↩︎
AutoGPT’s viral moment was important because it demonstrated both the potential and the limitations of autonomous agents to a broad audience. It showed that an LLM could autonomously plan and execute multi-step tasks; it also showed that it would do so unreliably, expensively, and sometimes dangerously. The gap between what’s technically possible and what’s practically useful is the central challenge of the agent paradigm.↩︎
MCP’s approach — standardizing the tool interface rather than the agent logic — is interesting because it separates two concerns that are usually conflated. The question “how should models discover and use tools?” is different from “what logic should govern autonomous agent behavior?” MCP answers the first without prescribing the second.↩︎
There’s a delightful recursion here: the model uses a tool (code execution) to check the output of its own reasoning, and uses its reasoning to fix the tool’s output (debugging code). This self-correcting loop — generate code, run it, read errors, fix code, repeat — is one of the most reliable patterns in tool-using agents.↩︎
The challenge of generating structured output reliably is non-trivial. Language models are trained to generate natural language, not JSON. Without constrained decoding, models frequently produce invalid JSON — missing commas, wrong types, extra fields. Willard & Louf (2023) showed that grammar-constrained decoding can guarantee valid output without degrading quality.↩︎
As tool catalogs grow larger, the tool selection problem becomes harder. Qin et al. (2023) found that GPT-4’s tool selection accuracy degrades from ~90% with 5 available tools to ~60% with 50 available tools. This suggests that scalable tool routing will require specialized retrieval or routing mechanisms rather than relying solely on the model’s native selection ability.↩︎
This connects to the broader theme of self-improving AI systems. A model that can create its own tools is, in a limited sense, improving its own capabilities. The loop from “encountering a problem” to “creating a tool to solve it” to “using that tool in the future” is a form of learning that persists across conversations — a step toward genuine adaptation.↩︎
This is already happening in practice. Users of ChatGPT and Claude increasingly expect their AI assistant to search the web, run code, and access files as a default behavior, not a special mode. The “text-only chatbot” experience feels increasingly primitive.↩︎

[Error: JavaScript disabled.]

[Backlinks, similar links, and the bibliography require JS enabled to load.]