function-calling agents
A function-calling agent does not just describe what it wants to do — it emits a structured call, naming a function and filling its arguments, that a runtime can execute directly. Instead of parsing free text like please look up the weather in Taipei, the system hands the model a typed menu of functions and the model replies with get_weather(city="Taipei"). The model decides which tool and with what arguments; the host actually runs it and returns the result.
Each tool is declared with a name, a description, and a JSON-schema for its parameters. At inference the model is conditioned on these declarations and, when appropriate, produces a structured object that conforms to the schema; constrained decoding or fine-tuning on tool-use data keeps the output valid. The host validates the arguments against the schema, invokes the real function, and feeds the return value back into context so the model can continue. This turns brittle string parsing into a typed, checkable interface.
The schema is both the strength and the limit: a precise, well-described schema steers the model to correct, parseable calls, while a vague one yields wrong tools or malformed arguments. Validation guards type errors but not semantics — the model can still call the wrong function or pass plausible but incorrect values — so confirmation steps and idempotent or reversible tools matter for anything with side effects.
{
"name": "get_weather",
"description": "Current weather for a city",
"parameters": {
"type": "object",
"properties": { "city": { "type": "string" } },
"required": ["city"]
}
}
// model emits -> {"name":"get_weather","arguments":{"city":"Taipei"}}A typed tool declaration and the structured call the model produces to match it.
Schema validation guarantees a call is well-formed, not that it is the right call: type-correct arguments can still be semantically wrong.