A language model on its own can only produce text. So how does an AI "check your calendar," "send the email," or "look up the order"? The answer is function calling — sometimes called tool use — and it's the single mechanism that turns a chatbot into an agent that can actually do things. Understanding it demystifies most of what people find magical about AI agents, because once you see the loop, you realize the model never touches your systems directly. It just asks, and your code does the work.
Here's the whole trick. You tell the model, up front, "here are some functions you can use" — each with a name, a description, and what inputs it needs. When a request would need one, the model doesn't run anything itself. It replies with a structured message that says, in effect, "call get_weather with city = Chicago." Your code sees that, actually runs the function, gets the result, and hands it back to the model, which then writes the final answer using it. The model decides what to call; your program does the calling. That separation is the safety and the power of the whole design.
A user asks, "What's the weather in Chicago and should I bring a jacket?" The model recognizes it can't know live weather, so it emits a function call for get_weather(city: "Chicago"). Your code runs that against a real weather API, gets "12°C, windy," and passes it back. Now the model has a fact it didn't have, and it writes: "It's 12°C and windy in Chicago — yes, bring a jacket." From the user's side it looks like the AI "knew" the weather. Really, it knew which tool to reach for and how to phrase the request.
Give a model a set of functions and a goal, and it can chain calls to accomplish something: look up a customer, check their orders, issue a refund, send a confirmation — deciding at each step which tool to use next based on what the last one returned. That loop of decide → call a tool → read the result → decide again is the beating heart of an agent. If you want the bigger picture of how it fits together, we lay it out in the agentic loop explained and in what is an AI agent.
You define each tool with a schema — its name, a plain description of what it does, and the shape of its inputs. The description matters more than people expect: the model chooses tools based on it, so a vague description leads to the model picking the wrong tool or calling it with garbage. This is also why function calling and structured outputs are cousins — both are about constraining the model to emit clean, valid, machine-readable data instead of free-form prose. Get the schemas right and reliability jumps.
Function calling is powerful precisely because tools can do real, sometimes irreversible things — delete records, spend money, send messages. The model deciding to call delete_account and your code blindly running it is how automated systems cause real damage. The discipline is least privilege plus a human gate: give the agent only the tools the job needs, make read-only things read-only, and require explicit confirmation before anything destructive or costly executes. An agent that can call a dangerous function isn't a problem; an agent that can call it with nothing standing in the way is. We go deeper on that in the MCP server security checklist.
Each turn of the tool loop is another model call, so an agent that chains five tools costs several times a single reply — worth watching with the token counter and pricing with the price comparison tool when you design the flow. And because a mis-called tool can send an agent down a wrong path invisibly, log every call and its result. That trace is how you debug agents at all — the theme we hit in AI agent observability.
Function calling is the line between a chatbot and an agent that gets work done. The cost tools above are free — no signup, right in your browser. And QADIR OS ships with tools plus a permission gate on the dangerous ones, so your agent can act without acting recklessly. Join QADIR OS early access.