Tool calling
Tool calling is the pattern by which an AI agent invokes external functions, APIs, databases, or other systems to accomplish a task. Instead of relying only on the language model's parametric knowledge, a tool-calling agent identifies when an external action is required, formulates the call with the right arguments, receives the result, and incorporates it into the ongoing reasoning or response.
Tool calling turns a language model from a text generator into an agent that can retrieve real-time data, take actions in downstream systems, and complete multi-step workflows. Nearly every production AI agent — including AI customer service agents, coding agents, and research agents — is built on tool calling.
Tool calling vs function calling
The terms are often used interchangeably but they refer to slightly different things. Function calling refers specifically to the LLM API feature — first popularized by OpenAI in 2023 — where the model returns a structured JSON payload describing a function to invoke, rather than natural-language text. It is the mechanism.
Tool calling is the broader agentic pattern that uses function calling as its foundation. A "tool" in this framing is any capability the agent can invoke: a database query, a REST API call, a code execution sandbox, a search engine, or another AI model. Function calling is how the LLM signals its intent; tool calling is what happens end-to-end when the agent orchestrates external work.
How tool calling works
A production tool-calling loop has five stages. First, the developer defines a catalog of available tools, each with a name, natural-language description, and JSON schema for its parameters. Second, the model receives the user's request along with the tool catalog, and either generates a direct text response or a tool-call payload requesting one or more tools be invoked. Third, the agent runtime intercepts the tool-call payload, validates it against the schema, and executes the underlying function. Fourth, the tool's return value is fed back into the model as a new message. Fifth, the model either issues another tool call, generates the final response, or asks the user a clarifying question.
Modern models can request multiple tools in parallel within a single turn. This is critical for latency: an agent that needs to look up the customer's account, check their order status, and fetch the shipping carrier's tracking data can do all three in one round trip rather than three sequential ones.
Common tool categories
In customer service and enterprise AI agent deployments, tools typically fall into four categories. Read tools query internal systems: CRMs, order-management systems, knowledge bases, and analytics warehouses. Write tools modify state: updating a ticket, refunding a payment, cancelling an order, or creating a case. Communication tools reach out through email, SMS, or downstream systems. Utility tools handle calculations, string formatting, or logic that would be awkward or unreliable for the LLM to do in-context.
The read/write distinction matters for safety. Read tools are generally safe to expose broadly; write tools require careful design because a hallucinated tool call can cause real damage. Well-designed AI agent frameworks add human-in-the-loop confirmation, permission scopes, or transactional rollback capabilities around write tools.
Design decisions that determine tool-calling quality
Three design decisions dominate whether a tool-calling agent works well in production.
Tool description quality is the single largest lever. The model chooses tools based on the natural-language description you provide in the tool catalog, not the underlying function name. Clear, disambiguated descriptions with concrete examples produce far better tool selection than terse or generic ones. A description that reads "Looks up an order by ID and returns its current status and shipping information" beats "Order lookup function."
Parameter schemas should be strict but not brittle. Required fields should be genuinely required. Enum types should list every legal value, not leave the model to guess. Optional fields with defaults should have those defaults documented in the description so the model knows when to omit them.
Error handling and retries catch the inevitable model mistakes. When a tool call fails validation, the runtime should return a clear error message that the model can read and correct on the next turn. A tool failure that returns "invalid input" tells the model nothing; a failure that returns "order_id must be a string of 8 digits, received 'ORDER-2024-001'" gives the model actionable information.
Tool calling and the broader agent pattern
Tool calling is the primitive that enables more sophisticated agent patterns. ReAct agents interleave reasoning steps with tool calls to solve complex problems. Agentic RAG uses tool calls to iteratively refine a search rather than fetching all context upfront. Multi-agent systems use tool calling to delegate work between specialized agents. In every case, the underlying primitive is the same: the model expresses a request, the runtime executes it, and the model incorporates the result.
For teams building AI agents, tool calling is where most of the engineering effort actually lives. Prompt engineering, model selection, and evaluation get more attention, but tool design — what tools exist, how they're described, how they handle errors — usually determines whether the agent ships or stalls.
