How function calling works: the model only ever asks
# How function calling works: the model only ever asks
An AI assistant tells you it is raining in your city right now. Another one adds an event to your calendar, and the event really appears. Meanwhile, the language model behind both of them cannot check weather, cannot touch a calendar, and cannot act on the world in any way at all. Text goes in, text comes out. That is the entire machine.
This gap confused me for a long time. The mechanism that closes it is called function calling, and once it clicks, most of the mystery around AI agents evaporates. Here is the whole thing, in plain language, without hand waving.
Start with what a model cannot do
Everything else depends on one fact, so it goes first. A language model takes in text and predicts more text. It has no hands. It cannot open a web page, cannot run a program, cannot read a file off your disk. When an assistant appears to look something up, the model never did the looking. Ordinary code did, and the model only handled the words on either side.
This tells you where the boundary sits. The model lives inside a world of text. Anything that touches the real world, fetching data, sending an email, running a calculation, happens outside the model, in code that you wrote and you control. Function calling is the bridge between those two territories.
First you hand it a menu
The setup happens before any question gets asked. You describe the tools the model may use. Each tool gets a name, like get weather. A short description of what it does: returns the current weather for a city. And a list of the inputs it needs, in this case a city name.
Notice what you are handing over. Descriptions of code, written in terms the model can read. Never the code itself. A room service menu works the same way: it contains no kitchen, just a list of what you may order and what information the kitchen needs from you.
The model reads this menu alongside your actual question. Now it knows what exists. If a question needs live weather, there is a thing called get weather that could be requested. Running that thing remains impossible for the model. Knowing it exists is enough.
The model asks and then it stops
Here is the heart of the whole design, and the part that surprised me most.
When the model decides a tool is needed, it produces a small structured message: please run get weather, city set to Singapore. Then it stops and waits. That is the entire act people describe as calling a function. Nothing was called. The model wrote down a request, in a rigid format, for someone else to carry out. You have seen this move in restaurants: writing your order on a slip and handing it to the waiter cooks nothing.
Sit with that for a second, because it carries the whole safety story. The most a model can ever do is ask. Whether the request gets honored is decided entirely by the code on the other side, and that code is yours.
Your code does the doing
The structured request lands in your program. Your program sees the model wants get weather for Singapore, and runs the actual function: real code, written by you, calling a real weather service, returning a real answer. The model sits outside, waiting, while ordinary software does the work.
Because you wrote this layer, you own every decision inside it. You can inspect the request before running anything. You can refuse it outright. You can require your own explicit approval before certain tools fire. The model proposes; your code disposes. The gap between asking and doing is where all of the safety lives, and no request becomes an action unless your code chooses to carry it out.
The answer goes back in
Closing the loop is the easy part. Your code got back something like twenty eight degrees and raining, and hands it to the model as more text: here is the result of the tool you requested. The model, still doing the only thing it knows, prediction, turns that fresh information into a natural reply. Looks like you will want an umbrella today.
The model never met the weather service. It asked for a number, your code fetched the number, and the model wrapped words around what came back. The whole round trip finishes in well under a second, which is why it reads as the assistant just knowing the weather.
Five steps, one loop
End to end, in a straight line. You ask what the weather is in Singapore. The model reads your question plus the tool menu and, instead of answering, emits a request for get weather. Your code catches the request and runs the real function, which returns twenty eight and raining. Your code feeds the result back. The model writes the final friendly answer.
Ask, request, run, return, reply.
The model participated at exactly two points: deciding a tool was needed at the start, and turning the result into words at the end. Every step that touched the real world was plain code under your control. Once you can see those five steps, every AI product starts looking a good deal less magical.
The name is the confusing part
The phrase function calling suggests the model reached out and executed code, the way one part of a program calls another. It never does. It generates text describing a call it would like to happen, and those are different things in the way that pressing a button differs from writing a note that says please press this button.
Every fancier name floating around, tool use and the rest, sits on the same floor. Underneath, the model performs its single trick, producing text, and the text happens to be a request in a format your code knows how to parse. A very good writer, filling out a very specific form.
Why this design should reassure you
Because the model can only ask, it holds no direct power over your systems. Your files and accounts sit beyond its reach. The only actions available are the specific tools you chose to describe, and each of those runs solely through code that gets the final say. Describe no tool that deletes things, and no generated text, however creative, can delete anything.
The picture I keep in mind is a capable assistant who fills out request forms all day and holds keys to none of the doors. You hold the keys. That boundary is the design, and it is why a carefully built AI tool stays trustworthy even while the model inside it does surprisingly clever things. The cleverness lives in the asking. The power stays with you.
Where it goes wrong anyway
Real failures exist, and they are worth naming.
The model asks for the wrong tool, because your descriptions were vague and search looked as plausible as weather. It asks with bad inputs, a city you never mentioned, because it misread the question. And given the chance, it loops, requesting tool after tool without ever concluding it is done.
The fixes are unglamorous. Write sharp tool descriptions, for the same reason clear instructions to a person produce better results. Check inputs before running anything, because a request is a suggestion and never a command. Put a hard ceiling on how many times the loop may run, so it can never spin forever. Ordinary, careful wiring. Nothing exotic.
How it decides, and what an agent really is
One last gear to expose. The model holds no rule engine saying if the question mentions weather, request the weather tool. Deciding is the same text prediction as everything else: it reads your question and the menu, and when the most natural continuation is a tool request, a tool request is what comes out. Vague menu, wrong guesses. Sharp, plain descriptions, right tool far more often. Label the boxes clearly and people hand you the right thing; models are no different on this point.
And here is the payoff. An AI agent, the thing generating all the noise right now, is this exact loop run repeatedly. Request a tool, receive the result, request the next tool, until the task is done. Even the standard protocol people use to plug assistants into outside tools amounts to a shared format for writing the menu, so any model can read any tool's description. Understand the one loop and you understand the engine inside nearly every serious AI product being shipped today.
It took me embarrassingly long to see that the model never acts and only ever asks. Once that landed, agents stopped being intimidating. If plain-language breakdowns of how this technology actually works are useful to you, I publish them at [xavierfok.com](/).
Get new guides and videos first — join the Telegram channel.