How AI Agents Use Tools (Function Calling Explained)

An AI agent uses a tool through function calling: the model reads the task in front of it, matches that task against the tools it has been given, and outputs a structured request naming the tool and the exact values to pass in. Your application, or the AI provider itself for hosted tools, runs that request against a real system and returns the result, which the model reads before deciding what to do next. Function calling is the mechanism that turns a language model from something that only writes text into something that can check a calendar, update a CRM record, or issue a refund.

This isn't a niche feature anymore. Gartner predicts that 40% of enterprise applications will feature task-specific AI agents by the end of 2026, up from less than 5% in 2025, and nearly every one of those agents depends on function calling to do anything beyond generating a reply. If you're building or buying an agent, understanding how tool calls actually work, and where they break, is the difference between an agent that's genuinely useful and one that looks impressive in a demo and falls apart in production.

From Talking About a Task to Doing It

A model without tools can describe what should happen: "I'd recommend rescheduling this to Thursday and sending a confirmation." A model with tools can make that happen. It calls a calendar tool to check Thursday's availability, calls a messaging tool to send the confirmation, and reports back that it's done. That's the whole difference between a chatbot and an agent, covered in more depth in how AI agents work: perception feeds reasoning, reasoning picks a tool, and the tool is what actually changes something outside the model.

The concept has a name in the AI literature: tool use, sometimes called function calling depending on the vendor. For the plain-English definition and business framing, what is tool use covers that ground. This article goes a level deeper and focuses on what matters once you're actually running an agent: how a tool call is built, how the model decides to make one, what happens when it goes wrong, and how a growing set of tools gets managed without turning into chaos.

The Anatomy of a Tool Call

Every tool an agent can use is defined the same basic way, regardless of which AI provider you're on. Three pieces make up the definition, and the model never sees more than what you put in these three, a structure documented consistently across Anthropic's tool use platform and every other major provider:

When the model decides to use a tool, it doesn't run any code itself. It outputs a structured object naming the tool and filling in the parameters, something like "call check_order_status with order_id: 48213." Your system, or the provider's hosted infrastructure for tools like web search that run on the vendor's side, executes that call against the real order system and sends the result back in the same conversation. The model reads the result as new information and continues, exactly as the perceive-reason-act-observe loop describes.

The quality of the description and the schema decides most of the outcome. A tool named update_record with no description of what kind of record, or which fields it accepts, gives the model almost nothing to work with. A tool the model can misuse because a parameter is loosely typed, a free-text date field instead of a strict format, is a tool that will eventually get called with a value nobody expected.

How the Model Decides Whether to Call a Tool

At each turn, the model makes a small decision: does this request need a tool, or can it answer from what it already knows? A question about your refund policy might be answerable directly if the policy text is already in context. A question about a specific customer's order needs a tool, because the model doesn't know that data and never will unless it looks it up.

Two things shape this decision. First, how well the tool's description maps to the request; a vague description gets skipped or misapplied. Second, how the system prompt or agent configuration nudges the behavior. An agent can be told to always check a knowledge base before answering, to only use tools when explicitly needed, or to require a tool call before responding at all in a given scenario. This is a tunable setting in most agent frameworks, not a fixed behavior, which is why two agents built on the same underlying model can act very differently depending on how directly they're instructed to reach for tools.

This decision point is exactly the "reason" part of the agent loop. How AI agents work covers that full cycle in more depth; the tool-selection moment described here is where reasoning turns into action. For a closer look at what happens on the reasoning side before a tool ever gets called, see how AI agents reason.

Single, Sequential, Parallel, and Conditional Calls

Not every task needs one tool call. Real agent work usually falls into one of four shapes:

The AI Meeting Scheduler Agent blueprint is a clean sequential example: availability lookup, then booking, then confirmation, each step depending on the one before it. The AI Research Agent blueprint leans on parallel and sequential calls together, querying multiple sources at once and then reading each result to decide the next search. The AI Support Triage Agent blueprint is the conditional case: classification determines whether the next tool call is a knowledge base lookup, a routing action, or an escalation.

What Tools Look Like in Production Blueprints

Abstract descriptions only go so far. Here's what tool sets actually look like on real jobs.

The AI SDR Agent calls a research tool to pull firmographic data on a target account, a CRM tool to check for existing relationships and log outreach, and an email tool to send the sequence. Three tools, three distinct systems, one coherent job.

