Function Calling

What it is

The mechanism by which a model is shown a set of callable declarations, emits a structured request to invoke one of them with arguments, and receives the outcome back as part of its next input. The model does not execute anything; it produces an intention in a form the host application can parse and act on. Everything interesting happens in the loop this creates — declare, select, emit, execute, return, continue — and in the budget of turns that loop is allowed before the user gets an answer.

Why it matters

This is the point where a language model stops being a text generator and starts causing effects in other systems, so the quality of the mechanism sets a ceiling on everything built above it. Selection accuracy falls as the declaration set grows, argument fidelity falls as schemas get deeper, and both failures look like the same thing from the outside: an agent that did the wrong thing confidently. The loop also governs cost and latency, because every result returned to the model is re-read on every subsequent turn of the same conversation.

The call and the contract check

Function calling is concerned with what the model is shown, what it chooses, and how the chosen call re-enters the conversation. Whether the arguments it produced actually satisfy the declared types, ranges, and required fields is a separate check with its own failure behaviour — one that must run even when the model is confident and the arguments look plausible. A system can have excellent selection and no validation, and will then execute well-chosen calls with malformed arguments.

Key decisions

• How many declarations are visible on a given turn, and by what rule the visible set is narrowed. Selection accuracy and prompt cost both move with this number.
• Whether the model may emit several calls in one turn, and if so whether the host executes them concurrently. Concurrency is only safe when no pair has a hidden ordering dependency.
• The call mode: free choice, a required call, a specific forced tool, or a prohibition on calling at all. Forcing removes the failure where a model answers from memory instead of looking something up, and introduces the failure where it calls a tool it did not need.
• What the model sees after execution: the full result, a projection, or a summary — and whether the earlier turns' results stay in context verbatim as the conversation lengthens.
• How a rejected call is reported back, and how many correction attempts are allowed before the turn is failed. Unbounded correction loops are the usual source of runaway token spend.
• Whether a call that the host cannot complete within the turn is reported as a failure or as a handle the model is expected to poll on a later turn.

Failure modes

• The declaration set grows past the point where the model distinguishes its members, and calls start landing on whichever of two similar tools was described more enthusiastically.
• Two declarations overlap in purpose but differ in a side effect, and the model treats them as interchangeable because nothing in the descriptions says one of them is irreversible.
• The model emits an enum value that is not in the enumeration, or an identifier it inferred from conversational context rather than from a lookup it was supposed to perform first.
• A returned result contains text shaped like an instruction, the model follows it, and the next call is the attacker's rather than the user's.
• The model answers from parametric memory instead of calling the tool that holds the current value, and the answer is plausible, specific, and out of date.
• Parallel calls are issued against a resource where order matters, and the outcome varies between runs that look identical in the transcript.
• A large result is pasted back into context, and the conversation's per-turn cost silently doubles for the rest of the session.
• The model repeats the same call with the same arguments after an ambiguous result, because nothing in the loop detects that no progress was made.

Related capabilities

• Tool Schema Validation — checks the arguments this mechanism produces
• Tool Result Normalization — decides what the result looks like on return
• Tool Discovery — supplies the candidate set that becomes declarations
• Tool Timeout and Retry — governs what happens when an invoked call stalls
• Tool Permission Management — decides whether an emitted call may proceed

Applies: Production readiness · Design questions