Tools: Beyond the Conversation

A language model, by itself, is a sophisticated text engine. It reads what you write, draws on patterns absorbed during training, and produces a response. That is genuinely powerful — but it has hard limits that matter the moment you try to use it for real work.

The model knows nothing that happened after its training data was collected. It cannot check whether a fact is still true. It cannot look up a price, read a document you have not pasted in, send an email, update a record, or run a calculation against live data. It is, in effect, a highly articulate expert who has been in an information blackout since the day their training ended.

Tools are the answer to every one of these limitations. They extend the model's reach beyond the conversation window into the live digital world.

Tool use — sometimes called function calling — is the ability of a language model to recognise when it needs external information or capability, pause its response, call a defined function, receive the result, and incorporate that result into its final output. The user sees a single, fluid answer. Behind the scenes, the model may have consulted several external sources before producing it.

The model itself does not execute code, browse the web, or send emails directly. It issues structured requests to tools — purpose-built functions that carry out specific tasks and return results in a format the model can read. The model is the orchestrator. The tools are the hands.

The tools themselves are defined by whoever builds the AI system — a developer, a platform, or a product team. Each tool has a name, a description the model can read to understand what it does, and a specification of what inputs it accepts and what it returns. The model uses this information to decide which tools to use and when.

When a model has access to tools, each response goes through a reasoning loop rather than a simple generation step. Understanding this loop explains both the power of tool use and its practical characteristics — including why tool-enabled responses can take slightly longer than a standard reply.

From the user's perspective, this entire process is invisible. They ask a question and receive an answer. The tool calls happen in the background. The quality of the answer, however, is fundamentally different from what the model could produce without them.

Web search is one tool in a much larger ecosystem. The range of capabilities available to a model grows as the developer connects more tools to it. The following categories cover the most common and impactful tool types in production AI systems today.

The practical boundary on tool use is not technical — modern model APIs support adding tools with relative ease. The boundary is almost always one of design: what tools make sense for this agent's purpose, and what guardrails should govern their use. A customer service agent probably does not need write access to a production database. A research agent does not need the ability to send emails on the user's behalf. The principle of least privilege — give each agent access only to what it genuinely needs — applies here as much as in any security architecture.

The value of tool use is best understood through concrete examples. The following illustrates how the same underlying model produces fundamentally different — and far more useful — outcomes when equipped with tools.

Each of these represents a shift from the model as a smart text generator to the model as a capable colleague who can go and find things out, process information, and take action. The difference in practical utility is not marginal — it is categorical.

The same capabilities that make tool use powerful also introduce risks that require deliberate design. An agent that can send emails, update records, and call APIs can also make consequential mistakes — and those mistakes may be harder to reverse than a poorly worded text response.

The most powerful applications of tool use are not single-tool calls — they are chains, where the output of one tool becomes the input for the next. This is how agents handle genuinely complex tasks that no single tool could accomplish alone.

Consider a task that sounds simple on the surface: "Prepare a competitive briefing on our three main rivals before tomorrow's board meeting." Broken down, this requires the model to search the web for recent news on each competitor, browse their websites for current positioning and pricing, run a code tool to organise the findings into a structured comparison, write a narrative briefing, format it as a document, and perhaps send it to a shared drive or email it to attendees. Each step depends on the one before it. Each uses a different tool. The model orchestrates the sequence autonomously.

Tool chaining also introduces a need for good error handling. If one step in the chain fails — a website is inaccessible, an API returns an unexpected result — the agent needs to reason about whether to retry, find an alternative, or stop and ask the user. Well-designed agents are explicit about this: they surface failures rather than glossing over them, and they give the user enough information to understand what happened and decide how to proceed.

A language model without tools is genuinely useful. A language model with tools is categorically different — a system capable of finding out what it does not know, acting on what it learns, and completing work that extends far beyond the conversation window.

Web search is the capability that most immediately expands practical usefulness, by solving the knowledge cutoff problem and giving the model access to current, citable information on demand. But search is one tool in a growing ecosystem. The organisations that will extract the most from AI in the next few years are not those who deploy the most powerful models — they are those who most thoughtfully extend those models with the right tools, the right guardrails, and the right workflows.