The AI Invoice AP Agent calls a document extraction tool to pull line items off an invoice, a vendor lookup tool to match it against a purchase order, and an ERP tool to post the approved payment. Each tool call here has real financial consequences, which is exactly why an approval step sits between extraction and posting instead of letting the agent chain straight through.

Notice the pattern: the tools an agent has access to define the ceiling of what it can do, nothing more. An agent with a read-only CRM tool can look up records but can't change them. An agent with a write-enabled tool can. That boundary is a design decision, not an accident, and it's usually the first thing worth reviewing when an agent does something you didn't expect.

When Tool Calls Fail: Errors, Retries, and Limits

Tool calls fail more often than demos suggest. The common failure modes:

• Wrong or missing parameters. The model guesses a value it wasn't given, especially on ambiguous requests. A well-built agent asks a clarifying question instead of guessing on anything consequential.
• Permission errors. The tool exists, but the agent's credentials don't allow that specific action, a safeguard that should stay in place rather than get "fixed" by widening access.
• The tool doesn't exist or was misremembered. More common with large, poorly organized tool sets than with a small, well-scoped one.
• Timeouts and outages. The downstream system is slow or down, and the agent needs a defined fallback instead of hanging or guessing at a result.

Scale changes this problem. OpenAI's own function calling guide recommends keeping the number of tools available in a single turn small, generally under 20, because accuracy drops as the model has to distinguish between more and more similar-looking options. For agents that genuinely need a large tool library, the fix isn't cramming all of them into every prompt. It's loading only the relevant subset for the task at hand, so the model chooses from a short, relevant list instead of an overwhelming one.

The observe step is what catches most of this. A well-designed agent checks whether a tool call actually succeeded before treating it as done, retries on a transient failure, and hands off to a human rather than guessing when a failure repeats. An agent that fires a tool call and assumes it worked is the most common root cause behind "the AI said it sent the email but it didn't."

Function Calling and the Standardization Problem

For a while, every tool integration was custom work: a bespoke connector for your CRM, another for your calendar, another for your support desk, each one breaking a little differently when the underlying API changed or you switched AI providers. Model Context Protocol addresses this by standardizing how a model discovers and calls tools, so a tool built once can work across different AI providers instead of being rebuilt for each one.

The standard has grown fast. Anthropic, which originally developed MCP, reported more than 10,000 active public MCP servers as of December 2025, up from a few hundred at launch a year earlier, and the protocol now sits under most major agentic platforms rather than beside them. If you're wiring an agent into a growing set of business tools without rebuilding the integration layer every time you change models, what is Model Context Protocol is the deeper reference, including the security considerations that come with connecting a broader set of servers.

Guardrails: What a Tool Should Never Be Allowed to Do Freely

Not every tool call deserves the same trust. A read-only lookup and a refund-issuing action carry very different risk if the agent gets it wrong, and treating them identically is how a small reasoning error turns into real financial or customer damage.

The pattern that works: scope each tool to the narrowest permission that still does the job, require a human approval step for tools that are financial, irreversible, or customer-facing at scale, and log every call so a wrong action is traceable after the fact instead of a mystery. This is the same discipline covered in AI agent guardrails, and it's what separates an agent that's safe to leave running from one that technically works until the day it doesn't. The Autonomous Agent pattern goes further into why tool-calling loops are the highest-risk part of any agent design, since every call is a chance to change real state.

Key Facts

• Function calling works through three parts: a tool name, a plain-language description, and a parameter schema. The model never executes code itself; it outputs a structured request that your system runs.
• The model decides whether to call a tool by matching the request against tool descriptions and following the instructions it has been given about when to reach for a tool versus answer directly.
• Tool calls happen in four shapes: single, sequential, parallel, and conditional, often combined within one agent's run.
• Accuracy drops as the number of available tools grows. OpenAI recommends keeping the active tool list under roughly 20 and loading additional tools on demand for larger libraries.
• Model Context Protocol standardizes tool integration across AI providers, and the ecosystem has grown past 10,000 active public servers.

Where to Go Next

Tool use is what gives an agent hands. Pair it with the reasoning side of the loop in how AI agents reason to see how a model decides which tool to reach for and when to stop, and see how AI agents work for the full loop these tool calls fit inside. If you're comparing platforms to build on, the automation tools roundup and the best no-code automation tools guide cover where tool-calling capability shows up in the products you can buy today.