Function calling: how to make an LLM act, not just answer

A language model, on its own, only knows how to do one thing: generate text. It's a brilliant conversationalist and a useless executor. Ask it what your bank balance is and, without help, it'll invent a convincing number — because generating plausible text is literally all it does. Function calling is the bridge between that conversationalist and the real world. It's the mechanism that turns "AI that talks" into "AI that does."

If you want to build agents that solve problems — not chatbots that push the customer to the portal — you need to understand this deeply.

What it really is

Function calling (also called tool use) is the model's ability to decide, in the middle of a conversation, that it needs an external tool and to ask to use it. The flow is this:

1. You tell the model which tools exist (name, description, parameters).
2. During the conversation, the model realizes it needs one of them and, instead of replying with text, returns a structured call: get_order(id: "123").
3. Your code executes that function for real — queries the database, calls the API — and returns the result to the model.
4. The model uses that real data to continue the conversation: "Your order 123 went out for delivery today."

The point many people get wrong: the LLM doesn't execute anything. It only decides what to call and with which arguments. The one that executes — and validates — is you. That separation is the backbone of a safe agent.

Why this changes everything

Without tools, an LLM's ceiling is giving generic information and, at worst, hallucinating. With tools, it starts operating on the reality of your business: the customer's real data, real inventory, the real payment. The conversation stops being about the problem and starts solving the problem.

That's exactly the difference that separates an AI agent from a chatbot. The chatbot says "for a duplicate invoice, go to the portal." The agent calls generate_duplicate_invoice(customer_id), gets the invoice, and sends the PIX in the conversation. Same question, completely different categories of software — and the difference is well-done function calling.

How to design good tools

The quality of your agent depends more on tool design than on the model. Principles I follow:

Descriptions the model understands. Each tool's description is a prompt. "Fetches information" is bad; "Fetches the delivery status of an order by order number" is good. The model chooses the tool by reading this — be specific.

Typed, minimal parameters. Ask for exactly what the function needs, with clear types. Fewer parameters, fewer chances for the model to fill them in wrong. Enums when the values are fixed.

Atomic tools, not Swiss army knives. A tool that does five things depending on an action parameter confuses the model. Prefer separate open_ticket, check_ticket, close_ticket. Each does one thing well.

Returns the model can use. Return structured, concise data. A giant JSON burns context and confuses. Return the essentials for the next decision.

The mistakes that break in production

I've seen (and made) all of these:

• Trusting the model's arguments without validating. The LLM can hallucinate a customer_id that doesn't exist, or a negative value. Your execution layer validates everything before acting. A non-negotiable rule.
• Irreversible tools without confirmation. transfer_money can't be called just because the model thought it was a good idea. Actions that change the world irreversibly require explicit user confirmation and a log.
• Infinite tool loops. The model calls, the result makes it call again, and it spins in a cycle. Set a limit on calls per turn and observability to detect it.
• No logging of the calls. If you don't record which tool was called, with which arguments, and which result, you can't debug anything when it goes wrong. And it will.

The golden rule

I sum it up like this: the LLM is the brain that decides; the tool layer is the body that acts responsibly. The brain can wander, hesitate, even hallucinate. The body — your code — can't. It validates every intention, confirms what's dangerous, executes what's safe, and logs everything.

Function calling is what makes AI leave the screen and touch the business. But it's also where the risk lives. Doing this layer well is the difference between an agent you trust in production and one you shouldn't have plugged in.

I build AI agents that actually act — with safe function calling, integrated into the business's systems. If you want to move past the chatbot and have AI that executes, let's talk.