Function calling
The model-side mechanism behind tool use: the model returns a structured invocation — name plus JSON arguments — matching a declared schema, which the host executes and feeds back.
A schema, a structured reply, an execution
You declare functions with names, descriptions and JSON schemas. The model returns a call — function name plus arguments — instead of prose. The host validates and executes it, then returns the result for the model to reason over. The description field does more work than people expect: it is the only thing telling the model when this function is the right one.
Why the details differ per provider
Every major provider supports the idea and no two agree on the envelope: parameter names, parallel-call semantics, how a refusal is expressed, how streaming interacts with a partial call. Code written against one provider’s exact shape is code that has quietly chosen a vendor.
Normalisation is what buys portability
A runtime that translates one internal representation into each provider’s dialect lets the same workflow run on a frontier API today and a local model tomorrow. That is a portability decision made once at the runtime layer rather than a migration project per workflow.
In AGNT
AGNT normalises function calling across providers, so the same workflow runs on GPT, Claude, Gemini or a local model.
Function calling — common questions
Do all models support function calling?
Most current instruction-tuned models do, with varying reliability. Smaller local models generally need simpler schemas and fewer simultaneous options to stay accurate.
How does AGNT handle provider differences?
It normalises calling across providers, so a workflow built against one model runs against another without rewriting the steps.
What makes a function easy for a model to call correctly?
A clear name, a description that explains when to use it, required parameters kept few, and enums instead of free text wherever the value set is known.