How Do AI Agents Use Tools and Call Functions?

Imagine it is Monday morning at the Lagos fabric shop from the first post, and the owner types: “Where is order 1042?” The agent answers after looking up the order and checking the courier. It did not reach into the shop’s systems by magic. This post shows what actually happens between the question and the answer.

(This is an illustrative scene, not a real business.)

What is a tool for an AI agent?

A tool is something the model can ask your software to do. In the first post, a tool was defined as a function or service the model can ask to use. OpenAI’s practical guide says agents need three types of tool: data tools that retrieve information (such as querying a database), action tools that change something (such as sending a message or updating a record), and orchestration tools, where one agent is used as a tool by another. Posts 3 and 4 in this series gave reasons to treat the second type with care.

What is function calling?

Function calling is the way a model asks for a tool to be run. OpenAI’s function-calling guide, as of October 2026, describes it as a way for its models “to interface with external systems and access data outside their training data”. Anthropic’s documentation, as of October 2026, says tool use is “also called function calling”. OpenAI also uses the name tool calling. In this post we use the terms interchangeably.

OpenAI adds a distinction: “A function is a specific kind of tool, defined by a JSON schema.” A schema is a written description of what a piece of data must look like. JSON is a plain-text format for structured data, with named fields such as "order_id": 1042.

What does the round trip look like?

The model asks, your code acts, and the result goes back to the model. OpenAI’s function-calling guide, as of October 2026, lists five high-level steps:

1. Make a request to the model with tools it could call.
2. Receive a tool call from the model.
3. Execute code on the application side with input from the tool call.
4. Make a second request to the model with the tool output.
5. Receive a final response from the model, or more tool calls.

Step 5 is where the loop from the second post comes back. If the model asks for another tool, the cycle repeats. A tool call, as the second post defined it, is a structured request that names a tool and the inputs to use. Anthropic’s documentation, as of October 2026, puts the key point plainly: “The model never executes anything on its own. It emits a structured request, your code (or Anthropic’s servers) runs the operation, and the result flows back into the conversation.”

Who runs the tool: your code or the vendor’s?

It depends on the tool. Anthropic’s overview says, as of October 2026, that “Tools differ primarily by where the code executes.” Client tools, which include tools you define yourself, run in your application. The model replies with a tool request, your code does the work, and you send back the result. Server tools, such as web search, “run on Anthropic’s infrastructure”, which means Anthropic’s own servers, so you usually see the results without handling the execution. OpenAI also offers built-in tools that can search the web or run code.

For a shop, the tools that touch its own orders and customers are the ones its own software runs. That is useful, because your code is the place to check what is allowed.

What does a tool definition contain?

A tool definition has three parts: a name, a description in plain language, and a schema for the inputs. Each input is a parameter, and the value the model fills in for one call is an argument.

Illustrative example. The tool names and the definition below are made up. Imagine the shop’s developer describes one tool like this:

{
  "name": "lookup_order",
  "description": "Find one order by its number and return its status, items and delivery address. Use when the owner or a customer asks about an order.",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_number": {
        "type": "integer",
        "description": "The order number, for example 1042"
      }
    },
    "required": ["order_number"]
  }
}

The model never sees the code behind lookup_order. It sees only this text. Anthropic’s engineering team describes tools as reflecting “a contract between deterministic systems and non-deterministic agents”. Deterministic software does the same thing with the same input. A model does not always, so the written contract matters.

How does the model decide whether to call a tool?

It reads the request and the tool descriptions and decides on each turn. Anthropic’s overview says that with its default setting the model “determines on each turn whether to call a tool or respond directly”, and calls a tool when the request fits a tool’s described capability and the answer is not already in context. It answers directly for things like stable knowledge or conversational turns. In our reading, that is why the description is not decoration: it is what the model has to go on.

What does a full round trip look like for the shop?

Illustrative example. Imagine the owner types “Where is order 1042?” on Monday morning. The shop has four made-up tools: lookup_order, track_parcel, draft_customer_message and send_customer_message.

1. Request. The shop’s software sends the question plus the four tool definitions to the model.
2. Tool call. The model replies with a request, not an answer: call lookup_order with order_number 1042.
3. Your code runs it. The software checks the order database and gets: shipped last week, with a tracking code.
4. Result returned. The software sends that result back to the model.
5. Another tool call. The model asks for track_parcel with that code. The courier system answers: held at the depot, delivery address incomplete.
6. Draft. The model asks for draft_customer_message, which only writes text and sends nothing.
7. Final response. The model tells the owner the parcel is held because the address is incomplete, shows the draft, and asks: “Shall I send it?”

Sending is a different tool, send_customer_message. The shop’s developer can set it up so that the code refuses to run it until the owner clicks approve. OpenAI’s guide says actions that are “sensitive, irreversible, or have high stakes should trigger human oversight until confidence in the agent’s reliability grows”. Giving the model a draft tool and a separate send tool is our own design choice, not something either vendor requires.

What happens when the model lacks information?

The model might guess. Suppose the owner had typed “Where is the Adeyemi order?” with no number. The lookup_order tool needs an order number. Anthropic’s documentation, as of October 2026, says that when a required parameter is missing, the model may ask for it, but it “might guess values you didn’t supply”, and adds: “This behavior is not guaranteed, especially for more ambiguous prompts and for less capable models.”

A guessed order number is exactly the kind of slip described in the third post, where wrong tool inputs were the largest group of the agent’s own failures that the tau-bench paper studied. Two defences follow. One is to tell the model in its instructions to ask when something is missing. The other is to check inputs in your own code before running anything.

Both vendors also offer a strict setting. As of October 2026, OpenAI says “Setting strict to true will ensure function calls reliably adhere to the function schema, instead of being best effort”, and Anthropic’s overview says adding strict: true to custom tool definitions ensures the calls “always match your schema exactly”. Strict mode makes the shape of the call correct. It cannot tell you whether the order number was the right one.

What makes a tool well designed?

Clear names, plain descriptions and few tools. Anthropic’s engineering team lists failures that good design reduces: “Agents might call the wrong tools, call the right tools with the wrong parameters, call too few tools, or process tool responses incorrectly.” Its advice, published on 11 September 2025, includes:

• Describe it like a briefing. Think of “how you would describe your tool to a new hire on your team.” Make implicit context explicit, and name an input user_id rather than user.
• Prefer a few thoughtful tools. It suggests tools such as search_contacts or message_contact rather than a list_contacts tool.
• Make errors useful. Error messages should say what to change, rather than return an opaque error code.

OpenAI’s guide gives similar advice: use enums and object structure to prevent invalid states, and avoid asking the model to fill in values your code already knows. As of October 2026, it also suggests, as a soft guide, fewer than 20 functions available at the start of a turn.

Anthropic’s engineering team writes that agents are “only as effective as the tools we give them”. In our reading, the practical lesson is that tools deserve as much care as the prompt.

What to remember

• A tool call is a request. The model writes it, your code runs it, and the result goes back to the model.
• A tool is described by a name, a plain-language description and an input schema. The model chooses from those words alone.
• Models can pick the wrong tool or guess an input, so check inputs in code and keep a person approving risky actions.

If you want to see how a business might connect models to its own systems more generally, our LLM integration guide covers API patterns for adding language models to apps. To revisit the basics, see What Is an AI Agent, and How Is It Different from a Chatbot? and How Does an AI Agent Actually Work, Step by Step?.

Next in the series: the Model Context Protocol (MCP), and why so many tools mention it.