{"id":81002,"date":"2026-06-21T17:35:08","date_gmt":"2026-06-21T17:35:08","guid":{"rendered":"https:\/\/www.europesays.com\/ai\/81002\/"},"modified":"2026-06-21T17:35:08","modified_gmt":"2026-06-21T17:35:08","slug":"tool-calling-explained-how-ai-agents-decide-what-to-do-next","status":"publish","type":"post","link":"https:\/\/www.europesays.com\/ai\/81002\/","title":{"rendered":"Tool Calling, Explained: How AI Agents Decide What to Do Next"},"content":{"rendered":"

In my latest post<\/a>, how to get structured, machine-readable outputs as a response from an LLM, using JSON Mode, function calling, and structured outputs. In that post, we briefly touched on the idea of function calling, approaching it as a method for obtaining structured responses. Nevertheless, function calling is something that goes well beyond just getting structured data back from a model, since it is essentially the backbone of agentic AI workflows. So, in today\u2019s post, we are going to take a closer look at exactly this topic.<\/p>\n

In all of the examples we have covered so far, the LLM is just used as a passive responder, meaning it receives a question and then generates an answer, and that\u2019s it. But what if we want the LLM not just to respond with something but instead to do something? Or to put it more precisely, what if we want an action to be triggered based on the model\u2019s response? This action may be anything: look up into live data, send a message, query a database, call an external API, and so on. <\/p>\n

This is made possible with tool calling. Tool calling is what transforms an LLM from a very smart text generator into something that can actually trigger actions and interact with the world around it. <\/p>\n

So, let\u2019s take a look!<\/p>\n

What is Tool Calling?<\/p>\n

Tool calling<\/a> (also called function calling<\/a>) is the mechanism by which an LLM can request the execution of external functions or APIs as part of generating its response. In other words, instead of just returning text, the model can execute a specific function with specific arguments, as a response to the user\u2019s request.<\/p>\n

The key thing to understand here is that the model itself does not execute the tool. It only decides which tool to call and with what arguments. The actual execution of the selected tool happens in our own code, in which the request to the AI model is included. We then feed the tool\u2019s result back to the AI model, which uses it to generate a final response to the user.<\/p>\n

This is the tool calling loop, which includes the following steps:<\/p>\n

The user submits a message<\/p>\n

The AI model takes the message as input and produces an output, which is essentially a decision on which tool to utilise and with which arguments<\/p>\n

The model\u2019s response containing the tool selection and respective arguments to be used is passed back to the code. The code \u2013 with no involvement of the AI model \u2013 executes the selected tool with the selected arguments. This execution produces some kind of result (e.g., a calculation, information obtained from an API, etc.), and this result is then passed back to the AI model.<\/p>\n

The AI model takes as input the result of the tool and produces a final response to the user based on that.<\/p>\n

\"\"<\/p>\n

Again, the model generates a tool call, not a tool execution. The two are very different things, and conflating them is one of the most common sources of confusion.<\/p>\n

But what exactly is a tool call? In practice, it means that the model returns a structured, machine-readable response using Function Calling, as we saw in the previous post. In this response, content is None; there is no natural language answer, just a structured instruction indicating which tool to call and with what arguments. It is only after we execute the tool and pass the result back that the model generates an actual text response for the user.<\/p>\n

But let\u2019s see this in practice!<\/p>\n

We\u2019ll start with a simple example using just one tool and one call, and then progressively build up to some more interesting scenarios.<\/p>\n

1. A single tool: weather API<\/p>\n

I think that the most common example of tool use with AI that comes to mind is a weather API (the cornerstone of custom, live data), so let\u2019s imagine we\u2019re building a weather assistant. In particular, we want to create a mechanism in which the user asks about the weather, and instead of just letting the AI model make something up (which the model would very happily do \ud83d\ude43), we want it to call a real weather function and get actual data about the weather from somewhere else, outside the LLM. To get the weather data, I will be using Open-Meteo<\/a>, a free, open-source weather API that happily requires no API key. <\/p>\n

To use a tool, we have to initially declare it in tools. <\/p>\n

from openai import OpenAI
\nimport json<\/p>\n

client = OpenAI(api_key=”your_api_key”)<\/p>\n

# Step 1: define the tool
\ntools = [
\n {
\n “type”: “function”,
\n “function”: {
\n “name”: “get_current_weather”,
\n “description”: “Get the current weather for a given city”,
\n “parameters”: {
\n “type”: “object”,
\n “properties”: {
\n “city”: {
\n “type”: “string”,
\n “description”: “The name of the city, e.g. Athens”
\n },
\n “unit”: {
\n “type”: “string”,
\n “enum”: [“celsius”, “fahrenheit”],
\n “description”: “The temperature unit to use”
\n }
\n },
\n “required”: [“city”]
\n }
\n }
\n }
\n]<\/p>\n

Notice how the actual tool to be used (the weather API) is mentioned nowhere up to this point. Instead, the model decides which tool to call based on three things: the function description (\u201cGet the current weather for a given city\u201d), the parameter descriptions (\u201cThe name of the city, e.g., Athens\u201d), and the enforced schema. It is purely from this information that the model figures out whether this is the right tool to call for a given user message and with what arguments. Thus, writing clear and accurate descriptions when defining our tools is of key importance for the model to successfully identify and call the right tool based on the user\u2019s input.<\/p>\n

So, after we have defined the tools variable, we can then make a request to the AI model:<\/p>\n

# Step 2: send the user message along with the tool definition
\nmessages = [
\n {“role”: “user”, “content”: “What’s the weather like in Athens right now?”}
\n]<\/p>\n

response = client.chat.completions.create(
\n model=”gpt-4o-mini”,
\n tools=tools,
\n messages=messages
\n)<\/p>\n

print(response.choices[0].message)<\/p>\n

Here\u2019s what happens when we make this request. The model reads the user\u2019s message, \u201cWhat\u2019s the weather like in Athens right now?\u201d, and understands that the available tool get_current_weather can help answer this query with real, live data. So, rather than generating a text response directly, it decides to call the tool first. More specifically, the model\u2019s response at this point looks like this:<\/p>\n

ChatCompletionMessage(
\n content=None,
\n role=’assistant’,
\n tool_calls=[
\n ChatCompletionMessageToolCall(
\n id=’call_abc123′,
\n type=’function’,
\n function=Function(
\n name=’get_current_weather’,
\n arguments='{“city”: “Athens”, “unit”: “celsius”}’
\n )
\n )
\n ]
\n)<\/p>\n

Notice how content is None, because the model isn\u2019t returning a text response, but a tool call. Now it\u2019s our job to actually execute the tool, the model selected, and return the result back to it. In our case, this is going to be making the API request to the weather API, using the arguments (that is, the city and unit of measurement) provided in the AI model\u2019s response:<\/p>\n

# Step 3: execute the tool using the Open-Meteo API
\nimport requests<\/p>\n

def get_current_weather(city: str, unit: str = “celsius”):
\n # geocode the city name to coordinates
\n geo = requests.get(
\n “https:\/\/geocoding-api.open-meteo.com\/v1\/search”,
\n params={“name”: city, “count”: 1}
\n ).json()
\n lat = geo[“results”][0][“latitude”]
\n lon = geo[“results”][0][“longitude”]<\/p>\n

# fetch current weather
\n weather = requests.get(
\n “https:\/\/api.open-meteo.com\/v1\/forecast”,
\n params={
\n “latitude”: lat,
\n “longitude”: lon,
\n “current”: “temperature_2m,weather_code”,
\n “temperature_unit”: unit
\n }
\n ).json()<\/p>\n

temp = weather[“current”][“temperature_2m”]
\n return {“city”: city, “temperature”: temp, “unit”: unit}<\/p>\n

# extract the tool call from the response
\ntool_call = response.choices[0].message.tool_calls[0]
\narguments = json.loads(tool_call.function.arguments)<\/p>\n

# call the actual function
\nweather_result = get_current_weather(**arguments)<\/p>\n

we can then append the tool\u2019s result to the message history and then send everything back to the model:<\/p>\n

# Step 4: add the assistant’s tool call AND the tool result to the message history
\nmessages.append(response.choices[0].message) # important: append the tool call first
\nmessages.append({
\n “role”: “tool”,
\n “tool_call_id”: tool_call.id, # links the result back to the specific tool call
\n “content”: json.dumps(weather_result)
\n})<\/p>\n

# Step 5: send everything back to the model for a final response
\nfinal_response = client.chat.completions.create(
\n model=”gpt-4o-mini”,
\n tools=tools,
\n messages=messages
\n)<\/p>\n

print(final_response.choices[0].message.content)<\/p>\n

And now, we finally get a proper text response:<\/p>\n

It’s currently 29\u00b0C in Athens. Sounds like a great day to be outside!<\/p>\n

\ud83c\udf68 DataCream<\/a> is a newsletter offering stories and tutorials on AI, data, and tech. If you are interested in these topics, subscribe here<\/a>!<\/p>\n

2. Letting the model choose from multiple tools<\/p>\n

Now let\u2019s take a look at a more realistic example. In a real-world agentic application, the model typically has access to not one, but multiple tools, and as a result, it needs to figure out which one (or ones) need to be used based on what the user is asking.<\/p>\n

Let\u2019s extend our initial weather API example by adding an additional tool for currencies. For this, we\u2019ll use Frankfurter<\/a>, a currency API providing European Central Bank daily rates, again with no API key requirement. So, let\u2019s update our tools variable by adding a second tool for converting currencies:<\/p>\n

tools = [
\n {
\n “type”: “function”,
\n “function”: {
\n “name”: “get_current_weather”,
\n “description”: “Get the current weather for a given city”,
\n “parameters”: {
\n “type”: “object”,
\n “properties”: {
\n “city”: {“type”: “string”, “description”: “The name of the city”},
\n “unit”: {“type”: “string”, “enum”: [“celsius”, “fahrenheit”]}
\n },
\n “required”: [“city”]
\n }
\n }
\n },
\n {
\n “type”: “function”,
\n “function”: {
\n “name”: “convert_currency”,
\n “description”: “Convert an amount from one currency to another”,
\n “parameters”: {
\n “type”: “object”,
\n “properties”: {
\n “amount”: {“type”: “number”, “description”: “The amount to convert”},
\n “from_currency”: {“type”: “string”, “description”: “The source currency code, e.g. USD”},
\n “to_currency”: {“type”: “string”, “description”: “The target currency code, e.g. EUR”}
\n },
\n “required”: [“amount”, “from_currency”, “to_currency”]
\n }
\n }
\n }
\n]<\/p>\n

And also set up the actual convert_currency function using the Frankfurter API:<\/p>\n

def convert_currency(amount: float, from_currency: str, to_currency: str):
\n response = requests.get(
\n f”https:\/\/api.frankfurter.dev\/v2\/rate\/{from_currency}\/{to_currency}”
\n ).json()<\/p>\n

rate = response[“rate”]
\n converted = round(amount * rate, 2)
\n return {
\n “amount”: amount,
\n “from_currency”: from_currency,
\n “to_currency”: to_currency,
\n “converted_amount”: converted,
\n “rate”: rate
\n }<\/p>\n

In this way, the model can handle a much wider range of user requests; it can now also answer about currencies, on top of the weather \ud83d\ude0b. Now, if the user asks \u201cWhat\u2019s the weather in Athens?\u201d, the model should call get_current_weather. If they ask \u201cHow much is 100 USD in EUR?\u201d, it should call convert_currency. And if we ask something irrelevant to both weather and currencies for which neither of the available tools can help, the model will simply respond in text without calling any tool at all.<\/p>\n

But let\u2019s see this in action:<\/p>\n

messages = [
\n {“role”: “user”, “content”: “How much is 200 USD in EUR?”}
\n]<\/p>\n

response = client.chat.completions.create(
\n model=”gpt-4o-mini”,
\n tools=tools,
\n messages=messages
\n)<\/p>\n

tool_call = response.choices[0].message.tool_calls[0]<\/p>\n

Let\u2019s take a glance at the response:<\/p>\n

print(tool_call.function.name) <\/p>\n

from which we get convert_currency. So, the model understood that the question \u201cHow much is 200 USD in EUR?\u201d is relevant to the convert_currency tool. Let\u2019s also take a look at the arguments:<\/p>\n

print(tool_call.function.arguments) <\/p>\n

from which we get <\/p>\n

‘{“amount”: 200, “from_currency”: “USD”, “to_currency”: “EUR”}’<\/p>\n

So, the model correctly identifies convert_currency as the right tool and fills in the appropriate arguments, without us doing anything other than providing appropriate tool descriptions, and the user providing an appropriate message. This exact decision-making mechanism is what makes tool-calling the foundation of agentic systems.<\/p>\n

3. Calling multiple tools at once<\/p>\n

Another interesting tool calling scenario is that many models, like gpt-4o, can call multiple tools in a single response when the user\u2019s request requires it. This is known as parallel tool calling<\/a>.<\/p>\n

For example, let\u2019s imagine a scenario where the user asks in a single request something that requires the use of both the get_current_weather and convert_currency tools to obtain the required info:<\/p>\n

messages = [
\n {“role”: “user”, “content”: “What’s the weather in Athens and how much is 100 USD in EUR?”}
\n]<\/p>\n

response = client.chat.completions.create(
\n model=”gpt-4o-mini”,
\n tools=tools,
\n messages=messages
\n)<\/p>\n

for tool_call in response.choices[0].message.tool_calls:
\n print(tool_call.function.name)
\n print(tool_call.function.arguments)<\/p>\n

In this case, the response we get is the following:<\/p>\n

get_current_weather
\n{“city”: “Athens”}<\/p>\n

convert_currency
\n{“amount”: 100, “from_currency”: “USD”, “to_currency”: “EUR”}<\/p>\n

Notice how both tools are called in a single model response. We can then execute the respective tools with the provided arguments and pass back the tool results to the model together. This is much more efficient than sequential calls, and it\u2019s how more advanced agents handle multi-part requests.<\/p>\n

On my mind: So, what makes this agentic?<\/p>\n

One thing that has always gotten on my nerves is the term \u201cagentic\u201d being slapped on everything. Agents, agentic workflows, anything originating from the word agent is very sexy nowadays, but as you may have already discovered yourself, not everything sold as agentic really is.<\/p>\n

So let\u2019s take a step back and think about what an agent actually is in the first place. At its core, an agent is something that perceives its environment, processes that information in some way, has a goal, and then decides what action to take in order to achieve it. Think about what our tool calling mechanism is doing: it perceives the tools available, decides which one is appropriate to address the user\u2019s request (if any), and passes that decision on to the rest of the code for execution. That, in its simplest form, is agency.<\/p>\n

In real-world agentic applications, the tool calling loop runs not one but multiple times, with the model using the results of one tool call to decide whether, and which, tool to call next. This is sometimes called a ReAct loop<\/a> (Reason + Act), and it\u2019s what allows agents to handle complex, multi-step tasks that can\u2019t be solved in a single call.<\/p>\n

Ultimately, what I find most fascinating about tool calling is how it changes the nature of what an LLM is. Up to this point, a language model was essentially a very sophisticated input-output function, which takes text as input and generates text as output. But with the tool calling, we gain access to an endless collection of additional functionalities, which we can combine with the reasoning power of the LLM to create systems that are far more capable than either alone.<\/p>\n

\u2728 Thank you for reading! \u2728<\/p>\n

If you made it this far, you might find pialgorithms useful<\/a> \u2014 a platform we\u2019ve been building that helps teams securely manage organizational knowledge in one place.<\/p>\n

Loved this post? Join me on \ud83d\udc8cSubstack<\/a> and \ud83d\udcbcLinkedIn<\/a><\/p>\n

All images by the author, except mentioned otherwise.<\/p>\n","protected":false},"excerpt":{"rendered":"In my latest post, how to get structured, machine-readable outputs as a response from an LLM, using JSON…\n","protected":false},"author":2,"featured_media":81003,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[179,7493,23817,415,7067,5147,44142],"class_list":["post-81002","post","type-post","status-publish","format-standard","has-post-thumbnail","category-agentic-ai","tag-agentic-ai","tag-agentic-artificial-intelligence","tag-deep-dives","tag-llm","tag-programming","tag-python","tag-tool-calling"],"_links":{"self":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/81002","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/comments?post=81002"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/posts\/81002\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media\/81003"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/media?parent=81002"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/categories?post=81002"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/ai\/wp-json\/wp\/v2\/tags?post=81002"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}