Function Calling (Tool Calling)

Function calling, also called tool calling, is a mechanism where a model is given a list of available functions — each with a name, description, and parameter schema — and, instead of answering in free text, can emit a structured request to invoke one of them with specific argument values, which the surrounding application then executes.

A raw language model can only produce text. It cannot check today's weather, query a database, or send an email — it can only describe, plausibly, what the result of doing so might look like, which is a direct route to hallucination. Function calling closes that gap by giving the model a menu of real actions it can request, and a contract for how to request them precisely enough that code, not another model, can carry them out.

How it works

The developer sends the model a list of tool definitions alongside the conversation — each one a name, a natural-language description of what it does, and a JSON Schema describing its parameters. When the model decides a tool is needed, instead of writing a normal reply it emits a structured object naming the tool and supplying schema-valid arguments, generated using the same constrained-decoding mechanism behind structured outputs, so the call is guaranteed parseable. The application, not the model, actually executes the function, then returns the result back into the conversation as a new message, and the model continues, now with real data instead of a guess.

Critically, the model never runs anything itself. It only ever proposes a call; execution, permissions, and error handling live entirely in the application layer, which is what makes function calling safe to gate — a harness can approve, log, rate-limit, or reject any call before it touches a real system.

Why it matters

Function calling is the mechanism that turns a language model into the reasoning core of an agent: every "the AI checked the database," "the AI booked the meeting," or "the AI ran the query" a product claims is, underneath, a function call the model requested and the application carried out. It is also the point where the propose-and-approve safety pattern becomes concrete — a human or policy engine reviewing a proposed function call before execution is reviewing a structured, auditable object, not a paragraph of prose.

A worked example

Tools offered: a lookup that returns an order's status, and a refund function that takes an order id and an amount. User asks: "Where's my order 48213, and can I get my money back if it's late?" The model first emits a call to look up order 48213. The application runs it, returns a result showing the order is delayed by six days. The model, now holding a real fact instead of a guess, emits a second call to issue a refund of $12.50 against that order — which a propose-and-approve harness holds for human sign-off before any money moves, precisely because refunds are a consequential action and order lookups are not.

How Miatz teaches it

Function calling is built from scratch in the agents track: learners write tool schemas, wire a model to call them, and build the approval gate before they build the autonomy, mirroring exactly how Mysty, the AI shadow engineer, operates propose-and-approve with every function call audit-logged in production.