Function Calling, How a Chatbot Actually Does Things

Function calling (also called tool use or tool calling) is the mechanism that lets a language model do something instead of only saying something. You describe a set of functions to the model, each with a name, a plain-English description, and a list of parameters. When the conversation calls for one, the model returns a structured request to run that function with specific arguments. Your code executes it, sends the result back, and the model carries on talking with the answer in hand.

Why it matters when you are buying or building

Everything that makes a chatbot worth paying for lives behind function calling. Checking real availability. Booking the appointment. Looking up an order. Creating a CRM record. Transferring a live call to a human. Without tools, you have a bot that can describe your business. With tools, you have one that can operate it.

When you evaluate platforms, this is the capability to interrogate hardest. Ask what a tool can call, whether it can be an authenticated HTTP request, whether the response is fed back into the conversation, whether tools can run mid-call on voice, and what happens when a tool times out. Those answers separate platforms that can run a business from platforms that can only answer questions. Most of the ones I work with, including Voiceflow and ElevenLabs agents, handle this well, and I have client agents that send email, generate images and book calls through tools.

A production example

The most expensive function-calling bug I have hit was on a voice stack where the call transfer tool had a hardcoded call identifier instead of the live call's control ID. In testing it looked fine. On real calls, every transfer came back as an error and the caller was left sitting with an agent that kept apologizing. The lesson generalizes well past that one platform: tools that act on a live session must be handed the current session's identifiers at runtime, never baked in at configuration time. I wrote up the broader pattern in my guide to call transfer flows.

Rules I follow when defining tools

• Write the description for the model, not for a developer. The description is what decides whether the tool gets called at the right moment.
• Keep parameters few and required ones fewer. Every optional parameter is a chance for the model to invent a value.
• Return a clear failure message, not an empty body. The model will read it and can tell the user something honest.
• Always give the agent an explicit fallback for when the tool fails, usually a human handoff.
• Test against real records, not synthetic ones. Green tests on invented data have hidden real bugs for me before.